TITLE: Why Do Academic Research in Programming Languages?
AUTHOR: Eugene Wallingford
DATE: May 11, 2016  2:45 PM
DESC: 
-----
BODY:
When people ask Jean Yang this question, she
<A HREF="http://jxyzabc.blogspot.com/2016/05/why-its-not-academias-job-to-produce.html">
   reminds them</A>
that most of the features in mainstream languages follow
decades of research:

<BLOCKQUOTE><EM>
 Yes, Guido Van Rossum was a programmer and not a researcher
 before he became the Benevolent Dictator of Python.  But
 Python's contribution is not in innovating in terms of any
 particular paradigm, but in combining well features like
 object orientation (Smalltalk, 1972, and Clu, 1975),
 anonymous lambda functions (the lambda calculus, 1937), and
 garbage collection (1959) with an interactive feel (1960s).
</EM></BLOCKQUOTE>

You find a similar story with Matz and Ruby.  Many other
languages were designed by people working in industry but
drawing explicitly on things learned by academic research.

I don't know what percentage of mainstream languages were
designed by people in industry rather than academia, but the
particular number is beside the point.  The same is true in
other areas of research, such as databases and networks.  We
need some research to look years and decades into the future
in order to figure what is and isn't possible.  That research
maps the terrain that makes more applied work, whether in
industry or academia, possible.

Without academics betting years of their career on crazy ideas,
we are doomed to incremental improvements of old ideas.
-----