[Haskell-cafe] The Lisp Curse
as at hacks.yi.org
Fri May 20 00:38:54 CEST 2011
I too am not all that concerned about the library proliferation, and I
think such work can definitely help find the best design for certain
abstractions. There are no less than 3 iteratee libraries - 4
including liboleg's original IterateeM formulation - and a number of
FRP implementations as well, but part of that is because we haven't
found the best designs for such things yet. Doing that will take time
and effort on the part of the community, whether there's 3 competing
libraries or 30.
In the case of Unicode, I think the community has clearly spoken in
its adoption of the `text` package into the Platform, as well as it
being one of the most depended on hackage packages. Certainly the
platform doesn't recommend a 'blessed' package for every need. JSON is
a simple example, and there are many various JSON implementations on
Hackage. Outside of the platform, I think there should definitely be a
better way to communicate to users what library might be best. I don't
know how that would look - Hackage 2 will have commenting and reverse
dependencies I think, but when that future hackage will rise is not
One thing is for certain: in the Haskell ecosystem, if your code does
not exist on Hackage, and *especially* if it does not use Cabal,
realistically speaking, it is dead as far as the larger community is
concerned (the exception being GHC itself, perhaps. Even gtk2hs - who
was one of the biggest outliers for a long time, now is cabalized.) I
think I would ultimately rather encourage people to submit code - even
if it is small or perhaps duplicate. At least give it and its ideas
the chance to survive, be used and talked about, and die if not -
rather than resign it to such a fate prematurely.
On Thu, May 19, 2011 at 5:00 PM, Daniel Peebles <pumpkingod at gmail.com> wrote:
> The way I understand it, you're saying not that we shouldn't be doing it
> this way (since it isn't centrally managed, it's the only possible way), but
> that we shouldn't be "bragging" (for lack of a better word) that we have
> lots of libraries that do a specific thing. Or if not that, then at least
> that it isn't a clear win.
> I agree that from an end-user's perspective it isn't always a clear win, but
> I do think that having a bunch of libraries (even ones that do the same
> thing) an indicator of a healthy, active, and enthusiastic community. Sure,
> it's decentralized and people will often duplicate effort, but different
> variations on the same idea can also help explore the design space and will
> reveal to everyone interested what works and what doesn't.
> But yeah, if you want to do X and you encounter 15 libraries that do X and
> can't find a clear consensus on what's best, I can understand why that might
> be frustrating. I don't think there's really a clear solution to that
> though, other than gently encouraging collaboration and scoping out of
> existing work before starting new work. But people generally hate working
> with other people's code, so I doubt that'll have much of an effect :)
> On Thu, May 19, 2011 at 4:56 PM, Andrew Coppin <andrewcoppin at btinternet.com>
>> On 19/05/2011 09:34 PM, vagif.verdi at gmail.com wrote:
>>> Andrew, you are being non constructive.
>> It seems I'm being misunderstood.
>> Some people seem to hold the opinion that more libraries = better. 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'm not trying to say "OMG, the way it is now completely sucks!" I'm not
>> trying to say "you must do X right now!" I'm just trying to put forward an
>> opinion. The opinion that having too many libraries can be a problem, which
>> some people don't seem to agree with. (Obviously it isn't *always* bad, I'm
>> just saying that sometimes it can be.)
>> That's all I was trying to say.
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe