Re: Industry versus academia

[Michael Vanier <address@hidden>]

> Date: Mon, 24 Feb 2003 13:36:00 -0800 (PST)
> From: Spencer Schumann <gaucho_puro@yahoo.com>
> 
> > 
> > One thing that I've always hoped would happen (but hasn't yet) is that new,
> > advanced languages would be able to do things that are not merely difficult
> > or tedious in existing languages, but well-nigh impossible.  In that case,
> > and assuming what they do is valuable to industry, I think industry types
> > would rush to hire pointy-headed academics who know about monads and
> > continuations etc., simply because that's the only way the job is going to
> > get done.  
> > 
> 
> Maybe it would be enough for an advanced language to do things that can be
> done in other languages, but do them so much more quickly and provide
> such a better solution in the end than would a conventional language that
> the clear choice would be the advanced language.
> 
> I have read Paul Graham's essay on how Lisp enabled his company to produce
> better online stores faster than anyone else could.  If there were more stories
> like this, I think the industry would take notice that, although they could
> do the same kinds of things with languages like C++, some other language
> could make their programmers so much more productive that it would be insane
> to do things "the old way."
> 

I agree, but in this case all the old arguments apply -- it's only quicker
and better if you have an advanced programmer who knows how to use {macros,
continuations, monads, etc.}.  There are so few of these people that it's
unlikely this will be a big factor in the foreseeable future.  If the
results were dramatically superior (e.g. 1/10 as much code, no bugs, same
performance), then maybe people would notice, but the difference usually
isn't that big.

It's a well-known law of technology adoption that a new technology usually
has to be ten times better than an older one for the new one to overtake
the older one.  With advanced languages, what are we offering?

-- significantly longer learning curve (maybe 3-5x as long in a good case, 
   or infinity if the learner can't/won't handle the new abstractions,
   which is not uncommon)
-- shorter programs (maybe 1/3 as long in a very good case)
-- fewer bugs (maybe 1/3 as many in a good case)
-- slower execution! (maybe 1/2 as fast in a good case relative to C/C++)

Precise numbers vary tremendously for different languages and problems, of
course.  The point is, the balance sheet is not good enough to cause a
massive migration to advanced languages.  Those advanced languages that
have the best balance sheets (ocaml is a good example) are slowly gaining
mind share among programmers.  Until they gain a LOT of mind share, I can't
expect managers to pay any attention to them.

The slower execution also tends to be a show-stopper; many programmers say
"why should I learn this very hard language if the code I end up writing is
going to be *slower*?"  Telling them that they'll spend less time debugging
is not enough of an incentive considering that they have to spend more time
learning.  I know that I much prefer time spent learning to time spent
debugging, but not everyone thinks the way I do.

Mike