>> 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