This is not terribly surprising. The concepts behind the static type system of ML - from back the late 70s - are still "groundbreaking" for industry programmers. Virtual machine-based languages and automated memory management were done several times over, but they were only taken seriously after being massively marketed through Java.

I know a certain Unix junkie. She has chosen to stick to the old standbys of C and Perl. She doesn't want to even look at revision control yet - "too complicated" she says. Fortunately, this is just a hobby right now and she isn't going out and doing commercial work in such a state, but if someone who ostensibly is enjoying themselves programming isn't willing to go out and play with languages and tools, I doubt the situation is much better for a commercially-driven developer.

As long as our development environments are perpetually being replaced by new ones, I think it will be an uphill battle to get the research tech to the mainstream. New environments are almost always crude and barebones. By the time they're mature, people are already starting to move on to the next one. We can only hope for some stability in the future; at that point, the dynamics of programming may take a major turn for the better.

As in mathematics, some of the best software research can be very hard for practitioners to recognize, appreciate, learn and apply.

Part of the reason is developers rarely get the opportunity to try out research ideas until enough success stories about them become mainstream. I remember looking into Erlang years ago around the time some folks I knew at Sendmail were looking into it but unfortunately nobody at my company would use it. It was too weird at the time. But if I were working on the same thing today I could easily reassure people by pointing to things like Amazon SimpleDB.

These days I'd like to see more mainstream publications about checking and reasoning tools like SPIN[1] and Coq[2] and techniques like Proof Carrying Code[3] so that I can convince my management and peers to try them out.

1- http://spinroot.com/spin/whatispin.html

2- http://en.wikipedia.org/wiki/Coq

3- http://en.wikipedia.org/wiki/Proof-carrying_code

Well, one of the best research in compilers and languages, IMHO is applying static analysis and constraint solvers to practical systems (e.g. C) find bugs and/or automatically generate tests to find bugs:

http://www.stanford.edu/~engler/

Coverity is a startup from such research. The new Klee paper is a good read as well.

Another way to predict the future is to realize that it takes a very long time--about 10 to 20 years--to get a technology out of the research lab and into everyday life. It's very difficult to get brand new ideas out in less than a decade; in the case of the transistor, it took almost 25 years. No matter what you do, it may take several companies, several different groups of people, several different areas of venture capital funding and more before you get something back. http://www.ecotopia.com/webpress/futures.htm

Java took a bunch of academically proven ideas, and put them together in a way that was workable for industry (and yes you're quite right, also marketed as an web applet-language, which is remarkable for Java's failure at it).

Haskell (for example) first appeared in 1990. 1990+25 = 2015.

Possibly, what we are seeing is just the historical rate of technology transfer.

That just shows that "the best research in compilers/languages" doesn't address the important problems as perceived by the software community.

I believe that the author is ignoring the importance of libraries for commercial work when bemoaning the slow uptake of lessons learned in language research. Learning a new language does not take a long time in comparison to the amount of time required to learn the APIs necessary to be really productive.

Perhaps the people who do the "best research" in compilers/languages simply suck at marketing.

Also, and I know this might be a heretical thing to say... maybe the ideas just aren't that good.