The programming language market (was Re: [Haskell-cafe] Why functional
paul at cogito.org.uk
Sat Jan 26 10:45:36 EST 2008
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
* 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"
More information about the Haskell-Cafe