Agree. There is a world market for maybe five computers.
Ok, I am joking you may be right. But it is notoriously difficult to predict the market for programming languages. had you attended LL2 on [November 9, 2002](http://weblog.raganwald.com/2007/01/where-were-you-on-saturd...), could you have predicted which of the languages discussed would be popular... five years later?
Is it for a programming language startup to make money if you have a superior language? Say you have a programing language that is to Lisp as Lisp was to Fortran, how (if at all) can you make money from it?
It's been tried, eg. Clean, Dylan, or Miranda. Results are not really encouraging, and the language often gets open-sourced after its owner realizes they can't make money off it. And those languages are really nice languages (Dylan is my favorite Lisp variant, and Clean and Miranda are in many ways friendlier versions of Haskell).
Companies tend to have much better luck if the language is attached to a product, either as a scripting language or as part of a RAD suite. Think of AutoCad/AutoLisp, Flash/ActionScript, or Visual Basic.
Do you think that the language you use matters much? i.e. if you have a language that makes you twice as productive as in Arc, would that be a big advantage or a small one? (compared to having money, a good idea or being smart, etc.)
Assuming that a significant portion of your time in a software startup is spent programming, a language that makes you twice as productive means you can try twice as many ideas, or develop the same software and free half your time for finding capital or users, or shortening your time to market by 50%, wouldn't any of these be a significant advantage???
From my experience in most startups (2/3) spend the first 4 months almost entirely on programming. Later stages are obviously more balanced as other activities begin to take the spotlight.
So according to your stats you get a 25% improvement in productivity by using non-Blub language (don't worry as you gain familiarity with non-Blub programming this will actually improve) and that means launching a month earlier.
The only reason to not use a non-Blub language is that you need to write in the Lowest Common Denominator of your team and if the entire team isn't comfortable in a specific language you'd better not use it.
The only exception to the above rule is if you separate your efforts in a very specific way, if instead of using the entire team to build project A, you use part of the team to build tools that help build projects like project A easily and the rest of the team uses the tools the other half created to actually build project A. In which case the tool building group can use more powerful languages without any adverse effects.