newbie conceptual question [from haskell list]

[Alastair David Reid]

D Tweed <tweed@cs.bris.ac.uk> writes:
> (I feel like a bee-keeper at apocryphal dinner party where it's said
> that by the laws of physics bees can't fly: all the other parties in
> this discussion are much more technically competent and well-read
> than me and yet my actual experiences don't seem to accord with
> their conclusions :-) )

As a fellow bee-keeper, let me say I'm in complete agreement with you.

  The problem is not that the semantics of C is incomplete or that the
  semantics of C is complex but that it is hard to use effectively.

I've talked with many non FPers about the relative merits of C and
Haskell (or ML) and found that:

1) Arguments that C's semantics are complex are so implausible or
   abstruse ("honest, you don't want to go messing with those
   assignment statements - they'll just make your life miserable")
   destroy my credibility.

2) Arguments that C is incompletely specified lead to exactly the same
   arguments we've seen in this discussion about their being a
   portable subset which suffices for most code we write.

So, while there's an element of truth in both arguments, it is
completely unproductive to use these arguments.

Much better is to concentrate on Haskell's strengths than on C's
weaknesses.  A great starting list is John Hughes' "Why FP matters".
Then, depending on audience, show them list comprehensions, throw in
Phil Wadler's "Theorems for Free", talk about equational reasoning,
show them what Haskell's standard libraries provide (contrast with C
and C++ provide or how useful their libraries are in practice), talk
about embedded domain specific languages (parser combinators, Fran,
etc.), show them a binary tree implementation, show them a complete
compiler written in N lines of code, show them Haskell programs with
GUI's (to dispel the belief that Haskell can't interact with the
outside world or that Haskell can't use existing libraries written in
other languages), show them FFT written in Squiggol, show them a
derivation of FFT (from the Discrete Fourier Transform) in Squiggol,
...

At least half of these rely on Haskell's simple semantics.  (This is
indirect in the case of the standard libraries - the simple semantics
means that I don't need multiple versions to deal with different kinds
of side effect or exception-throwing behaviour).

I also talk frankly about the relatively weak state of debugging
support and the fact that I have no effective way of reasoning about
space usage or execution time in Haskell programs (just tools for
examining it empirically).  (These are significant obstacles since I
currently work in an OS group with a bias towards Real Time Embedded
Systems :-).  Fortunately, they let me write my compiler in Haskell.)

-- 
Alastair Reid        reid@cs.utah.edu        http://www.cs.utah.edu/~reid/