Learning Haskell and FP
Fri, 5 Jan 2001 10:22:44 -0800
> -----Original Message-----
> From: Michael Zawrotny [mailto:firstname.lastname@example.org]
> Sent: Friday, January 05, 2001 8:01 AM
> To: email@example.com
> Subject: Re: Learning Haskell and FP
> "Benjamin L. Russell" <firstname.lastname@example.org> wrote
> > Michael Zawrotny <email@example.com> wrote:
> > >
> > > The thing that I would most like to see would entitled "A
> > > Practical Guide to Haskell" or something of that nature.
> > >
> > > [snip]
> > >
> > > One is tempted to come to the conclusion that Haskell is
> > > not
> > > suited for "normal" programmers writing "normal"
> > > programs.
> > How would you define a "'normal' programmer writing
> 'normal' programs?" What
> > exactly is a "'normal' program?"
> That was sloppy on my part. My message was getting long, so I used
> "normal" as a short cut. I should know better after seeing all of
> the flamewars about whether or not FP is suitable for "real" work.
> What I meant by "normal programmer" was (surprise) someone
> like myself.
> I.e. someone who doesn't have much, if any background in
> formal logic,
> higher mathematics, proofs of various and sundry things, etc.
I agree here. Todays software engineers take the tools at their disposal to
make systems as best they can at the lowest price they can. The FP
documentation is not ready -- it is still in the world of academics. The
tools are also not there.
The problem is not that working programmers can not understand necessary
theory to apply techniques. We certainly do not have the time to go through
all sorts of academic papers. We do have the time to take home a text book
and read it over a few weekends. What we need is to be spoon fed the
important knowledge (i.e. in a single textbook). The various Design Pattern
catalogs do this for OO. FP is a little more complicated, but I think there
is much potential to get more work done in the same time if we could learn
to apply it.
> By "normal program" I meant things like short utility programs that
> I might otherwise write in shell, python, perl, etc. or data
> and analysis programs that I might write in in python, perl, C or C++
> depending on the type of analysis.
For the sake of diversity, a normal program to me inludes everything from
XML processing (which I do a fair bit), database manipulation, delivery of
historical and current (i.e. "real time" or immediate values) to users, and
this one is real key: scalable programs for 3 tiered architectures. The
last one is real interesting. For those familliar with COM+ or MTS (or the
Java equivelent), the middle or business tier typically contains objects
which behave as functions -- when a client calls a middle tier object, the
state of that middle tier object is cruft once the call completes. I think
what is called "business logic" in the "real world" of delivering systems
would be an excellent place to us FP.
> > (Perhaps another way of phrasing the issue is as the
> "declarative" vs. "proce
> > dural" distinction, since the issue seems to be that of
> "what is" (types) vs.
> > "how to" (imperative expression; i.e., procedures).)
> Although there is some of that, for me at least, the types aren't a
> big deal. The main thing for me is figuring out how to actually get
> something done. Most of the things I've read have had tons of really
> neat things that you can do with functional abstractions, but it's all
> ... abstract. I would love to see something that is more
> about getting
> things done in a how-to sense, including IO. Much of the
> material I've
> seen tends to either relegate IO and related topics into a
> small section
> near the end (almost as if it were somehow tainted by not being able
> to be modelled as a mathematical function), or it goes into it talking
> about monads and combinators and things that make no sense to me.
> > While I agree that "A Practical Guide to Haskell" would
> indeed be a suitable
> > alternative for programmers from the procedural school of
> expression, I would
> > caution that such an introduction would probably not be
> suitable for all.
> This is very true. I think that there is plenty of material
> that would
> be helpful for an SMLer to learn Haskell, but not much for someone who
> was was only familiar with with C or who was only comfortable with FP
> to the extent of understanding lambdas, closures and
> functions as values,
> but none of the more esoteric areas of FP. I'm advocating something
> along the lines of the "Practical Guide" I mentioned or the "Nutshell"
> book below.
> > Perhaps, ideally, two separate tutorials (or perhaps a
> single tutorial with t
> > wo sections based on different viewpoints?) may be needed?
> The difficulty is
> > that the conceptual distance between the declarative and
> procedural schools
> > of thought seems too great to be bridged by a single
> viewpoint. It seems tha
> > t any introduction favoring either one would risk
> alienating the other.
> I agree that any single tutorial would be able to target both
> > Personally, I would really prefer "A Gentle Elementary
> Introduction to Haskel
> > l: Elements of the Haskell School of Expression with
> Practical Examples," bu
> > t some would no doubt choose "Haskell in a Nutshell: How
> to Write Practical
> > Programs in Haskell."
> I'm definitely the "Nutshell" type. If it were published, I'd buy
> it in a heartbeat. That's why it would be good to have both, everyone
> would have one that suited their needs.
> I'd like to say a couple things in closing, just so that people don't
> get the wrong idea. I like Haskell. Even if I never really write any
> programs in it, trying to learn it has given me a different way of
> thinking about programming as well as exposing me to some new ideas
> and generally broadening my horizons. My only problem is that I just
> can't seem to get things done with it. Please note that I am not
> saying here, nor did I say previously that it isn't possible to do
> things in Haskell. Obviously there are a number of people who can.
> I am simply saying that I am having trouble doing it. I would also
> like to mention that I really appreciate the helpful and informative
> tone on the list, especially on a topic that, even though not intended
> that way, could be considered critical of Haskell.
> Michael Zawrotny
> 411 Molecular Biophysics Building
> Florida State University | email: firstname.lastname@example.org
> Tallahassee, FL 32306-4380 | phone: (850) 644-0069
> Haskell-Cafe mailing list