> Instead of starting out with languages and tools that will almost guarantee slow software, maybe we work on designing languages that provide productivity while at the same time encouraging leaner software.
The key point I'm making is that you need to consider the whole system/environment; developers aren't choosing "slow languages" because they simply don't care about performance, they are choosing those languages because they are more productive in other dimensions, and the return on that productivity gain exceeds the return on optimizing for more speed.
> Also, faster software can often provide opportunities for new features that weren't possible before.
Absolutely -- we do see performance improvements happen, when they give users something that they actually value; for example the reason IntelliJ triumphed over Eclipse was by doing more sophisticated compiling/parsing in real-time, which was only made possible by significant performance optimizations.
The key point I'm making is that you need to consider the whole system/environment; developers aren't choosing "slow languages" because they simply don't care about performance, they are choosing those languages because they are more productive in other dimensions, and the return on that productivity gain exceeds the return on optimizing for more speed.
> Also, faster software can often provide opportunities for new features that weren't possible before.
Absolutely -- we do see performance improvements happen, when they give users something that they actually value; for example the reason IntelliJ triumphed over Eclipse was by doing more sophisticated compiling/parsing in real-time, which was only made possible by significant performance optimizations.