>  I'm a Haskell newbie, and this post began as a scream for help. Having
>  slept on it I find myself thinking of Simon Peyton-Jones' recent
>  request for good use cases. Perhaps a frustrated - and doubting -
>  newbie can also provide a data point. If my worries are unfounded (and
>  I hope they are), I think it's significant that to me, today, they
>  seem real enough. Please understand that I'm not being negative for
>  the sake of it - rather I'm describing what Haskell looks like from
>  the outside.

>  Let me put it this way. Imagine that two weeks ago my forward-thinking
>  and risk-embracing boss asked me to evaluate Haskell for the upcoming
>  Project X. Further imagine that she ensured I was able to sit in the
>  corner emitting curses for the whole two weeks, and on Monday I have
>  to provide my report.

>  At this point, two weeks in, I would be forced to say that I have no
>  reason to believe that Haskell is useful for real world tasks. ghc is
>  an industrial strength compiler for a toy language. While remarkable
>  claims are made for it, in practice even the experts are often unable
>  to implement the most basic behaviours, and where they are able to
>  implement, they find that their program has become so complex that
>  they are unable to describe or discuss the result. Likely this is a
>  deep problem, not a shallow one. The Haskell community is in denial
>  over this, leading to phenomenal time wasting as one goes round and
>  round in circles playing word games with documentation. This risks a
>  return of the chronic embuggerance that we thought we'd escaped when
>  Vista appeared and the set of people who would have to write Windows
>  device drivers reduced to Hewlett Packard employees, Joanna Rutkowska
>  and criminals. When people enthuse about Haskell, we should run a
>  program called Cat.hs from the haskell.org website, throw fruit at
>  them and laugh.

