|
![](/i/fill.gif) |
>> So having several different but essentially equivilent programming
>> languages was "bad". But having several different but somewhat
>> overlapping array libraries is "good" and even "to be encouraged". WTF?
>
> Sounds like they drank the OSS flavored kool-aid.
I have no idea what the heck kool-aid is, but... yes.
Don was the person who rejected my suggestion for working on unifying
the libraries. Don is also the guy who regularly posts graphs of the
number of packages being submitted to the Haskell package database.
(Because, after all, it's the number of packages that matters, right?
Not, say, the quality of those packages or how many people they're
useful to or even whether they compile at all...)
Don's position was that "the perfect container API hasn't been invented
yet" and that we need to "experiment" and that these multiple different
array libraries would "compete" for users and the best one would win. Or
something like that.
From where I'm sitting, we've got a library that does A, B and C,
another one that does A, D and E, another that does C, D and F, and yet
another that does X, Y and B. And I'd really like to just have a single
library that does A through Z easily and without fuss. :-P
IMHO, "competition" only works if people actually have the time and
inclination to try out all the alternatives and pick the one they like
the best. That probably works for parser libraries. (Indeed, Haskell has
at least two major ones - Parsec and PolyParse.) I'm not sure it works
well for a bunch of array libraries when none of them covers more than a
few use cases.
But hey, it's only my opinion. And I suck at Haskell, remember? :-S
Post a reply to this message
|
![](/i/fill.gif) |