[Haskell-cafe] Re: Go Haskell! -> array libraries

[Claus Reinke]

> But I don't want Perl, I want a well designed language and well
> designed libraries.
> I think it's find to let libraries proliferate, but at some point you
> also need to step back and abstract.
> 
>  -- Lennart

Especially so if the free marketeers claim there is something 
fundamentally wrong with the standard libraries and language, as in 
the case of arrays. When someone did that nice little survey of the 
last bunch of array libraries (Bulat, I think? now in the wiki book), 
I was hoping there would be a grand unification soon. Instead, it 
seems that those who have worked most with Haskell arrays 
recently have simply abandoned all of the standard array libraries. 

Okay, why not, if there are good reasons. But can't you document 
those reasons, for each of your alternative proposals, so that people 
have some basis on which to choose (other than who has the loudest 
market voice;-)? And would it be difficult for you all to agree on a 
standard API, to make switching between the alternatives easy (if
it is indeed impossible to unify their advantages in a single library,
the reasons for which should also be documented somewhere)?
And what is wrong about Simon's suggestion, to use the standard 
array lib APIs on top of your implementations?

Not that I see Haskell' coming soon, but I'd certainly not want it
to continue standardising a kind of array that appears to have no 
backing among the Haskell array user/library author community. Nor 
would I like something as central as arrays to remain outside the 
standard, where it won't remain stable enough for Haskell 
programmers to rely on in the long run.

bazaar, yes; mayhem, no.
Claus
 
> On Fri, Nov 28, 2008 at 9:46 PM, Don Stewart <dons at galois.com> wrote:
>> andrewcoppin:
>>> What *I* propose is that somebody [you see what I did there?] should sit
>>> down, take stock of all the multitudes of array libraries, what features
>>> they have, what obvious features they're missing, and think up a good
>>> API from scratch. Once we figure out what the best way to arrange all
>>> this stuff is, *then* we attack the problem of implementing it for real.
>>>
>>> It seems lots of people have written really useful code, but we need to
>>> take a step back and look at the big picture here before writing any
>>> more of it.
>>
>> No.
>>
>> My view would be to let the free market of developers decide what is
>> best. No bottlenecks -- there's too many Haskell libraries already (~1000 now).
>>
>> And this approach has yielded more code than ever before, more libraries
>> than ever before, and library authors are competing.
>>
>> So let the market decide. We're a bazaar, not a cathedral.
>>
>> -- Don
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe