John Lato
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