[Haskell-cafe] The Lisp Curse

[Andrew Coppin]

On 19/05/2011 10:43 PM, Ketil Malde wrote:
> Andrew Coppin<andrewcoppin at btinternet.com>  writes:
>
>> I'm trying to voice the opinion that there is such a thing as too many
>> libraries. The article I linked to explains part of why this is the
>> case, in a better way than I've been able to phrase it myself.
>
> I don't think so, the article seems to talk more about social problems
> among lisp users, which it - at least in part - ascribes to the technical
> prowess of the language.

Actually, the author seems to be saying that Lisp is [relatively] 
unsuccessful because it's so powerful that is discourages cooperation. 
Personally I don't buy it; I'm sure there are *several* reasons why Lisp 
never became The Next Big Thing. (There's a dozen dialects of it, for 
starters...) But hey, I'm not really interested in Lisp. I'm interested 
in Haskell.

What I took away from the article is that if you design a really 
powerful language, paradoxically this can make it cheaper to reimplement 
stuff rather than reuse it. You'd think a language with strong support 
for reuse would encourage reuse, but not necessary.

As you point out, people not cooperating is a social rather than 
technical problem. It seems obvious once you say it out loud, but I 
hadn't really conciously realised that.

Consequently, the language isn't the whole story. If you make the 
language really powerful, that reduces the cost of implementing things 
from scratch. On the other hand, if you can do things that reduce the 
cost of finding existing code that you could reuse, you swing the 
balance back in the other direction. We have Hackage (and now HP). I 
have no idea whether Lisp has anything comparable.

>> The opinion that having too many libraries can be
>> a problem, which some people don't seem to agree with.
>
> I don't see how the number of available libraries is a problem in
> itself, but it would be nice if hackage or some other resource provided
> more help in recommending which library to try first.  We do have
> standardization efforts, committees bringing the language forward and an
> inclusive and collaborative community.

I certainly don't think having a lot of libraries available is bad. 
Having lots of libraries available for /the same task/ is different. As 
some others have pointed out, it varies somewhat depending on what the 
task in question is.

If Haskell still used the old lazy-list I/O approach and Hackage had 3 
different monadic I/O libraries implemented on top of that, that would 
be really bad. Fortunately, once everybody realised that monadic I/O was 
the way to go, we ended up with one library which everybody uses. It has 
costs (e.g., you cannot redefine the Monad class to include, say, 
Data.Set), but it has the huge, huge benefit that nobody will ever utter 
the words "I'd like to bolt HsLogger onto Yesod - oh wait, I can't, they 
use incompatible IO monads".

On the other hand, there are lots of GUI libraries. Because they bind to 
different toolkits, or work on different combinations of platforms, or 
because they wrap low-level bindings with more "functional" interfaces, 
or whatever. We wouldn't want a massive *explosion* of identical GUI 
libraries, but I don't think the current set is excessive at all.