AW: slide: useful function?

Mark Carroll
Mon, 2 Dec 2002 14:19:20 -0500 (EST)

On Mon, 2 Dec 2002, David Bergman wrote:
> Till then, we "Haskellers" will probably continue expressing our
> patterns either directly in Haskell or using highly formal language,
> with terms such as "catamorphisms".
> The virtue, and weakness, of traditional design patterns is their
> vagueness and informal character, making them (1) comprehensible to the
> 90% of the developer community not familiar with category theory but (2)

If there are any good ways in which non-mathematicians can get to grips
with these terms from category theory, they would be well worth promoting.
For example, despite having a good computer science degree (in which I was
at least introduced to FP, proof, etc. and even learned to draw the dual
graph of hypercubes) I'm really not equipped to understand catamorphisms
in terms of algebras and homomorphisms, and don't currently have time to
take the math degree I fear I'd need in order to do so. Last time I was
looking at category theory books I think I came to the conclusion that
Lawvere and Schanuel cover things kindly but Pierce seemed to get the
syllabus right, so the "right" book wasn't quite out there.

My understanding of monads is already a matter of record. Does anyone know
of a friendly text that might help new Haskellers to understand functors,
etc. and what they mean for program design? I'm not averse to the formal
language per se if it can be easily acquired; right now, I worry that I'm
using Haskell suboptimally because, not only do I not know the terminology
well, but I fear that I'm not even cognisant of the concepts that these
terms represent.

In a nutshell: if these category theory concepts indeed have an important
impact in Haskell land, how to introduce them to working Haskell
programmers well enough that they can use them in engineering software
that's at least half as good as it could be?

(I'm making the assumption here that it would be good for Haskell to be
much more widely used - it shouldn't solely be for researchers.)

-- Mark