
It's generally considered OK to break small parts of code. For example, the infamous n+k patterns — if I remember correctly, they are still here, but you have to enable them explicitly. It breaks SOME code, but not a lot of it. We might even break a lot of code, but we surely need a VERY good reason to do that.
On 08 Aug 2015, at 23:27, Hilco Wijbenga
wrote: On 8 August 2015 at 14:03, Brandon Allbery
wrote: This is quite important, folks. Don't tell us how tools will mitigate this. Go look at Python 3's adoption rate --- and it does have the tools --- and tell me again how well that path works for an established language. (Hint: every Python package I use has no intention of moving to Python 3.)
That seems like a red herring to me. Python does not have a type system to speak of so even simple refactoring is painful. Let alone making changes to the language itself...
Haskell may be new to you personally. That does not mean that it's okay to break what, more than 15 years worth of code?
So when is it okay? :-) Still, if proper tooling automates it, why not?
(I'm not advocating making language changes willy-nilly but the argument "it breaks existing code" [in and of itself] implies we are stuck with all mistakes made in the past. Language designers are human too. We need a way forward.)