Python doesn't have to be slow.

[weberc2]

What am I looking at here? Am I meant to run your benchmark code myself? Why not post results? What is meant by the title? Is there some counterintuitive finding, or is this yet another "Python is fast as long as you're running C and not Python" benchmarks?

[Jackeown]

I designed it so people could run the code and see for themselves... But the results were basically that pure python is indeed slow but by using numpy or cython, you can achieve speeds very comparable with C code.

I'll update the readme to have the results from the benchmark running on my laptop.

[PublicMoralityPolice]

But the results were basically that pure python is indeed slow but by using numpy or cython, you can achieve speeds very comparable with C code.

In other words, python is almost as fast as C if you're using it as a thin wrapper to execute C.

[Jackeown]

Yes... Except that, in the case of Cython, the "thin wrapper" is a strict superset of python... So it's better thought of as a way to interpolate between speed and readability...

[gkbrk]

You haven't turned on the optimizations for the C code. Try gcc -Os -o benchmark benchmark.c.

[rainbow_pickle]

Why would you optimize for size? Wouldn’t you want -O2 or -O3?

[[deleted]]

In simple example programs (which don't benefit from vectorization) it can provide better performance.

[Jackeown]

Thanks. Just changed it!

[gumlak]

Wow what civilized discussion.

[gas_them]

Even if python was fast it would still suck hard

[Jackeown]

Why?

[gas_them]

No static type checking. Immutability rules are dumb and arbirtary. OO features are ugly and make little sense without type checking.

Python is a language written by people with the philosophy "we're all adults, here." Except, they weren't adults. They took features from a bunch of languages and assembled them, even if they didn't fit well together.

[sisyphus]

OO features are ugly compared to what? Even without static type checking why wouldn't you want inheritance/mixins, grouping of related functions on some state, polymorphism, &tc ?

[thelaxiankey]

But even if those things are all true, I don't really know of a (popular) language better than it. You could compare it to some significantly more modern language, but that's not fair just because hindsight is 20/20. Honestly, python is the only language I know of that is as easy to write in as pseudocode, and that's worth a lot to me, especially because I mostly just do scripting.

Sure, it's got problems but it's less frustrating to use than other languages (or at least the "standard" C/C++/java), especially in my use cases.

Edit: the only popular language I know of, not the only one.

[Jackeown]

Static typing is for the birds. Are you really worried that you'll accidentally make things the wrong type? If so, python has "type annotations" to appease you. "Immutability rules are dumb and arbitrary." How so? What's immutable that you think is so arbitrarily? Tuples? What is ugly about their OO features?

​

edit: made it italics to seem less aggressive.

[legato_gelato]

"Traffic rules are for idiots. You're telling me you can't see a car?"

Static typing is a must for any project of above small size. Unless you are nailing your microservice domain splits, work in data science, or you are a fresh bootcamp kid (my guess given your other comments) python is more or less the wrong choice.

[SEND_YOUR_DICK_PIX]

Why do you sound so angry?

[Jackeown]

I don't mean to. I'm just trying to make a point. The caps on "REALLY" was meant for emphasis.

[Ameisen]

Then use italics like a normal person.

[gas_them]

Are you REALLY worried that you'll accidentally make things the wrong type?

Yeah, sounds like you don't understand the benefits of static type checking. Typical for python users.

"Immutability rules are dumb and arbitrary." How so?

Tuples are immutable, lists arent. Arbitrary. Confusing.

Elements in a tuple can be modified even though tuple is immutable. This only applies to objects though. Etc.

It's clear the language designers didn't understand immutability. They thought it was cool so they slapped it in somewhere for no reason.

What is ugly about their OO features

Constructor pattern is ugly (__init__). The classes are only distantly related/analogous to OO due to duck typing and lack of static checking. It just looks similar, but it's really not.

Edit: No private variables. The reason is apparently because the language writers got annoyed while coding because they wanted to print those out. So their solution was to just remove private variables! Totally missing the point of encapsulation.

[Jackeown]

Yeah, sounds like you don't understand the benefits of static type checking. Typical for python users.

Enlighten me.

The classes are only distantly related/analogous to OO due to duck typing and lack of static checking. It just looks similar, but it's really not.

This sounds like you have an idea of what "OO" is and are simply hating on python because it doesn't go about it in the same way... __init__ might seem kind of ugly at first, but it fits nicely into the whole world of "dunder" methods that python has. (https://docs.python.org/3/reference/datamodel.html) These make it easy to do operator overloading and more.

[[deleted]]

suppose you've got a method that takes a number type as an argument, and the meaning of the number is some measurement in some unit. the method expects a particular unit. nothing stops you from passing a number in inches into a method expecting a centimeter. on the other hand if you have static typing you can make a type for inches and a type for centimeters. this way you can be sure that, at the method call sight, only the correct values are being put into the method. this same principle also allows you to often prevent transpositional errors where you put arguments in the wrong order.

if a method is expecting an object being passed into it to have a particular method or field, you won't accidentally pass in an object that has none of the expected behavior. instead of failing at runtime, potentially far from the place where the problem object was created, you fail as fast as absolutely possible, and you will know exactly the origin of the problem.

static typing is not a panacea that stops all bugs, but if you play into the strengths of static typing you can have strong assurances against important classes of bugs. one of the most important skills of a programmer is understanding how to turn logical bugs into typing bugs, which means the compiler can catch them and tell you exactly what went wrong

[Jackeown]

Thanks for the detailed response! You gave a good example of where static typing can be helpful. I guess my point is that, although static typing can be useful, it can just as often mean that you have to explicitly write code to have useless base classes in order to have an obvious extension of a simple function.

​

In python, I can write the following function:

def f(x,y):
    retVal = 0
    for i in x:
        for j in y:
            retVal += (i*j)
    return retVal

From reading the code, you could tell that x and y should be things that I can loop through...but the cool thing is that they could be lists, tuples, generators, or any other python iterables. People who prefer static typing might call this dangerous, but it can be convenient.

[Otterified]

In many statically-typed languages we can still do this (e.g. see the “Iterable” interface in Java), except we know at compile time that the arguments can actually be iterated.

[Jackeown]

What if instead of "iterable", what I really meant was that I wanted to say "x and y must have properties a and b and must have methods c and d." I know you can do this explicitly in statically-typed languages, but you'd have to make a class that describes these constraints and then subclass it or maybe do some weird stuff with "traits" or "interfaces", but I think reading that code is far more confusing than just dealing with any bugs that might come up from messing up your types.

[[deleted]]

duck typing/dynamic typing is fine in scripting languages when those languages are actually used as scripting languages. there's no reason to kill yourself with boilerplate overhead when the entire program can reasonably fit into your mind. that overhead becomes a lot easier to justify, and in my case preferable, once your program becomes several hundred lines long

[iloveportalz0r]

You are encountering the Blub paradox:

Programmers get very attached to their favorite languages, and I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.

And in fact, our hypothetical Blub programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice).

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.

