On Fri, Apr 23, 2010 at 12:17 PM, John Goerzen
Don Stewart wrote:
I'll just quickly mention one factor that contributes:
* In 2.5 years we've gone from 10 libraries on Hackage to 2023 (literally!)
That is a massive API to try to manage, hence the continuing move to focus on automated QA on Hackage, and automated tools -- no one wants to have to resolve those dependencies by hand.
Yep, it's massive, and it's exciting. We seem to have gone from stodgy old language to scrappy hot one. Which isn't a bad thing at all.
Out of those 2023, there are certain libraries where small changes impact a lot of people (say base, time, etc.) I certainly don't expect all 2023 to be held to the same standard as base and time. We certainly need to have room in the community for libraries that change rapidly too.
I'd propose a very rough measuring stick: anything in the platform ought to be carefully considered for introducing incompatibilities. Other commonly-used libraries, such as HaXML and HDBC, perhaps should fit in that criteria as well.
I feel your pain John... I try to use Haskell commercially, and sometimes run into things I'm either going to have to re-implement myself or wait for a fix and do some workaround. Luckily I *like* this language enough to care to do it, but it does present a bit of a problem when trying to break it into an ecosystem full of C/C++ and Java when I have to back-peddle to explain why something in this "new" language that's supposed to help solve some problems with the "old" languages is not a magic bullet. I think managers expect magic bullets and holy grails... sometimes they just end up with "holy cow"'s (or other more interesting 4 letter words) instead. Dave
-- John _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe