[pmontra]

There is a drive to improve performances of dynamic languages. Probably not a moral imperative but business imperatives. Everybody remembers what happened to JavaScript, from slow to fast in a few years. The same forces are at work on Python (or Ruby, which gets faster at every iteration.)

But those tradeoffs are difficult to assess. Example: which is greener, unoptimized code that took 1 hour to develop or optimized code that took 1 day? I guess it depends on how long that code has to run. And what if the company spending 10x to optimize all code is forced out of business by another company that got all the customers while they were optimizing code? Then all that optimized code is wasted.

Concentrating optimizations in the compiler or interpreter scales better IMHO.

[dom0]

> The same forces are at work on Python (or Ruby, which gets faster at every iteration.)

Python performance has been one step forward two steps back. For example, dict() has significantly evolved over time and some other things became faster as well, but most stuff just becomes slower as more stuff is added or previously native code is replaced by pure Python (see io in 3.0, which was reverted, or import).

Ditto for Python application performance. Python has exactly no zero-cost abstractions, so when something is refactored to use classes or big methods are split up, the result is almost always slower than before.