"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.
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…
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.
>>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.)
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?
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.
I've been console game developer for quite some time, and async stuff has always been around for us (but not so network oriented for the stuff I was doing - streaming sound, file I/O, DMA from one cpu to another, etc.)
But If I have to direct it, then precooking your data, so data once loaded only pointer mixup is needed was the basic to get streaming stuff in a game (Spiderman-2, Ultimate Spiderman, Spiderman 3).
Then comes stuff like ability to cancel async jobs, and off course start several at the same time, giving some more info to the underlying code - which should be done first. I can go on technical details in few pages.
What exactly is he talking about?
However, your perspective as a console game developer is highly interesting to me - care to write a bit more about it?
*) KV stores, node.js hating or petting, the next big X, iPhools, Fezbook, little boyz anonymous - we are the rulerz of the world - hacking, "old tool" in a "new language" thing
(OK, I am enerved ...)
And that clarity, readability and common idioms of a language matters more than its runtime, and that 100k of Java or Javascript code is not the same pile of crap as 100k of Python or Ruby code, assuming that it is not specially obfuscated. ^_^
Fast prototyping that some stacks (VM+frameworks) provide has no correlation with real production environments where you must consider a system in terms of data-flows, content types, separate storage for different types and flows of data, different levels of caching, and so on.
And, of course, in most cases, serving a content from a file on modern FS with help of a little C code is much faster end more efficient than serving the same content with some cool VM involved. ^_^
