
Yes, Python Is Slow, and I Don’t Care - zerogvt
https://hackernoon.com/yes-python-is-slow-and-i-dont-care-13763980b5a1
======
vp8989
The idea that a certain programming language could be proven to be more
productive than another is laughable. There are so many factors involved in
that, I can pretty much guarantee you it will never be studied to an
acceptable level of rigor.

The author presents some flimsy "study" about coding string processing
algorithms with a straight face, and basically loses all credibility. What
about lifetime productivity of a codebase? Speed of refactoring, onboarding,
testing etc..

Why don't you just be honest and say you don't care Python is slow because you
like using it?

Performance doesn't matter? Of course it does. On the frontend, bad
performance has been proven by many eCommerce companies to lead to lost
business. On backend data pipelines, bad performance kills your flexibility.
The longer it takes you to process N, the less times you can do it. The more
times you can do it, the more times you can get it wrong.

Also who says that time-to-market is everything? Tech history has shown that
product quality/brand marketing win out in the long term. There are tons of
forgotten shitty products that were first. Being first is over-rated.

~~~
Someone
_”The idea that a certain programming language could be proven to be more
productive than another is laughable.”_

I disagree. In the extreme, take python on the one hand and a variant of
brainfuck that requires the hash (could be as simple as CRC-32 or as hard as
SHA-256) of every source file to be zero on the other.

I don’t think you have to go that far to get provable differences, though.
Some features that, I think, can fairly easily be proven to make programmers
more productive in large parts of the space of programming tasks:

\- assembler macros

\- variable names that can have more than two characters

\- direct support for floating point

\- support for complex numbers

\- local variables

\- structures

\- support for serialization and deserialization. Compare the way one can make
simple structures serializable using Swift’s Codable protocol to whatever is
‘best’ for C (probably something macro-based)

\- generics

\- support for Unicode strings

\- iterators

Of course, “python vs Java” or “python vs Perl” are much closer races where I
expect measuring differences is way harder and results will depend on problem
domain, experience of the subjects of the study, number of good and bad
answers on StackOverflow, etc, but even for ‘normal’ languages, I expect some
conclusions to be possible, given enough effort is spent. Python 1.0 didn’t
have complex numbers, for example, so if your program needed them, python 1.4
was a huge improvement.

I doubt evaluating productivity of languages is worthwhile, though.

------
mruts
But python is both slow and inexpressive. No types, no match statements, no
easy FP. Also the language is poorly designed and inconsistent.

I’m practically forced to use python for quant finance at my job because of
the network effect: numpy, pandas, cvxpy, etc.

But the language itself is total garbage compared to, say, Scala or OCaml. And
both of those languages are also much faster.

~~~
deogeo
That is my experience as well - the only redeeming feature of the language is
the vast selection of easy-to-use libraries. The speed that the language
sacrificed isn't some inherent trade-off, but completely orthogonal to what
makes the language useful.

~~~
Yxven
You do realize that "vast selection of easy-to-use libraries" is the most
important feature of a programming language. Right? It's up there with, "it's
not hard to hire programmers for the language", which Python also benefits
from.

Like, I'm partial to Haskell, but if I'm actually trying to get work done, I
reach for a language with a robust ecosystem. These days I reach for
Typescript, but before then, python was my go-to since it's way nicer to
program with than java/c++/c/javascript.

~~~
ernst_klim
>You do realize that "vast selection of easy-to-use libraries" is the most
important feature of a programming language.

No, it's not. When I switched from Python to OCaml it felt like blessing,
since the quality of the libraries felt much higher in OCaml. There are also
the projects that you have to build from the ground up without libraries (any
mission critical software), and in such cases you don't care about libraries
at all, you care about the merits of the language solely.

Python is the BASIC of the XXI century, and it's fine in that role, but not as
a general purpose language.

------
geebee
One big factor in performance is whether a process can be parallelized. It can
be an interesting computational problem, and these techniques has really
gained relevance lately now the the barrier to clusters has dropped (cost and
technical complexity). A lot of algorithms (say for solving a massive
optimization problem) that were 10x slower in total operations but can be
split up and solved in arbitrarily small pieces are suddenly immensely
valuable. And in this context, the actual speed of the programming language
probably isn’t terribly important.

------
melling
“Python is more than 2x as productive as Java in the above study.“

How about compared to a functional language like Haskell, OCaml, or F#?

I agree that we should choose productivity over performance when possible.
However, Java, for example, is extremely verbose.

