[Haskell-cafe] Doubting Haskell

[Alan Carter]

Greetings Haskellers,

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"