"Most programmers only know how to program in obsolete ways"
-- This actually illustrates for me the problem of "progress" in programming approaches. Any "new and better way" that can't be grasped quickly and easily by a good fraction of programmer isn't really "better". The path to new systems flows along the line of least resistance. A better programming system is one which can flow close enough to the lines of resistance that most programmers can adopt it.
There can be a huge barrier to entry for new stuff. A new editor is likely to be ignored unless it 1) has compelling new ideas, and 2) can already do most of what e.g. Emacs can. Likewise, any new operating system has the burden of porting over numerous major programs, protocols, etc. that people expect.
Suppose someone created a completely new system, which did NOTHING that the old systems did BUT could be learned quickly and easily, had tremendous power and fullfilled a new or existing need. Then, that system would be adopted in very short order. Ruby-on-rails is far from ideal but it shows the principles. Maybe the users of older approaches would poo-poo it but that wouldn't matter.
Systems that attempt to be an incremental improvement on existing system with large user bases are the least likely to be accepted.
The problem one can see with ACADEMIC research is that this research has lost interest in easily grasped and used method, systems and approaches.
Technology choices for the majority of programmers are often not based on technical merit alone, but rather are based on historical influence (legacy systems, existing libraries, interoperability, et cetera,) managerial perceptions (nobody gets fired for picking Java, it is too hard to hire good Rubyists, the smalltalk vendors are unstable, et cetera) and cost.
