Emphatic agreement on this point. Likewise, the strong type system and the often helpful type error messages make it really easy to update code to work with more modern libs!
-Carter On Thu, May 2, 2013 at 9:39 AM, David Thomas <davidleotho...@gmail.com>wrote: > If you are actively using something then keep it up to date, encourage > someone to keep it up to date, pay someone to keep it up to date, or > migrate off of it. If you try building with a fresh set of packages every > so often, you can catch breaking changes early and deal with them when it's > typically pretty clear why things broke. > On May 2, 2013 6:33 AM, "Adrian May" <adrian.alexander....@gmail.com> > wrote: > >> So WASH is ancient history. OK, lets forget it. >> >> How about the Haskell Platform? Is that ancient history? Certainly not: >> it doesn't compile on anything but the very newest GHC. Not 7.4.1 but >> 7.4.2. Now that's rapid maintenance, but it's still version hell because >> you've got to have that compiler installed first (even though HP is >> supposed to be a way to acquire haskell) and you probably haven't. You've >> probably got the one from the linux package which hasn't been maintained >> since, ooh, must have been at least a week ago, so you install the new one >> and you've trashed cabal. How long is that puzzle gonna take to unravel? >> That's how I spent my afternoon today, instead of getting on with my job. >> Now you might think I was silly not to have uninstalled the linux package >> first, but I tried, and then decided against it because it thought the >> entire OS depended on it and actually proposed to remove everything from >> clib to googleearth as a solution. It's not Haskell's fault that linux >> package management is as broken as any other for the same reasons, but in >> an imperfect world, it's better not to keep moving the furniture around. >> >> Why was I trying to build the Haskell Platform at all? Because it wasn't >> obvious to me that a 7 year old library would be doomed. I find it >> perfectly normal to be able to compile C code from the 1970s but still run >> STL through the same compiler. That's why I blamed the system instead of >> the library. And unless somebody can explain to me how I would rescue my >> business now if I had opted for WASH in that long-forgotten era when Barack >> Obama was barely known, a Russian spy was poisoned with Polonium and a >> Sudanese man was ordered to marry a goat he was caught in an intimate >> position with, then I still see it that way. >> >> Adrian. >> >> >> >> >> >> >> >> >> On 2 May 2013 19:57, Ertugrul Söylemez <e...@ertes.de> wrote: >> >>> John Lato <jwl...@gmail.com> wrote: >>> >>> > I don't think there's anything wrong with moving at a fast pace, nor >>> > do I think backwards compatibility should be maintained in perpetuity. >>> >>> I think this statement pretty much covers the mindset of the Haskell >>> community and also explains the higher breakage rate of Haskell packages >>> when compared to other languages, in particular non-static ones: We >>> move at a very fast pace. Innovations are made all the time. Without >>> this feature we wouldn't be where we are today. >>> >>> Of course Haskell, being a rigorously static and correct language and a >>> community that equally rigorously insists on correctness of design >>> patterns we have to live with the fact that we need to fix the breakages >>> we introduce, and we do that. This is a good thing. >>> >>> >>> > Unfortunately this leaves a lot of scope for migrations to be handled >>> > poorly, and for unintended consequences of shiny new systems. IMHO >>> > both have caused issues for Haskell developers and users in the recent >>> > and more distant past. This is an issue where I think the community >>> > should continually try to improve, and if a user calls out a >>> > difficulty we should at least try to learn from it and not repeat the >>> > same mistake. >>> >>> I think we do that. The most severe breakages are introduced by new GHC >>> versions. That's why there is the Haskell Platform. If users decide to >>> move to new versions sooner they should be prepared to handle the >>> breakages. In particular a Haskell beginner simply shouldn't use >>> GHC-HEAD. Our type system makes us aware of the breakages we introduce >>> and gives us the opportunity to fix them properly before exposing them >>> to the users. >>> >>> With this in mind I don't think there is anything to learn from this >>> particular case. You wouldn't use WASH today for the same reasons you >>> wouldn't use Linux 0.x. It's a legacy, and the ideas from it have >>> inspired the more recent web frameworks, which are more convenient, >>> faster, more real-world-oriented. In fact I totally expect a new >>> generation of web frameworks to pop up in the future, more categorical, >>> even more convenient and less error-prone. >>> >>> >>> Greets, >>> Ertugrul >>> >>> -- >>> Key-ID: E5DD8D11 "Ertugrul Soeylemez <e...@ertes.de>" >>> FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11 >>> Keysrv: hkp://subkeys.pgp.net/ >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
