[Haskell-cafe] Re: Go Haskell! -> array libraries
jwlato at gmail.com
Sat Nov 29 13:08:17 EST 2008
> From: Andrew Coppin <andrewcoppin at btinternet.com>
>>> 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.
> I find this kind of attitude disturbing.
> Are you seriously asserting that it's "bad" for people to stop and think
> about their designs before building? That it's "bad" for people to get
> together and coordinate their efforts? Would you really prefer each and
> every developer to reinvent the wheel until we have 50,000 equivilent
> but slightly different wheel implementations? Certainly you seem
> obsessed with the notion that "more packages on Hackage == better". Well
> in my book, quantity /= quality. (The latter being vastly more important
> than the former - while admittedly far harder to measure objectively.) I
> would far prefer to see one well-written library that solves the problem
> properly than see 25 incompatible libraries that all solve small
> fragments of the problem poorly. In the latter case, there will be no
> "competition" between libraries; everybody will just give up and not use
> *any* of them. You _can_ have too much choice!
> I really hope I'm not the only person here who sees it this way...
I would love to see a perfect, unified array library in Haskell. I
think everyone would. However, the problem Don, Roman, and others
have raised is that there is no single consensus on what that library
would look like, or how it would be implemented. It might be
impossible for one library to fill the entire design space. Don's
point is that, since this isn't yet a solved problem, having multiple
implementations available to see what works well (and what doesn't) is
a necessary step in finding a solution.
I also think this is a exactly why Hackage needs a way to indicate
that packages are deprecated/superceded by other packages. There was
some talk about this recently, and IIRC even a submitted patch. I
hope that gets adopted soon.
More information about the Haskell-Cafe