Learning Haskell and FP

[Michael Zawrotny]

Paul Hudak <paul.hudak@yale.edu> wrote:
> Thanks to everyone for their comments regarding "GITH".  I conclude
> that:
> 
> -- it is useful to people who have previously programmed in Scheme
>    or some other functional language
> -- it is a difficult read for those not familiar with FP concepts,
>    and certainly not appropriate for novice programmers
> -- given the dearth of free documentation on Haskell, it serves a
>    useful purpose
> -- the title is misleading
> 
> Also thanks to George Russell for reminding me that the intro states
> clearly that:
> 
> > Our goal is to provide a gentle introduction to Haskell for someone 
> > who has experience with at least one other language, preferably a 
> > functional language (even if only an "almost-functional" language 
> > such as ML or Scheme).

GITH was a bit much for me.  However, I have a slightly different
take on the reason why.  My original background (undergrad
and PhD) is in biochemistry.  Most of my programming, etc. is
self-taught, although I got through about third year's worth of
course work for an undergrad CS degree while I was at my previous
job.  In the course of teaching myself various things, I dabbled
in both scheme and common lisp and more recently in SML and OCaml
(and obviously Haskell as well).

The reason that I found GITH difficult wasn't that the concept
of programming with functions/functional style was new to
me.  What got me was that the concepts and notations were much
more "mathematical" than "programmatic".  In my explorations
of various languages, my experience with introductions to
scheme/CL has mostly been that they tend to show how to do
things that are familiar to imperative programmers, plus all
of the things that you can do with functions as first class
values.  With intros to SML, OCaml and Haskell, there is a
much greater emphasis on types, type systems, and provable
program correctness.  The main difference being the emphasis
on doing familiar things in a better way followed by some new
things (scheme/lisp intros) versus throwing you into what may
be completely uncharted territory (formal type systems, monads,
functors) in SML/OCaml/Haskell intros.

There also seems to be the tendency to assume that the meaning of
a type signature like
 map                     :: (a->b) -> [a] -> [b]
is inherently obvious.  To someone unfamiliar with HM type
systems and whose last course in mathematics was more than a
decade ago, it might as well be greek.

The thing that I would most like to see would entitled "A
Practical Guide to Haskell" or something of that nature.  After
working through some of the online tutorials and a fair portion
of "Craft of Functional Programming", I thought, "Ok, I do most
of these excercises, and am comfortable.  Let's try that utility
program I've been thinking about for the last couple weeks."
What I ran into was scenarios like the ones listed below (some of
which have since been solved):

1.  How the #$!? do I read some data from a file.  Good, I've
got the data, now I can work on it.  Nope, now I have an "IO
thingie" whatever that is, but all of the standard functions want
a regular "thingie" now what?

2.  I need to do some XML processing.  Go to haskell.org, find
links to HaXML and install it.  Try to use it...  Nope, no
documentation that is understandable to me.  Ok, look at the
source to the one demo program that does something close to
what I want.  Nope, it was written in the "It's functional and
therefore self-documenting" style.  (Note, this is not intended
to be a shot at the implementors of HaXML.  It is clear from
the description of the library and the functions of the included
programs that the library is complete and well thought out.  I
am also sure that someone already fluent in Haskell who is used
to looking at type signatures to deduce the purpose of a function
can do sophisticated things with it.  My only criticism was that
it wasn't approachable to someone who is starting to feel somewhat
comfortable with Haskell and wants to "do" something useful with it, 
as opposed to exercises from a book or tutorial.)

3.  I gave up on Haskell for that particular utility and wrote it
OCaml.

One is tempted to come to the conclusion that Haskell is not
suited for "normal" programmers writing "normal" programs.  I
don't necessarily think that is true, but it is difficult for
someone who is used to imperative/OO style programming and has
dabbled in impure functional languages.

To be fair, I had almost the same reaction to SML/OCaml when I
first encountered them.  Working on Haskell and reading "Craft"
made it much easier to go back and look at them again.  It's
probably that in the spectrum of imperative ----> functional
languages, scheme/CL are farther to the left than SML/OCaml,
which is still left of Haskell.  In the case of someone like me
coming from C, C++, perl, python, etc., the extreme right is
inherently much less familiar territory than the middle ground.
The tendency of the written materials to get more mathematical as
one moves to the right also exacerbates the problem.

That was my reaction when I read GITH and some of the other
introductory material around.  A lot of this probably is
more relevant to the people who are thinking of writing
a lower-level intro than it is to the next edition of
The-Document-Formerly-Known-As-GITH.

My plea is for people include introductory material for people
who know how to program in general and want to do mundane tasks
in Haskell as opposed to C, Python, or whatever other language.


Mike

--
Michael Zawrotny
411 Molecular Biophysics Building
Florida State University		| email:  zawrotny@sb.fsu.edu
Tallahassee, FL 32306-4380		| phone:  (850) 644-0069