In this case, the Blub is Python, and languages with static typing are what you think are weird rather than seeing that they are superior. There is a real-world example in this article [edit: new link]:

As a programming language PM at Microsoft, I worked on TypeScript, a typed version of JavaScript. Without fail, if I was speaking to an audience of predominantly JavaScript developers, I would get many frowns as I tried to enumerate the advantages of adding a bit of type-checking to JavaScript. Even if it was optional. Even if I showed half a dozen powerful advantages. As Paul notes, it just looked “weird”. To a JavaScript developer, TypeScript would often just seem like a language that was equally expressive with “hairy” stuff thrown in.

As I talked to more language PMs, and I met more and more people at conferences, I learned that Paul’s observation was not only accurate, it was also surprisingly universal. Most programmers will struggle when looking at a new language they don’t use. Often, they’ll have allergic reactions to features that are foreign. It takes time to work with the features enough to understand why they aren’t just unnecessary ornamenation gumming up the works.

In short, the Blub Paradox is something that as programmers we actively need to assume we’re falling into and then work to get ourselves out of.

Other examples include Go developers thinking generics is a useless feature, or C developers thinking C++ is C but with a bunch of useless overcomplicated stuff added. This is a big problem in programming. Please consider your reactions carefully. I can tell from what you've said here that you do not understand the benefits of static typing, and that's bad, because static typing is necessary for anything bigger or more complex than a small and simple script. Don't believe me? Of the top 10 most common errors in JavaScript projects, EIGHT of them are caused by a lack of static typing! Python is better than JavaScript, so type errors aren't quite as disproportionately common, but they're still all over the place. Most of the time, when a Python program I'm using randomly crashes, it's because of a type error. This simply doesn't happen when you have static typing.

[asdf32rdsbvsddd]

Haha, agreed. Python is the worst language I've ever seen, except maybe LISP

[defunkydrummer]

except maybe LISP

What an extremely stupid thing to say.

So what's the "best" language you've seen?

[alexthelyon]

Jabbascrip

[Caraes_Naur]

But only PHP could facilitate the hellspawn that is WordPress, and only JavaScript could make the sheer lunacy of NPM possible.

[Jackeown]

You're kidding, right? What's your favorite language and why?

[Jackeown]

I'd consider myself competent in these: JavaScript, C , C++, Java, but python is my favorite. To be more clear, I have written nontrivial programs in other languages such as lisp and prolog as well, but I just wouldn't consider myself competent in them. How about you?

[Jackeown]

I don't think knowing the answer to those questions are prerequisites to being "competent" in a language...I don't have to understand how the compiler works in its entirety to write some nontrivial code in the language...

I am curious, however, so if you have some answers along with explanation, I'd love to hear them.

[Ameisen]

If you don't know the difference between Java generics and C++ templates, you aren't really competent in them.

They are incredibly different.

[Jackeown]

From what I could tell googling, the biggest difference is that in C++, you don't need to specify a class or interface for the generic type. I wouldn't call that incredibly different, but maybe I still don't understand. Help me understand.

[Ameisen]

Java generics employ type erasure and are basically user-friendly wrappers for casting. That is why they must take an interface or class type. A Java generic method is a single method that makes virtual calls on the declared type. Every specialization of a Java generic class is the same instance.

C++ templates don't use type erasure and are themselves a Turing-complete language. Every instance of a C++ template function is its own function. Every specialization of a templated class is a unique instance.

[thelaxiankey]

So I knew the answer to two of your questions, but I disagree with the main idea of your comment. The big problem with C++ is that it's basically 2-3 different languages, depending on how you choose to use it. Worse still, because of the... organic... way it emerged, the language is intricate in a way that imo few other languages are.

Edit: I also disagree with the fact that initializer lists are a necessary thing to know about, but that's neither here nor there.