The programming language market (was Re: [Haskell-cafe] Why functional programming matters

[Paul Johnson]

Evan Laforge wrote:
>
> Java's just wordy like that.  In python you'd say max(foos, key=lambda
> x: x.update_time).  
While this is true, I was also thinking of the typical audience SPJ 
specified: senior technical people and managers.  Most of these people 
have heard of Python and Ruby, but see them as "scripting" languages 
that are not suitable for Real Work.  Most of the ones I have met seem 
to regard a static type system and compilation to native code as 
prerequisites for "real" programming languages (although Java has 
greatly weakened the second prejudice).

More importantly, these people have not read "Beating the Averages".  
They see the programming language market as a Keynsian Beauty Contest, 
in which the judges get rewarded for voting for the most popular 
candidate.  Therefore the trick to winning the contest is not persuading 
the judges that you are the most beautiful, but that you are the one 
that most of the other judges are going to vote for.  Paradoxically this 
is best done by emphasising your similarity with what they already 
know.  The message is "I'm just like her, only better".

In the case of Haskell ways to do this would include:

    * Outline (single Powerpoint slide) a mapping between UML class
      diagrams and Haskell data and class types.  Mention that Haskell
      classes and data types correspond roughly to Java interface and
      implementation classes respectively.
    * Emphasise that Haskell *is* statically type checked, its just that
      type inference means you don't have to declare the type of every
      single thing.  Repeat this point three or four times during the
      talk to make sure it sticks.
    * Mention the covariance type hole in Java and say that Haskell
      doesn't have it.  In Haskell "static type system" means what it says.
    * Hackage does what Doxygen and Javadoc do.  The ones who know about
      automatic documentation will get a warm fuzzy feeling.  The ones
      who don't will find it interesting.  Also mention Hunit.  Mention
      QuickCheck in passing, but don't dwell on it because its not what
      they know.
    * Mention that there is an Eclipse plug-in for Haskell.
    * Talk at length about the Haskell library and package mechanisms. 
      Large projects often have multi-version configuration management
      issues, so talk about how library versions can be selected at
      compile time by a configuration file.
    * Talk about the FFI interface.  Most of these people have big
      important monoliths of legacy code that they don't like to talk
      about in public.
    * Trying to dereference "null" is a significant source of bugs, so
      explain that null references are impossible in Haskell.  If you
      have "x :: Foo" then "x" can never be null; it *has* to refer to a
      Foo object.  If we want a possible null value then we say "Maybe
      Foo" to signal this, and type safety means you have to account for
      possible "Nothing" values.
    * Say "computers are cheap but programmers are expensive" whenever
      explaining a correctness or productivity feature.

The best way to demonstrate the innate productivity improvement in 
Haskell is using numbers.  Haskell projects to re-implement existing 
code routinely report 4-fold or better code reduction.  The 1993 paper 
on Ada vs Awk vs C++ vs Haskell... is still good ammunition, as are the 
GetOpts implementations in C and Haskell.

A lot of this is to demonstrate that the normal development 
infrastructure is actually available.  This is another thing that these 
people expect to see in a "real" language.  Its not that this is 
important for productivity, its just stuff you have to have to be 
considered a "real" language.

Maybe I should write a "Real Programming Languages Eat Lots of Quiche" 
piece.

Paul.