[Haskell-cafe] The Lisp Curse

[Jesper Louis Andersen]

On Thu, May 19, 2011 at 20:33, Andrew Coppin
<andrewcoppin at btinternet.com> wrote:

Ok, I'll bite.

> To all the people who look at Hackage, see that there are 6 different
> libraries for processing Unicode text files, and claim that this is somehow
> a *good* thing, I offer the above essay as a counter-example.

Here is what usually happens:

Every library that is *useful* undergoes an iterative process in which
is will gradually be improved until a winner emerges. This is like
biological evolution and a signal of a healthy community. For a winner
to emerge however (like Text in Unicode) - there need to be a clear
problem you are trying to solve and the solution must be fairly easy
to use. This doesn't always happen if the initial problem is too
vague.

This is by the way the same model used for the Linux kernel. At some
point there was like 3 wifi stacks and 4 USB stacks in the kernel,
until people opted to extend the one that was easiest to extend.

Haskell's demon are advanced type-level constructions at the library
level. If you build a library which is hard to use because you need to
understand a complex type-world, then there will be less adoption
compared to a simpler library more people understand. Common Lisps
demon are complex macros and that you need discipline in the more
dynamic typing environment. Also that there is no enforcing of concern
separation.

On the other hand, a library with a simple type-world may be too
simple and not give the guarantees one would like. Hence, for the same
problem, you now have justification for the existence of two
libraries.

My personal gripe is the construction of libraries for the sake of
constructing libraries. I like the tools I use to have been used in
anger in real projects. That tends to weed out some problems right
away because you had an actual user. It also underpins a mantra I
learned from the Erlang community: Build tools, not solutions. The
library should support your program and not provide a solution. If
that is not the case, you are probably better off without the library
in the first place. The horror-case I know is Java Apache XML-RPC. It
underwent three iterations. v1.x was useful but cumbersome. v2.x
improves the interface and is more useful. v3.x is a mistake. The
author decided to use reflection, automatic generation and generate
interfaces based on classes. That library is very hard to use in
practice because there are many things you want to do you can't. It is
also a project with a RequestProcessorFactoryFactory class :)



-- 
J.