My impression is that people who use functional languages are quite
productive.

Plus, they need fewer unit tests.

~~~
dual_basis
I'm not sure if people using functional languages are more productive. One of
the points Uncle Bob makes in his talk supporting functional programming is
that it is harder and slower to write:

[https://youtu.be/7Zlp9rKHGD4](https://youtu.be/7Zlp9rKHGD4)

That said, I have to wonder if these dynamic scripting languages are truly
enabling productivity or if it just feels like that because you can write it
and try many things quickly. It reminds me of being such in traffic on the
highway - sometimes I get off and take back roads even if my GPS tells me it
will take longer, because it is more pleasant to be moving than feeling stuck.

That said, I think the biggest benefit of dynamic languages is that they are
so easy to refactor. You don't have as rigid a structure, so you can try
easily hack together some idea that, done "properly", would require a big
refactor. Despite being functional, Haskell's strong type system makes
refactoring a huge pain. If course the same things enabling this quick
refactoring in the dynamic languages works against you when it comes to speed
and reliability.

~~~
ggm
I sit with an FP expert (he might deny it, but he is). What I find, is that he
takes a lot longer to get to the solution that I hack out in a day in Python3
(with his assistance most of the time) but his solution has three interesting
properties.

1) its usually founded on a very good understanding of the problem, and the
abstractions inherent in the problem. If he can re-use the abstractions he has
used before he does, to great effect in speed-to-solution

2) it is very usually correct. it is remarkably bug free because the Haskell
typing removes a huge amount of ambiguity about the problem going in

3) he has absolutely no problem explaining what it does 3 months or more
later.

I value these behaviours immensely. My own Python is usually buggy, often re-
produces techniques I did a week ago, badly, and I can't explain why I used
that lambda/map function.

~~~
2wrist
It is really cool when you can find people like this. He sounds class!

~~~
ggm
He is!

------
pjmlp
Thing is, there are many languages expressive as Python, while providing
compilation to native code without having to search for additional tooling.

No need to sacrifice performance for productivity.

~~~
craftyguy
Care to name some examples?

~~~
pjmlp
Lisp, Scheme, Dylan[1], Smalltalk, JavaScript, Prolog.

[1] - Yeah, I know it is dead now, just wanted to mention it anyway.

~~~
purple_ducks
Is Prolog known for it's performance?

~~~
pjmlp
Well, it beats Python, given that most well known implementations do have JIT
compilers.

------
bobjordan
Great observation, 100% on point. "Microservices are inherently slow. The very
concept of a microservice is to break up a boundary by a network call. This
means you are taking what was a function call (a couple cpu cycles) and
turning it into a network call. There isn’t much you could do that is worse in
terms of performance. Network calls are really slow compared to the CPU. But
these big companies still choose to use microservices. There really isn’t an
architecture slower than microservices that I know of. Microservices’ biggest
con is performance, but greatest pro is time-to-market. By building teams
around smaller projects and code bases, a company is able to iterate and
innovate at a much faster pace. This just goes to show that very large
companies also care about time-to-market, not just startups."

~~~
cdoxsey
Except it doesn't scale. Amazon, Google and Netflix (the companies referenced
before this quote) can't run their applications on a single machine.
Distributed programming is unavoidable at scale.

Also there's a big difference between throughput and latency. Networking might
introduce a longer delay than a CPU call, but if each one of those calls does
significantly more work, the overall performance of the system can increase.

------
vardump
Whether slow code matters or not depends on the scale, because executing code
requires power.

If it's a one off or otherwise rarely executed, yeah, it doesn't matter much.
But it starts to matter when it's constantly running on a significant number
of systems.

Widely distributed frequently running slow code can waste a lot of energy.
Cell phones and laptops heat up and have a shorter battery life. Even desktops
require more power.

On the global scale, a large number of such systems can waste several nuclear
reactors worth of electricity.

10 times slower code might require 10 times the number of servers. Maybe it
doesn't matter much when it's just the difference between one and 10 servers.
Or perhaps you don't even consume 10% of a single server. But there's a point
when the hardware and power costs start to dominate.

The scale matters.

------
truth_seeker
Long story in short description:

Python isn't slow. Programming languages aren't slow or fast but interpreters
are.

cpython is slow. PyPy interpreter is reasonably faster, upto 8 times.

Recently pypy 7.0 released which brought more hope.

[http://speed.pypy.org](http://speed.pypy.org)