>  Strong words, but in all honesty I *want* to believe, and if I would
>  make such a report I imagine hundreds if not thousands would say the
>  same thing. I'm hoping I'm wrong about this, and what's actually
>  needed is some work on communication (perhaps from a production
>  programming point of view, which I'd be keen to help with).

>  What got me started with Haskell was the video of an Intel employee
>  holding a Teraflops in his hand. I still remember the very silly
>  September 1991 edition of Scientific American, which asked if a
>  Teraflops would *ever* be built. What a stupid question! Stack up
>  enough VIC20s and eventually you'll get a Teraflops. The question
>  should have been "when". Now it's the size of a CD, and only 80 cores
>  are needed. Unfortunately keeping 80 cores running is tricky. I know
>  this from writing some heavy parallel stuff in the mid-90s. It was all
>  quite clever in it's day. Chuck bloated and unguessable CORBA, do
>  something light with TCP/IP (Beuwolf took that to extremes). Neat
>  linkage like rpcgen gave C, so that I could run fast on an SMP Sequent
>  with 30 cores or on a floorfull of about 70 Sun pizza boxen at night.

>  Unfortunately despite having a nice framework, tracing rays is still
>  hard (the rays and medium were... interesting). Making a problem
>  parallel required a sneaky and dedicated person's sincere skull-sweat.
>  Worse, the solutions so produced had a horrible structural instability
>  about them. Just a small change to the requirement could require a
>  computed value where it wasn't needed before, so that it resulted in
>  big changes to the implementation. The skull-sweating would be needed
>  all over again. (Remember that the big point about objects, which e.g.
>  Booch always emphasized, was that a well chosen set of classes maps
>  well to the domain and so reduces such structural instability.) Even
>  then, it was devilish hard to keep 70 "cores" busy.

>  So watching the Intel guy got my klaxons going. We now need to be able
>  to do parallel with ease. Functional programming just got really
>  important. It's years since I last played with Scheme, but I quickly
>  moved on because I could see the "which Scheme" problem becoming a
>  millstone round everyone's necks outside of research contexts. Ditto
>  Lisp. So Haskell. Grown-up compiler, one standard and (apparently) a
>  decent corpus of example code and tutorials. I might be an imperative
>  programmer, but I do lapse - for example I find it very easy to
>  generate swathes of cross referenced documentation using m4. My head
>  goes kind of weird after a few hours, such that m4 seems sane and it's
>  the rest of the world that's ungainly, so maybe it should be banned
>  like DMT, but I like it. I felt able to enter the functional world.

>  I'll omit the first week of suffering, which I see is a well
>  documented rite of passage. (Although most evaluators will have left
>  the building by the end of week one so it's not helping popularity.
>  Perhaps there could be Squires of the Lambda Calculus who haven't done
>  the vigil, mortification of flesh and so on?) Eventually a 3 page
>  introduction on the O'Reilly website together with a good document
>  called "Haskell for C Programmers" got me to the point where I could
>  access "Yet Another Haskell Tutorial", and I was away... for a bit.

>  After a while I'd written some malformed horrors as answers to
>  exercises, and was telling myself that it's probably just an edge
>  effect - deep within a real Haskell program the ugliness would be
>  invisible, tucked away in Ugly.hs. Then I discovered wxHaskell and got
>  very excited. I really like wxWidgets, and I know it well. If I could
>  play with some Haskell which manipulates wxWidgets I'd progress very
>  quickly! I even have a recent C++ wxWidgets  program which was
>  annoying me as I wrote it because of the boilerplate. Great! I can
>  play with type inference and mutter "about bloody time" with a smile
>  on my face. Eventually I got a mix of wxWidgets 2.6.3, wxHaskell from
>  darcs, ghc 6.6 running on my Mac, almost exactly as that permutation
>  was described on the website, and I was off.

>  Within a few hours I had a nice frame, with 10 text controls and
>  legends populating it. It already took less lines than C++, and then I
>  discovered how to bundle all the text controls into a tuple to pass
>  them around, and define some "getters" to access the tuple. My line
>  count shrunk to what it "should" be - that is, something Kolmogorov
>  wouldn't laugh at but is unattainable in C++. I had an onOpen which
>  popped up a dialog and got a filename from the user, with all the
>  properties filled in right. I proved that I could update the values in
>  the text controls from the onOpen. Great. Next, translate the bit that
>  says (pseudocode):

>   if(attempt_file_open)
>     if(attempt_file_read)
>       process

>  That's it. No fancy, complex error messages. Just check the error
>  returns and only proceed if I have something to proceed with. Like
>  grown-ups do. I *will* check my error returns. I have tormented too
>  many newbies to *ever* consider doing anything else. If I cannot check
>  my error returns I will not write the program. This is production
>  programming 101, and I suspect that there's a real issue with
>  priorities between the traditional Haskell community and production
>  programmers.

>  So the time of madness began. I could find examples which did:

>   if(attempt_file_open)
>     attempt_file_read
>     process

>  Which is useless. Other examples did:

>   attempt_file_open
>   if(attempt_file_read)
>     process

>  Which is also useless. So I'm looking through the wxHaskell examples.
>  They're all contrived, using very high level functions to (for
>  example) read a complete image structure from a named file, which as
>  one function had one possible source of errors. I go back to scanning
>  and Googling like crazy. Eventually I notice a bit in "Yet Another
>  Haskell Tutorial" - page 65 - which introduces "bracket", immediately
>  explains that it is useless for my (very common) need, and refers the
>  reader to Section 10 - "Advanced Techniques". The author of this
>  excellent document hasn't yet written Section 10. I wonder why. I
>  pause to examine bracket some more. I really can't tell if the
>  "always" clause gets called if the initialization fails. From the use
>  with file opening it looks like it isn't (or the handle to be closed
>  would be invalid) but that wouldn't help if the initializer had two
>  steps, e.g. called socket(2) and bind(2). This is the kind of thing
>  good production programmers get really het up about.

>  I'm still grovelling through reams of stuff, trying to find out how to
>  open *and* read a file in a grown up way, and I find various programs
>  on haskell.org. There's an implementation of cat(1)! That's the thing!
>  A file concatenator must be able to open *and* read it's file. Eagerly
>  I download it. Curiously there doesn't seem to be any error handling.
>  I compile it and point it at a non-existent file. The program crashes.
>  Horribly. So much for Cat.hs. I feel glad I hadn't been able to cope
>  with the video of Simon Peyton-Jones OSCON talk, because the camera
>  operator kept filming his face while he's gesturing at the specific
>  line of code he's talking about with a pointer! After seeing Cat.hs do
>  essence of FAIL just opening a file, claims that Haskell could serve
>  as a scripting language suitable for the crew of the Black Pearl in
>  yonder corner to use would pain me.

