I disagree, again for a couple of different reasons. Number 1: you say "eval is optimizeable", but optimizing eval in general is incredibly difficult. It's tru

I disagree, again for a couple of different reasons. Number 1: you say "eval is optimizeable", but optimizing eval in general is incredibly difficult. It's true that you can add optimizations for specific situations. But every time you do so, you expand the surface area of the boundary between "efficient" and "inefficient", and it becomes harder to maintain a mental model of how any given chunk of code will be executed. (For example, in Python, strings are immutable; when concatenating strings in a loop, the intermediate copies can be optimized away but only sometimes, which means that pattern is generally avoided as a matter of good coding style. Tail-return optimization in Scheme is a useful trick that suffers from similar drawbacks, which is probably why you don't see it implemented in a lot of other languages.) I'm skeptical that adding this type of complexity results in a better overall developer experience. Remember, code is written not just for the compiler, but also to be read and understood. And number 2: in practice, most languages don't have multiple competing implementations at the level of complexity you're talking about. When your compiler gets to the point of doing sophisticated JIT optimizations, maintaining it requires a lot of specialized knowledge and experience. It's impractical to fork a project like V8 or Hotspot to add a specific new optimization. So individual runtime environments usually aren't subject to competitive pressure, except from entirely different languages.