D Tweed
(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/