I agree with Mark and wren; it would be better to fix several of these
issues at once. I think it would be helpful to know how frequently
community members would tolerate breaking changes like this. For myself, I
think 2-4 years seems right, with 2 on the fast side. My impression is
there's a lot of support for rolling breakages, but maybe that's not the
case?
On Fri, May 24, 2013 at 7:45 AM, wren ng thornton
On 5/22/13 1:12 AM, Mark Lentczner wrote:
3) Stability is very important to adoption of a language. People are very influenced by their first impressions of a system. We seem perilously close to "death by continuous little paper cuts" here: I saw the catch debacle snag tons of people and projects in tiny hiccups. If you were a newcomer to Haskell (experienced engineer or no) and you ran into this, I bet it was a turn off.
FWIW, this is exactly why I made the "Burning Bridges" post. We've had a number of rather serious papercuts of late. The Prelude.catch one was rather annoying, especially because of its interaction with various automatic tools. The Show =/=> Num one also caused a flurry of version bumps and breakages. And of course there are others. These are all base/core issues ---I'm completely ignoring things like mtl-1 vs mtl-2, or parsec-2 vs parsec-3, or the iteratee libraries.
I am not opposed to change (obviously). I like that Haskell evolves. But the slow trickle of major breaking changes is not so nice. Nor is the accumulation of warts due to this slow tricking of major changes. This is why I suggest aiming for a major breakage in order to fix as much as we can in one fell swoop.
Yes, breakage will happen; but breakage is already happening with every new version of GHC! We continually hide our heads in the sand and pretend that this slow trickle of major changes isn't happening, but it is. And it turns off both newcomers trying to get their footing on shifting sands, as well as folks who want to deploy Haskell with the same sort of stability as they get from deploying Perl, Python, or Ruby.
-- Live well, ~wren
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries