On 19/05/2011 10:43 PM, Ketil Malde wrote:
Andrew Coppin<andrewcop...@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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
