<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 21, 2015 at 11:40 PM, Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">All I'm saying is that if we want to appeal to or cater to working software engineers, we have to be a lot less cavalier about causing more work for them, and we need to prize stability of the core infrastructure more highly. That'd be a broader cultural change, and that goes beyond process: it's policy.</div></div></blockquote><div><br></div></span><div>The way things are shaping up, we've had 17 years of rock solid stability</div></blockquote><div><br></div><div>I have >95% confidence that all of the C++ programs I wrote 15 years ago would build and work if I dusted them off and typed "make" today. I have Haskell programs I wrote last year that I probably couldn't say that about.</div><div><br></div><div>So I don't buy that, at all, at least if we're discussing the topic of the stability of the core infrastructure in general rather than changes being made to the Prelude. It's been possible to write to Haskell 98 without too much breakage, yes, but almost nobody actually does that; they write to Haskell as defined by GHC + the boot libraries + Haskell platform + Hackage, IMO with decreasing expectations of stability for each. The core set breaks a lot. We definitely shouldn't adopt a posture to breaking changes as conservative as the C++ committee's, and literally nobody in the Haskell community is arguing against breaking changes in general, but as I've pointed out, most of these breakages could have been avoided with more careful engineering, and indeed, on many occasions the argument has been made and it's fallen on deaf ears.</div><div><br></div><div>They can speak for themselves but I think for Mark and Johan, this is a "straw that broke the camel's back" issue rather than anything to do with the merits of removing return from Monad. I think the blowback just happens to be so much stronger on MRP because the breaking change is so close to the core of the language, and the benefits are so nebulous: fixing an aesthetic problem has almost zero practical value, and ">> could be slightly more efficient for some monads" is pretty weak sauce.</div><div><br></div></div>-- <br><div class="gmail_signature">Gregory Collins <<a href="mailto:greg@gregorycollins.net" target="_blank">greg@gregorycollins.net</a>></div>
</div></div>