11–20 of 206 posts
The problem is not so much that python is slow. It's that in some scenarios python can't be made fast. Fast prototyping is great but being stuck with a prototype for deployment isn't.
"People saying it doesn't matter that Python is slow are deluding themselves and preventing Python from getting faster like JS did"
"Python is inherently harder to optimize than JS since it has "
"Smalltalk/Lisp/etc are also very dynamic yet are much faster"
"The slowness of Python is harming the planet by being inefficient and therefore wasting more energy/producing more pollution"
Did I miss any arguments? I know certain topics are bound to attract some repetitive discussion, but "Python is slow" has been one of the worst.
Right tool for the right job I suppose.
"It doesn't matter than Python is slow, besides we can use compiled libraries to speed it up" "People saying it doesn't matter that Python is slow are deluding themselves and preventing Python from getting faster like JS did" "Python is inherently harder to optimize than JS since it has " "Smalltalk/Lisp/etc are also very dynamic yet are much faster" "The slowness of Python is harming the planet by being inefficient…
The fact that Python is slow isn't its only problem. What I care more about nowadays is wasting my time hunting bugs that could have been avoided by a static type system.
Also most of my problems are IO bound so single threaded concurrency is fine.
But I represent a very small portion of the global problem space.
> Your bottleneck is most likely not CPU or Python itself.
With applications that are dominated by raw data processing, it's very, very easy to be CPU dominated. Hell, I had one quite trivial data converter for logfiles where the "parsing the printf string" part of Java's printf dominated processing and writing a custom formatter halved processing time (while regexes can be compiled, the format string cannot be precompiled and will be interpreted each time); it's one of those things where I would intuitively say "why did this moron write his custom formatter" if I stumbled upon it in a code review. Intuitively, you'd expect this to be a simple case of an IO dominated task (which it is now once the bottleneck has been removed).
If it's fire-and-forget batch jobs, you can get away with it, but if the converter is part of a user facing fat client application that runs on a old office laptop, you don't have that luxury.
The main example he cites is a study that compares the amount of time writing string processing routines in different languages - which is quite a bit different from the work I do every day. I develop web apps which means I generally work in very large code bases, and spend most of my time modifying existing code rather than writing fresh code from scratch. I have found that statically typed languages (java + typescript) and the fantastic IDE support that comes along with them make it really easy to navigate around the code and refactor things. Also - the compiler tends to catch and prevent a whole class of bugs that you might otherwise only catch at runtime in a dynamically typed language.
Of course there are other situations where I prefer to use Ruby as my scripting language of choice - it all comes down to using the right tool for the job at hand. Unfortunately I don't think the author gives enough consideration to the trade-offs between static vs. dynamically typed languages, and I think he would have been better just leaving that section out as it isn't really necessary to prove his point that CPU efficiency isn't important in a lot of applications.
Ultimately though I completely agree with his main point: "Optimize for your most expensive resource. That’s YOU, not the computer."
On the other hand, the idea that dynamic languages are more productive than static languages are laughable. Statically type languages prevent a lot of bugs and allow for a lot of automated provably correct refactorings that simple cannot be done with a statically typed languages. You can't even reliably do a "find usages" of classes using a dynamically typed language.