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.<p>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..<p>Why don't you just be honest and say you don't care Python is slow because you like using it?<p>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.<p>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.
But python is both slow and inexpressive. No types, no match statements, no easy FP. Also the language is poorly designed and inconsistent.<p>I’m practically forced to use python for quant finance at my job because of the network effect: numpy, pandas, cvxpy, etc.<p>But the language itself is total garbage compared to, say, Scala or OCaml. And both of those languages are also much faster.
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.
“Python is more than 2x as productive as Java in the above study.“<p>How about compared to a functional language like Haskell, OCaml, or F#?<p>I agree that we should choose productivity over performance when possible. However, Java, for example, is extremely verbose.<p>My impression is that people who use functional languages are quite productive.<p>Plus, they need fewer unit tests.
Thing is, there are many languages expressive as Python, while providing compilation to native code without having to search for additional tooling.<p>No need to sacrifice performance for productivity.
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."
Whether slow code matters or not depends on the scale, because executing code requires power.<p>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.<p>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.<p>On the global scale, a large number of such systems can waste several nuclear reactors worth of electricity.<p>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.<p>The scale matters.
Long story in short description:<p>Python isn't slow.
Programming languages aren't slow or fast but interpreters are.<p>cpython is slow. PyPy interpreter is reasonably faster, upto 8 times.<p>Recently pypy 7.0 released which brought more hope.<p><a href="http://speed.pypy.org" rel="nofollow">http://speed.pypy.org</a>