Perspectives on learning and using Haskell

[ajb at spamcop.net]

G'day all.

Quoting Graham Klyne <gk at ninebynine.org>:

> (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.

In theory, that's true of other languages too.  Programmers are
*supposed* to spend more time doing non-coding than coding (where I
don't, for example, count writing unit tests as "coding").

I suspect that this is actually an artifact of your level of experience
with Haskell.  I know that I used to spend more time thinking than coding.
When you get familiar enough, you get to the stage where you can think on
your feet.

> (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.

This, I believe, is one of the most unappreciated (by non-declarative
programmers, anyway) aspects of declarative programming.  It's easy to
write could-be-slow code that works first time, once you've fixed all
the bugs caught by the compiler.  Then, it's straightforward to swap out
implementations and replace them with more efficient ones as the need
arises.

This is possible to do in non-declarative languages.  It's even
encouraged in "agile" OO methodologies, like XP.  However, it's so much
less painful in a declarative language, because you're far less tempted
to introduce hidden dependencies to begin with.

In fact, I find that my "working but slow" code has almost no weird
dependencies.  I find myself having to _introduce_ them during the "get
it faster" phrase.  From an engineering point of view, this is almost
exactly the right thing, because that way you (in theory) end up with as
few dependencies as possible.

> (6) I have found that Haskell seems to a particularly effective platform
> for pursuing some ideas of extreme programming,

There you go. :-)

There is only one problem I've found with test-driven development in
Haskell.  In C++, it's possible to break the "module" abstraction
(yes, I know, C++ doesn't have modules; it has classes, which are really
instantiable modules) by using "friend".  In Haskell, I find myself
occasionally having to expose parts of a module which I would prefer not
to, in order for the unit tests suite to do their job effectively.

I wonder if there might be a way to fix this, say, by allowing modules
to selectively expose parts of their interface depending on who wants
to use it.

Cheers,
Andrew Bromage