Re: foldable flexible bridges (putting foldable+traversable in prelude) Re: Burning bridges
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
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
On 24 May 2013 08:27, John Lato
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?
I'd much prefer to have all these little things (type hierarchy cleanup, prelude generalisation) lumped together: * available in a ghc release but off-by-default; that way library authors and commercial users can test the changes without hacking ghc * default in the following ghc release, but disableable by a flag * with a document explaining how to transition code I expect most of the transitioning advice would be pointing out which lines to remove from imports and custom instances, and I'd prefer to do all that once asap rather than once every 6 months for the next few years. Conrad.
On Fri, May 24, 2013 at 08:55:55AM +0800, Conrad Parker wrote:
I'd much prefer to have all these little things (type hierarchy cleanup, prelude generalisation) lumped together: * available in a ghc release but off-by-default; that way library authors and commercial users can test the changes without hacking ghc * default in the following ghc release, but disableable by a flag
To do either of these you'd need a completely different set of libraries for the old vs the new. It would be simpler just to install 2 different GHCs, one with the old and one with the new. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
On Thu, May 23, 2013 at 04:45:30PM -0700, wren ng thornton wrote:
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.
This sounds like a good idea to me. At the moment, I don't remember any changes currently in the git base repo that I expect would have a widespread impact (there have been changes that could cause clashes with particular libraries, but I don't think there's anything that will have a more global effect, like the Num and catch changes did). There are currently a number of proposals that seem to have support (e.g. splitting base, generalising Prelude functions, class hierarchy changes), but I don't think we have patches for any of them yet. So we'd still need (for each proposal) to get agreement, work out the details, make and apply the patch, and then may find that there are unexpected repercussions that we'd like to react to. Now, there's about 4 months until we'd like to be putting GHC 7.8 out, which sounds like a lot of time, but once you take into account ICFP and other absences, finishing the other things we're working on for 7.8, the pre-release frantic bug fixing, and actually getting everything working smoothly so that we can release it, it's really not that long. So I'd suggest that we leave 7.8 as a mostly-compatible release, and while it is still worth people making and discussing these proposals now, we don't actually apply them until just after 7.8 is branched. That gives us the maximum amount of time for them to mature in HEAD before they release with 7.10, and gives us lots of time to think about other changes we'd like to batch together with them. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
participants (4)
-
Conrad Parker -
Ian Lynagh -
John Lato -
wren ng thornton