John Hughes writes
> (...)
> encountered all too many students with the impression that functional
> languages are OK for toy programs, but for real work you need
> C/C++/Java/whatever. They can easily get that impression, paradoxically,
> because of the success we functional programmers have had in introducing
> functional languages early in the curriculum! Students believe functional
> languages are good for toy programs because they learned them when they could
> only write toy programs. If they gradually discover that, in fact, the very
> language they have learned is also used for very serious applications then
> there's a chance of countering that impression. If instead they discover that
> they were quite right, the language they have learned is considered a toy even
> by functional language researchers, then I don't think we have much chance. So
> personally I am dead against designing a `Noddy Haskell' which is clean enough
> for teaching; let Standard Haskell be clean instead!
In essence this sounds to me like `let us design a serious language
which is simple to teach *and* which is worth learning'. I strongly
support this point of view. The goals of the Standard Haskell
committee, however, only reflect the aim of simplifying the current
Haskell design. [As Will Partain puts it `The "make it easy for
students" people are running amok (...)']. While simplicity is
certainly a desirable goal it is not nearly as important as developing
a serious language. To turn Haskell into a serious language, several
*extensions* are absolutely necessary:
o Haskell's type system must be improved: multiple parameter type classes
are a must (*). It is currently not possible to develop a *clean* library
of data structures (collection classes) and computational structures
(monad transformers). A well-developed library would certainly contribute
to Haskell's seriousity. [This point has already been made, I just
wanted to stress its importance.]
(*) One should even consider to adopt each of the recommended extensions
in the Haskell workshop paper "Type classes: an exploration of the
design space".
o Lazy state threads with mutable variables and mutable arrays are a must.
There are a couple of algorithms and data structures for which no purely
functional solution is known to exist. Efficiency is at a premium, so
students will certainly classify Haskell as a toy language if the
complexity gap cannot be bridged by means of an imperative sublanguage.
[Furthermore it is not possible to develop an *efficient* library of data
structures.] If the adoption of lazy state threads means that explicit
quantification is also desirable, adopt it too!
o Perhaps primitives for concurrency should be standardized,
but I'm not an expert here. A language which does not support GUI
programming is probably considered toy, as well.
o Types such as Packed Strings or Packed Booleans (ie bitlist) are missing
in the Standard Library.
Could one otherwise convince students that Haskell is not an academic
playground? I believe not.
Ralf Hinze
