[Haskell-cafe] The Lisp Curse
andrewcoppin at btinternet.com
Sat May 21 11:03:19 CEST 2011
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
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.
More information about the Haskell-Cafe