Perspectives on learning and using Haskell

Wed Dec 24 12:29:05 EST 2003

At 17:44 23/12/03 -0500, Derek Elkins wrote:
>On Tue, 23 Dec 2003 17:26:20 +0000
>Graham Klyne <gk at ninebynine.org> wrote:
>
>(moved to Haskell-Cafe as this reply might generate several more)
>
> > I've spent part of the past few months learning Haskell and developing
> > a moderately sized application.  I came to this from a long background
> > (20 years or so) of "conventional" programming in a variety of
> > languages (from Fortran and Algol W to Java and Python).  For me,
> > learning Haskell has been one of the steepest learning curves of any
> > new language that I have ever learned.  Before this project, I was
> > aware of some aspects of functional programming, but had never
> > previously done any "in anger" (i.e. for real).
>
>Well, the obvious question is: after climbing partway up that curve,
>what do you think of the view?  Was it worth learning?  Is it worth
>continuing to use?  Does the code seem 'better' than what you might
>produce in other languages you've used?

I think the view is good :-)

Others have written about the advantages of FP, and I won't try to repeat 
that.  My personal observations include:

(1) I notice that it's very easy to pick up and use third-party 
functions;  there doesn't seem to be the square peg/round hole effect that 
one gets with third-party libraries in conventional programming 
languages.  I don't know why this is, but two possibly contributing factors 
may be:

   (a) many Haskell expressions are just values, so in some respects 
they're closer to data than to code.  There isn't a procedural aspect to 
get in the way (e.g. no need to coordinate passage through the "von Neumann 
bottleneck"?)

   (b) the type system permits, even encourages, typing details that are 
not relevant to some function to be left unspecified.

(2) I find that I spend a far greater portion of my time *thinking* about 
what I'm trying to do than actually coding it.  There used to be an adage 
in the software industry that programmer productivity in lines-of-code per 
day was independent of programming language:  with Haskell, I suspect that 
old rule breaks down, because it seems that actually coding has become a 
relatively small part of the overall exercise.

(3) it has often been noted that despite the influx of "new" programming 
languages, little is truly new -- the act of programming is pretty much 
unchanged since, er, the 60's?  I know the basic ideas of FP have been 
around for several decades, but I do think there is some truly new thinking 
being applied in the area of FP, compared with conventional languages.  I 
think I do see some truly different approaches being explored in the FP 
community, and some of those do seem to have some real value.  (e.g. the 
way that Monads turn out to be such a flexible idea.  I haven't yet started 
to look at arrows.)

   Related to this, it seems to me that Haskell's lazy functional model is 
capable of subsuming many other programming models.  One that I discovered 
quite early was mimicking the test-and-backtrack style of Prolog.  More 
recently, looking at the like of "scrap your boilerplate" ideas, it seems 
that FP is capable of tackling the separation of "cross-cutting concerns" 
that seem to motivate the more recent Aspect Oriented Programming ideas, 
without really adding any new language features.

(4) I have noticed that it's often very easy to write some inefficient code 
(sometimes *very* inefficient) to do some task in Haskell, and then to 
optimize it.  My current project is currently riddled with horrendous 
inefficiencies, but I don't care because I am confident that I can optimize 
as and when I need to.  (The GHC profiling system is one reason for this 
confidence, and also the availability of off-the-shelf libraries to improve 
many of my very inefficient data structures.)

(5) working as I do in the area of Internet and Web protocols, I like the 
idea that I can (often) write code that is closely and "obviously" related 
to a specification that I'm trying to implement.  (This is an area that I'd 
like to explore further.)

(6) I have found that Haskell seems to a particularly effective platform 
for pursuing some ideas of extreme programming, and in particular test-led 
development.  (I do this very imperfectly, but I'm learning ;-)  For 
example, Dean Herington's unit testing framework seems to fit more 
comfortably into the  host language than, say, the JUnit framework from 
which it takes its inspiration.  Adding new styles of test-case has been a 
breeze compared with my experience of using JUnit or PyUnit (and I have 
found those frameworks to be very satisfactory).

(7) For the first time since learning Pascal, I'm impressed at how reliable 
my Haskell code (messy as much of it may be by Haskell standards) has 
turned out to be.

If I sit here longer, I will probably think of more.

But, in summary, I think a combination of:
- improved language implementations
- improved hardware
- new ideas about how to use/deploy FP
- the nature of some Internet/Web applications
mean that FP in general and Haskell in particular can be used to good 
effect in real-world "industrial strength" projects.

There are some more of my comments about using Haskell here:
   http://www.ninebynine.org/RDFNotes/Swish/Intro.html#WhyHaskell
(these are directed more toward an audience not familiar with Haskell or FP.)

> > Throughout this period, I've been accumulating some notes about some
> > things that I found challenging along the way.  The notes are not
> > organized in any way, and they're certainly not complete.  I've
> > published them on my web site [1] in case the perspective might be
> > useful to any "old hands" here.
> >
> > [1] http://www.ninebynine.org/Software/Learning-Haskell-Notes.html
>
>When I saw this page earlier, I was thinking about suggesting to you to
>add it and any new thoughts to the wiki so that it's more readily
>accessible to other Haskell newbies and can be annotated with pointers
>to resources and comments; kind of like an annotated unidirectional
>version of "A Newbie's on-going tutorial" on the Squeak wiki
>(http://minnow.cc.gatech.edu/squeak/1928).

I wondered about that... I'm more than happy for any or all of this 
material to be served by the Wiki.  As a relative outsider/newcomer to this 
community, I wasn't sure if my offerings would be felt to be useful or 
welcome there.

Your suggestion sounds good... if it's felt to be helpful, I'll ponder it 
and think about how I might present it.  The page you cite seems to have 
the right kind of tone.

#g

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact