That's exactly it (and it's a message we've been hearing over and over for the past decade at least -- "worry about being productive, if it's slow, Moore's law will fix it for you in a few years").
The thing is, in some cases, all the productivity ends up costing a lot more. For small shops it will not be evident, but for bigger ones trying to scale, it'll be a major area of improvement (to use less cycles).
And that's OK... comes down to using the right tool for the right job, matching the skills of your developers with the challenge, how fast you want things delivered, etc, etc, etc.
I think the major issue people see is that when all of that slow programs are looked from a 10,000 feet view as a single thing, it looks like a damn waste of resources. Thus comments like "computing (as a whole) in the last X years has been terrible", etc. We can delve into programmer culture, lack of skills, people not caring about wasting resources, etc, etc, etc.
I think the solution is better tooling. Let the programmer be productive, deliver things fast, etc, but build something more intelligent that will strip it down to only the necessary bits and deploy.
I find this hard to believe. Any time people write systems in a dynamic language, they inevitably run into issues as they scale, ending up wasting money (computers, electricity) and a lot of user time. This usually results in rewriting things over and over.
Performance is always important. If you can solve a problem in 10% more time using a performant language, then it makes sense to do so, and I've seen few problems that I can express in Python or Ruby (painfully slow) that I cannot express in C++ (highly performant) or Scala (moderately performant) in roughly that amount of extra time.
Time is not perfectly fungible. The only way to save time early on (prototyping and delivering products early on) may result in spending a lot of time later on.
Do you have any actual data to back your wild assertions? Entire domains of computer science are dedicated to productivity languages and many are widely used with great success and little or no overhead relative to C. (edit: for example scipy)
I was stating an opinion based on my experience. I don't deny that tools like SciPy are very useful for experimental programming. However SciPy and Matlab are exceptions, where the end-user of the program is also the programmer, so the developer experience IS the user experience.
In most cases, when you are a professional developer, you are not the end-user of your product. In these cases, deliberately choosing a less performant language for the sake of developer productivity can mean you end up penalizing the end user.
Good point, and I think that that's why languages like Java and C# are very popular these days - they hit a good balance between performance and developer productivity.
The danger with the "speed doesn't matter" attitude is that you end up with a 10x slowdown due to language choice, and then another 10x slowdown due to inefficient implementation, and you end up with a 100x slowdown, which might actually be significant even in situations where speed doesn't matter that match.
The sentiment you just wrote is one of the chief inspirations for the TechEmpower Framework Benchmarks project that I'm part of. Today, we routinely see huge amounts of computational horsepower evaporated in the name of developer efficiency. Yet the modern web development ecosystem is so plentiful and diverse that there are myriad high-productivity platforms and frameworks that exploit computational horsepower rather than squander it.
My opinion is that investing the modest effort to select a high-performance platform and framework gives you the freedom to write inefficient application code first and to optimize later. It is the process that allows you to avoid the most expensive kind of premature optimization I've seen by postponing optimization until well after an application's concept has been vetted by its first several thousand users.