>  Now I'm getting cross and turned off the whole business.  I've been
>  here before, grovelling through reams of stuff, trying to find
>  something out while each example is contrived to side-step the
>  problem, half-baked and useless, evasive or referencing non-existent
>  documentation. All I need to make the experience complete is a certain
>  firm's trademarks gratuitously embedded in the text at least once on
>  every line. Then I'd be nauseous by now too.

>  Finally I found an uncommented example with no discussion called Hedi.
>  This seems to be doing exception handling, but what it is doing, how,
>  why, what can raise them, so on and so forth would presumably be
>  covered in the "too complex to describe" bit of "Yet Another Haskell
>  Tutorial". I tried to understand it from first principles, looking at
>  the Type theology for the exceptions and various calls, but while I
>  have the cup of tea I lack the necessary Total Perspective Vortex. I
>  felt no confidence trying to even cut and paste it.

>  So question number one: Please - how do I do this?

>  Somehow I doubt that wrapping the complexity of opening a file *and*
>  reading it in a grown up way and then documenting idioms that use the
>  wrapper would help. If it would, the wrapper and doco would already
>  exist. That implies that the complexity doesn't stack. If I get to the
>  point where I can open a file *and* read it in a grown up way, and
>  then I need to (say) verify a version number from the file:

>   if(attempt_file_open)
>     if(attempt_file_read)
>       if(version_ok)
>         process

>  Would I need to completely restructure my program? I suspect so. But
>  it's worth bringing it up. Question number two: Might wrapping the
>  indescribable complexity of the most basic operations make it possible
>  to publish and discuss some idioms which accomplish them? I'd be quite
>  happy with a voodoo idiom for now. I know someone who (20 years on)
>  still doesn't understand pointers to functions. She still uses
>  qsort(3) by rote, and it works for her. That will do for beginners.

>  My biggest worry is that there's a really bad trade-off going on here.
>  Sure, the structural instability of imperative parallel algorithms can
>  be reduced, but at the cost of adding structural instability to
>  everything else! TANSTAAFL and the lump in the carpet always goes
>  somewhere. I read one chap who complained that in order to add one
>  single line of debug he had to completely restructure his entire
>  program, and then the line count was as big as an imperative language
>  would be. Plus a world more complex I bet. It's this TANSTAAFL that's
>  making me a non-believer.

>  So question number three (rhetorical): What would have happened if
>  Codd and Date had tried to make SQL a general purpose programming
>  language? Sequential file handling would have been impossible for all
>  practical purposes, so no-one would have got the benefits of set
>  theory (oh sorry relational calculus) and our most successful
>  intentional language would have been stillborn. We'd still be using
>  CODASYL.

>  Which leads to question number four: Why not do one job well? Limit
>  parallelism to a single SMP machine where there are no comms to fail
>  and failures which do occur will justify the OS chucking the whole
>  process. Make an interface so that Haskell can be called from C++ or
>  Java, with a simple IDL that can marshall nested structs, list<>s,
>  map<>s and vector<>s in and out. Then we can get on with writing
>  ambitious pure computations with names like sortOutRawCatScanData,
>  tersely and in easily parallelizable ways, like we embed SQL to get
>  certain specialist jobs done.

>  Then when all this was going on, question number five appeared: What
>  the hell are these "lightweight Haskell threads"? Are they some kind
>  of green threads running non-preemptively inside a single OS thread?
>  Are they OS threads that could run concurrently on multi-core
>  hardware? If they are green threads (and it sounds like they are) then
>  this is all an academic exercise which has no production application
>  yet.

>  I'm still hoping that this is solvable. That the instinctive
>  priorities of production programmers are just different to those of
>  researchers, and in fact it *is* possible to open a file *and* read
>  it, checking *both* error returns, without being driven insane. If so,
>  I sincerely suggest an example or two, like the small but well formed
>  programs in K&R, Stroustrup or Gosling saying things like:

>   if((fp = fopen(...)) != NULL)
>   {
>     if(fgets(...) != NULL)
>     {
>       printf(...);
>     }

>     fclose(...)
>   }

>  Best wishes - and still hoping I'm wrong after all

>  Alan Carter

>  --
>  ... the PA system was moaning unctuously, like a lady hippopotamus
>  reading A. E. Housman ..."
>   -- James Blish, "They Shall Have Stars"
>  _______________________________________________
>  Haskell-Cafe mailing list
>  Haskell-C...@haskell.org
>  http://www.haskell.org/mailman/listinfo/haskell-cafe