[Haskell-cafe] The Lisp Curse

[Paolo G. Giarrusso]

Hi,
while I'm still a Haskell learner, I wanted to contribute my point of
view, which I hope is different enough to be useful.

First, of course we don't need to restrict Hackage to contain just 1
library for every purpose, we just need to give incentives for people
to collaborate. And if they really have different ideas, they should
compare their approaches and their implementation, to some extent.
For the unicode example, the question is: why people kept creating new
solutions to the same problem, instead of working together? At least,
why don't those people document their different goals, if they have
some?

Andrew Coppin is not trolling. He is calling the community to reflect
on why this happens and to find together a solution. To me, it seems
that already agreeing that there is a problem would be already a step
forward.

Daniel Peebles wrote, as an answer:
> But people generally hate working with other people's code, so I doubt that'll have much of an effect :)

I only hate working on somebody else's code when it's bad/unclear/
badly documented - IMHO code is good when it's a pleasure to work on
it.

1) Collaboration and critical mass
A library is not just code. It is an ecosystem of code, documentation,
experience is using it and refining the design (that is, client
software), tutorials and blog posts, and generally any form of shared
knowledge. If we split this, none of the projects reach the critical
mass.
Interestingly, the smaller size of the Haskell community is itself one
of the reason of the problem. Also in other languages there are often
more solutions for the same problem - I bet every language has tons of
interesting JSON libraries, together with not-so-interesting ones.
However, I bet that for an interesting domain and a popular language,
the best approaches are automatically selected: few libraries reach
the critical mass and become popular. Haskell has less developers, so
we need more efficient tools to build shared knowledge.

It seems that the future Hackage will have comments; I'd also like a
guideline such that authors compare their work to the alternatives.
Just as papers get rejected when they miss relevant related work, and
for good reasons, packages will get downvoted if the author is not
aware of another solution. Then, we can encourage the author to either
improve his library, or to "deprecate" it if he doesn't care.

2) The Haskell platform - just a partial answer.
I understand it was born exactly to address this problem, so it
confirms it; I don't think that everything can fit in there, so it
doesn't solve the problem for everything - except for what can be
included.

3) The advantage of multiple interfaces in 1 library. (Answering to
Julian Porter)
That is, interoperability. A simpler and a more complex interface
might be needed. But why do they have to be into different libraries,
written without a coherent design, and without (say) wrapper/converter
functions? Probably, in many cases, I want to have 1 library which is
general, supplies some standard boilerplate for the common use case,
has a single guide which allows me to find my way around. Of course
that's a final product, but we need at least to aim for that.

This is my answer to Julian Porter's point:
[
>   ultimately the ideal is to end up with one library that solves the problem well, which everybody can use.

 Nonsense.  One library that everyone can use with either end up being
so small in functionality that it's actually useless, or so general
that either it requires tons and tons of boilerplate just to use it at
all, or it's really about eight libraries rolled into one and so
impossible to find your way around.  Whichever, it's not good.  The
sweet spot is at the point of maximum tension between generality and
simplicity.
]

4) Development level
"There are 3-4 versions of iteratee because we are still not sure
about the right design". Hmm, this suggests that the concept is still
in a research stage and incomplete - so newcomers should either spend
lots of effort studying all libraries or avoid using the concept at
all because it's too complex. If instead there is consensus that
different approaches are useful in different cases, then please
compare them, especially because libraries with an advanced type-level
construction have a steeper learning curve.

One problem here, I think, is also that a lot of us are researchers,
and most research produces prototypes which are then often not
maintained, leaving a complete implementation to "somebody else". I'm
not accusing anybody - I'm a PhD student, and I realize that doing
otherwise might be detrimental to my career, at least in its early
stages, since I'm supposed to prototype new, innovative ideas instead
of complete existing ones. But is that really true for everybody? Or
am I mistaken here?

On May 19, 10:20 pm, Andrew Coppin <andrewcop... at btinternet.com>
wrote:
> On 19/05/2011 07:56 PM, Gilberto Garcia wrote:
>
> > I think what Andrew meant is that it's not a good idea to have big
> > pile of different implementations of the same library, and all trying
> > to solve the very same problem.
>
> I'm glad somebody understood what I was trying to get at.
>
> I'm not saying that we shouldn't ever have more than one library
> tackling the same problem. I'm just saying that when people say "we have
> multiple libraries competing to solve this problem, and that's
> *great*"... well, not necessarily, no. Obviously there's room for
> finding out what the best way to solve the problem is, but ultimately
> the ideal is to end up with one library that solves the problem well,
> which everybody can use.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-C... at haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe