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