CompSci Bullying ☺
-
All other languages tired of Python’s shit
New Zealand. A recent survey of software languages has revealed that every single one of them is sick to the back teeth of Python telling them it’s better than everything else for everything…
-
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...
-
"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.
-
The ScienceWeb tried to call Java, but no-one was home.
They just have call screening these days.
-
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.
"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...
-
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.
-
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.
-
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.
[…]
-
Python doesn't have imports, which makes the exact meaning of later references implicit? Oh, wait, yes it does...
Well, Python
importsdon'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".
-
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
-
@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.
-
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.)
-
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?
-
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...
-
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)
-
True, but it's still a weakness of the language;
throw;andthrow 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.
-
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.
-
It would be nice if they added a field like
OriginalExceptionorOriginalStackTracefor the rethrow case
-
throw new Exception() { InnerException = ex };
Obviously, throw a proper exception; I'm just showing the general case ;)
curse you hedgehog! i was typing that!
Mwahahahaha!
-
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!
-
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
-
If you're creating the exception, then
InnerExceptiondefaults tonull, and is yours to do with as you please. And since it's a property of theExceptionsuperclass, and therefore all Exception classes, you can chain exceptions viaInnerExceptionas much as you need ;)
-
Yes, but if I catch an exception that has an
InnerExceptionalready I don't want the framework nuking thatinnerexceptionwhen Ithrow 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;withthrow 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 tothrow;in that case
-
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.
-
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;copiesexand resets the stacktrace on the copy. then attaches the original unmodifiedexas the copiesInnerExceptionthen throws the copy.
-
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.
(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.
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.
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.
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.
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?!
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.
-
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..
-
Not done Java for years.
Not eager to do any either
-
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
tryblock can be both atry/catchandtry-with-resourcesblock at the same time.If you have
catchorfinallyblocks on thetry, any exceptions thrown in those blocks will cause thetry-with-resourcesexception(s) to show up as suppressed exceptions of thecatch/finallyblock's exception.It's not clear from the documentation what happens if a
try-with-resourcesblock has multiple objects that throw exceptions whencloseis 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.
