CompSci Bullying ☺




  • Fake News

    One of the early replies is nice though:

    I don’t think C gets enough credit. Sure, C doesn’t love you. C isn’t about love–C is about thrills. C hangs around in the bad part of town. C knows all the gang signs. C has a motorcycle, and wears the leathers everywhere, and never wears a helmet, because that would mess up C’s punked-out hair. C likes to give cops the finger and grin and speed away. Mention that you’d like something, and C will pretend to ignore you; the next day, C will bring you one, no questions asked, and toss it to you with a you-know-you-want-me smirk that makes your heart race. Where did C get it? “It fell off a truck,” C says, putting away the boltcutters. You start to feel like C doesn’t know the meaning of “private” or “protected”: what C wants, C takes. This excites you. C knows how to get you anything but safety. C will give you anything but commitment

    In the end, you’ll leave C, not because you want something better, but because you can’t handle the intensity. C says “I’m gonna live fast, die young, and leave a good-looking corpse,” but you know that C can never die, not so long as C is still the fastest thing on the road.



  • “It’s bullying, quite frankly” said Perl, a language once popular amongst developers. “I basically can’t go out now. As soon as I step outside of the house, a Pythonista/prick starts shouting in my ear about how shit I am. It’s really disturbing”.

    No Perl, everyone says you're shit. Nobody likes you

    This video's dialog could fit perfectly here. Just pretend Neville is Perl, Harry is Python and Ron is PHP (the clumsy sidekick that somehow manages to be useful).



  • I liked this one as well:

    Meanwhile, PHP is chilling in the corner, looking at his watch & waiting to get back to work.

    However PHP is not "chilling in the corner…". It's facing the corner with it's nose against the wall. Right @Arantor ? ☺



  • There definitely is something weird and culty about Python. I'm not a huge fan of the whole "there's only one way to do anything" mentality (with the implication that if you're not Doing it in Python, you're Doing it Wrong™.
    "Explicit is better than implicit?" Meh...



  • @tar said:

    "Explicit is better than implicit?"

    Sounds like Go. Have you ever used testing.T? I mean, sometimes slim is nice, but it's a little... spartan.

    At the same time... that's good in some situations. I've seen people trying to call C++ template functions from their JIT code, the compiler was fighting them every step of the way.


  • Discourse touched me in a no-no place

    The ScienceWeb tried to call Java, but no-one was home.

    They just have call screening these days.



  • @tar said:

    I'm not a huge fan of the whole "there's only one way to do anything" mentality

    Can that even be accomplished in a general-purpose language?

    I don't think so.

    @tar said:

    "Explicit is better than implicit?" Meh...

    Also not very meaningful while also being a rallying cry.

    Python doesn't have imports, which makes the exact meaning of later references implicit? Oh, wait, yes it does...



  • @Bort said:

    Can that even be accomplished in a general-purpose language?

    I don't think so.

    Or, as I occasionally feel the need to remember the guys who write our business rules: The fact you can do stuff in the business rules engine as is, doesn't mean you shouldn't be asking for language extensions to make your life easier.


  • Discourse touched me in a no-no place

    @Bort said:

    Can that even be accomplished in a general-purpose language?

    Of course not. But it's often possible to make one way much easier than the others.



  • @Bort said:

    Also not very meaningful while also being a rallying cry.

    From the book of van Rossum chapter 20:

    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    […]



  • @Bort said:

    Python doesn't have imports, which makes the exact meaning of later references implicit? Oh, wait, yes it does...

    Well, Python imports don't run around dumping the importee's stuff into any of your namespaces unless you explicitly tell them "OK, put your suitcase in my living room".


  • SockDev

    @tarunik said:

    Well, Python imports don't run around dumping the importee's stuff into any of your namespaces unless you explicitly tell them "OK, put your suitcase in my living room".

    same with NodeJS, and you can't really tell things to leave their suitcases in your livingroom... not without some real effort on your part

    best move ever IMNSHO


  • SockDev

    @accalia said:

    @tarunik said:
    Well, Python imports don't run around dumping the importee's stuff into any of your namespaces unless you explicitly tell them "OK, put your suitcase in my living room".

    same with NodeJS, and you can't really tell things to leave their suitcases in your livingroom... not without some real effort on your part

    Correct me if I'm wrong, but .NET is the same; in fact, it's the only sane thing to do.


  • SockDev

    correct, although you can use using aliases to get the same effect if you really want to.

    (I actually like C#. it makes it very easy to fall into the "Pit of success" by making the right thing generally easier to do than the wrong thing.)



  • @tar said:

    There definitely is something weird and culty about Python. I'm not a huge fan of the whole "there's only one way to do anything" mentality (with the implication that if you're not Doing it in Python, you're Doing it Wrong™.
    "Explicit is better than implicit?" Meh...

    Python is all about only having one way to do things?

    They have looked at urllib, urllib2, and urllib3 right? :stuck_out_tongue:


  • SockDev

    @accalia said:

    I actually like C#. it makes it very easy to fall into the "Pit of success" by making the right thing generally easier to do than the wrong thing.

    IIRC, it's one of the basic tenets of the language design. Having said that, throw ex;; bye-bye, incredibly useful stack trace!



  • So you have to be explicit about your implicitness...


  • kills Dumbledore

    @RaceProUK said:

    throw ex;; bye-bye, incredibly useful stack trace!

    At least there's some context conserved. I've seen far too much throw new Exception(ex.Message)


  • SockDev

    True, but it's still a weakness of the language; throw; and throw ex; are equally easy, and the latter is often used by devs with Java/C++ backgrounds, where, IIRC, the stack trace is not blasted into the digital ether.


  • SockDev

    @RaceProUK said:

    Having said that, throw ex;; bye-bye, incredibly useful stack trace!

    historical compatibility constraints there i think. sometimes you want to reset the stacktrace (helps for things like cross thread exceptions sometimes) and as i recall the bare throw was added to the language later, after release and other programs were relying on the reset of the stack trace.


  • kills Dumbledore

    It would be nice if they added a field like OriginalException or OriginalStackTrace for the rethrow case


  • SockDev

    throw new Exception() { InnerException = ex };
    :stuck_out_tongue_winking_eye:

    Obviously, throw a proper exception; I'm just showing the general case ;)


    @accalia said:

    curse you hedgehog! i was typing that!

    Mwahahahaha! :smiling_imp:


  • SockDev

    you mean InnerException?

    yeah it would be nice if that got filles with a copy of the exception with the or....

    curse you hedgehog! i was typing that!


  • kills Dumbledore

    Inner exceptions might already be filled by something else though, and it doesn't fix any existing code that just does throw ex;. Automatically preserving the original stack trace in a new field would Just Work and not have any backwards compatibility restraints


  • SockDev

    If you're creating the exception, then InnerException defaults to null, and is yours to do with as you please. And since it's a property of the Exception superclass, and therefore all Exception classes, you can chain exceptions via InnerException as much as you need ;)


  • kills Dumbledore

    Yes, but if I catch an exception that has an InnerException already I don't want the framework nuking that innerexception when I throw ex; like a noob.

    If the framework detected that I was rethrowing like a noob and stepped in to go "I'm not going to stop you, but in case you're a noob I'll just add in this detail that you've removed", that would be a good thing.

    It could also implicitly replace throw ex;with throw new Exception() { InnerException = ex };, but that would change the behaviour and potentially break things downstream. The important thing, though, would be the framework automatically doing these things, not hoping people are going to go through their 10 year backlog of C# to fix it up, because they might as well just change it to throw; in that case


  • SockDev

    It's a change that will never be made, not any more anyway; there are legitimate reasons for nuking the stack trace and stuff, and trying to make the compiler smart enough to detect 'noob' rethrows vs deliberate stack trace nuking would never work reliably enough.


  • SockDev

    @Jaloopa said:

    Yes, but if I catch an exception that has an InnerException already I don't want the framework nuking that innerexception when I throw ex; like a noob.

    actually the way i'd handle that is throw ex; copies ex and resets the stacktrace on the copy. then attaches the original unmodified ex as the copies InnerException then throws the copy.



  • @RaceProUK said:

    Correct me if I'm wrong, but .NET is the same; in fact, it's the only sane thing to do.

    I think it's possible, but you'd have to go way out of your way. And I could be wrong, the compiler might barf if you try it.

    @accalia said:

    (I actually like C#. it makes it very easy to fall into the "Pit of success" by making the right thing generally easier to do than the wrong thing.)

    Yeah, that.

    It's called "not being a shitty language." It's pretty rare.

    @RaceProUK said:

    IIRC, it's one of the basic tenets of the language design. Having said that, throw ex;; bye-bye, incredibly useful stack trace!

    If you throw a new exception, you're supposed to set the InnerException first. The framework itself sets a good example here, at least.

    @Jaloopa said:

    It would be nice if they added a field like OriginalException or OriginalStackTrace for the rethrow case

    Yeah, gee, they should do that. They should have done that in version 1.1. OH WAIT THEY DID.

    @Jaloopa said:

    Inner exceptions might already be filled by something else though,

    Huh? If you throw a NEW exception, you set the old one to your InnerException. The old exception can also have an InnerException. (And so on, as many levels as you have exceptions.) I don't understand your complaint here.

    @Jaloopa said:

    and it doesn't fix any existing code that just does throw ex;.

    Correct; it was not implemented with a magical wizard wand, it was designed by humans. I put that in the bug tracker, but the bastards marked it as "won't fix". Microsoft has like 60,000 employees, and NONE of them are magical wizards?!

    @Jaloopa said:

    Yes, but if I catch an exception that has an InnerException already I don't want the framework nuking that innerexception when I throw ex; like a noob.

    So don't do that?

    If you do wrong things you get wrong results. Whodathunkit.


  • kills Dumbledore

    @blakeyrat said:

    So don't do that?

    I don't, but the third party code I have to call into does, so the useful stack traces are obliterated.



  • Have you seen the garbage that is Throwable[] getSuppressed() in Java?

    It was added for the try-with-resources statement - if the block throws an exception, and the .close() throws an exception, the close() throw is added as a suppressed exception to the original.

    Because you can nest them, and getCause() can only return the one..


  • SockDev

    Not done Java for years.

    Not eager to do any either :wink:


  • Discourse touched me in a no-no place

    @riking said:

    It was added for the try-with-resources statement - if the block throws an exception, and the .close() throws an exception, the close() throw is added as a suppressed exception to the original.

    What happens if the close fails in C#?



  • It eats the original exception and just propagates whatever the one thrown from Dispose() was.



  • On a side note, for those of you not familiar with Java, try-with-resources is Java's answer to C#'s using.

    Anyway, the suppressed exceptions thing is tricky as a try block can be both a try/catch and try-with-resources block at the same time.

    If you have catch or finally blocks on the try, any exceptions thrown in those blocks will cause the try-with-resources exception(s) to show up as suppressed exceptions of the catch/finally block's exception.

    It's not clear from the documentation what happens if a try-with-resources block has multiple objects that throw exceptions when close is called on them. I suppose I should mock up some classes and try it.



  • If you know C#, they're almost the same thing. They're the two most similar languages/platforms in common use. The languages take ideas from each other, much of the same libraries exist in Java and .Net versions, much of the same tooling comes in Java and .Net variants...



  • Someone mentioned programming language cults and didn't mention me? I'm a bit surprised.



  • Java and C# are more inbred than the Hapsburgs.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.