If it takes me 3 months to deliver a given program in Clojure and 6 to deliver its Java equivalent, the Clojure one already has 3 months of lead. Assuming the Java one is twice as fast, it'll take 45 days to catch up.
Development time is expensive, computers are cheap and get twice as fast every year or so.
While a long startup time is annoying, it can certainly be optimized out if someone focuses enough attention to the low level aspects of the runtime.
I get what you're saying, and you're sort of right, but it's still interesting to figure out why that startup time is so slow, or what other things slow it down. That talk from Daniel Solano Gómez about Clojure on Android was pretty interesting in that regard. I would want to encourage that kind of investigation, although this blogpost has a terrifically flamebait title.
> Development time is expensive, computers are cheap and get twice as fast every year or so.
It's a bit funny that you're citing Moore's law when Clojure is specifically designed to overcome its breakdown and get out ahead of that lagging curve. (Paraphrasing an early talk from Rich Hickey: "The hardware guys are punting!!")
You can turn that right around as fuel for your original point, that Clojure and it's approach to concurrency buys you tons of developer productivity, compared to whacking about in the weeds with Java. I totally agree there, those higher level features are valuable and worth something, but they do not cost nothing.
single thread performance isn't increasing that quickly, but machines like the Xeon Phy should be rather sweet for highly threaded (or processed) apps. Also, if we can make GPUs run Java bytecode, we would unlock a whole lot of GFLOPS that are just pushing pixels now.
No it doesn't. Development time is a one off (for a given feature set). Usage is recurring, so savings in running time catch up and eventually dwarf development time.
But I don't think this calculation makes much sense in the first place. It's simply not that linear and depends on many other things, for instance whether it's a throughput or response time problem, the relative value being the first to market versus being the best, etc.
Time running the app is both irrelevant compared to the time it takes to develop it. Also, as long as the app offers the answer quickly enough from the user's perspective, fast enough is fast enough and being able to iterate twice as fast as your competition is the ultimate advantage.
Making it fast enough from a user's perspective comes at a cost though (where it is possible at all). If you have many users and you have to pay that price for each one, it becomes very expensive.
All I'm saying is that at some point it becomes way more expensive than paying developers to optimize or rewrite in a faster language, which is exactly why Google and Facebook are doing so much work in C++, not exactly a language known for developer productivity.
And obviously there are many places where you can't scale your way out of a response time or battery usage issue because you're not the one buying the machine.
So I totally disagree with your assumption that developer productivity always trumps runtime efficiency. It is also my experience that the productivity advantages usually ascribed to some (mostly dynamic) languages is way overblown. But that's another debate.
Even if I have to rebuild part (or all) of the application in some future moment, the initial productivity boost is worth a lot. Rebuilding a program that is already running is usually far less painful than building a fast one from scratch. At least the developers will have a test suite they can use to check whether their version is correct. And how much faster.
I agree there are cases where only the leanest and meanest code will do, but my point is that those cases are very rare.
That was the point. Execution time is mostly inconsequential when compared to things like development time and competitive edge provided by the language you're using - you know, the actual money makings factors.
If it takes me 3 months to deliver a given program in Clojure and 6 to deliver its Java equivalent, the Clojure one already has 3 months of lead. Assuming the Java one is twice as fast, it'll take 45 days to catch up.
Development time is expensive, computers are cheap and get twice as fast every year or so.
While a long startup time is annoying, it can certainly be optimized out if someone focuses enough attention to the low level aspects of the runtime.