[Haskell-cafe] The Lisp Curse

[Andrew Coppin]

On 19/05/2011 11:00 PM, Daniel Peebles wrote:

> I agree that from an end-user's perspective it isn't always a clear win,
> but I do think that having a bunch of libraries (even ones that do the
> same thing) an indicator of a healthy, active, and enthusiastic
> community.

I won't argue with that. ;-)

> Sure, it's decentralized and people will often duplicate
> effort, but different variations on the same idea can also help explore
> the design space and will reveal to everyone interested what works and
> what doesn't.

Yeah, as some others have said, it depends on the problem domain. For 
some things, it's really not clear what the correct abstractions are 
yet, and there's still a lot of design space to explore. (I might pick 
at random, say, Functional Reactive Programming. As best as I can tell, 
several people have ideas, but there's no clear "best way" of doing this 
yet. We're still experimenting.) For stuff like that, it's useful to 
have lots of people trying different stuff.

> But yeah, if you want to do X and you encounter 15 libraries that do X
> and can't find a clear consensus on what's best, I can understand why
> that might be frustrating.

Moreover, there can be network effects involved. A while back somebody 
from Google wrote that everybody agrees that String is too slow for 
high-performance I/O, but each library that involves high-performance 
I/O tends to end up using a different text representation, which rather 
impedes compatibility between them.

> I don't think there's really a clear solution
> to that though, other than gently encouraging collaboration and scoping
> out of existing work before starting new work. But people generally hate
> working with other people's code, so I doubt that'll have much of an
> effect :)

Yeah, I'm not going to present I have a solution. I merely wanted to 
point out that it's a problem which does exist. Some of the other folks 
in this thread seem to be coming up with useful ideas though.