[EwanToo]

The key piece for me is:

"If you could choose n where your language is n times as slow and you are n times as productive with this language were both true which value of n would you choose?"

It's absolutely true - For me, if I can build an app 5 times quicker than before, and the amount of time involved isn't trivial (i.e. a few hours) then then development time is vastly more important than the end speed of the code.

Execution speed issues can always be solved - it might need more hardware, better coding, or even a complete rewrite, but it's fundamentally something that can be fixed.

That's not to say that your choice of stack and architecture isn't important, it's just that the language itself is only a small part of that decision, and most architectures (and most performance requirements) can be achieved in most languages.

[mhd]

The problem I see with this premise is that for any reasonable language/environment and actual, real-life problem, n will hardly ever be n.

Most of the time, your productivity increase p will be equal to a slowdown s multiplied by a factor f.

So the big performance for lots of problems is: How large can f get for you? Sometimes you can't really pay the price (e.g. writing 3D engines in tcl), sometimes the money factor m will make more than up for it (i.e. more programmers, more instances on more servers etc.).

Never mind the actual size of p. Given the mentioned hodgepodge of dynamic languages, I'd expect it to be pretty small unless your environment isn't up to it, i.e. you have to write modules. Then even hyper-mega-insta-lisptalkscript will be much slower than CPAN.

I'd say that even for C/C++ vs. dynlang f will be pretty high, but again, it often doesn't matter that much…

[6ren]

It also depends on how fast the app needs to be, and how far your computer is (e.g. the answer might have been different 20 years ago for the same task) - it would be nice to express the question differently, to make it invariant of these aspects.

For "interesting" tasks (in a research sense), speed is limited by combinatorial explosion. Finding an algorithm/approximation/heuristic that avoids or reduces that is the only real solution - because faster languages, like faster computers, can only give you linear speed up.

[berntb]

>>"If you could choose n where your language is n times as slow and you are n times as productive with this language were both true which value of n would you choose?"

>>if I can build an app 5 times quicker than before, and the amount of time involved isn't trivial (i.e. a few hours) then then development time is vastly more important than the end speed of the code.

I would set n somewhere between 50 and 100. Then benchmark the resulting programs and rewrite bottlenecks in C. (Just think about it; years of productivity in a month! Then another few months to optimise the prototype.)

[adgar]

This is pretty good advice in an entrepreneurial forum where people are most interested in quickly prototyping an idea for the web, showing it to people and finding where to take it and how to change the idea, getting people to look at it who might throw some cash at it, and so on. You're not concerned about high performance or even really quality engineering yet, all the "soft" stuff is way more important.

I'd question its wisdom for engineering-heavy work.

Edit: Also, it makes a bit more sense to posit this:

If you could choose n where your language is n orders of magnitude slower and you are n times as productive with this language were both true which value of n would you choose?

[EwanToo]

For engineering-heavy work (I work in telecoms where a fair bit of work goes into reliability), the choice of language is still pretty low in the importance compared to other decisions.

The language can make things easier (and quicker) to do things the right way, but it'll always be possible to do the wrong thing.