Breaking Changes and Long Term Support Haskell

[Gregory Collins]

On Wed, Oct 21, 2015 at 11:40 PM, Edward Kmett <ekmett at gmail.com> wrote:

> 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.
>>
>
> The way things are shaping up, we've had 17 years of rock solid stability
>

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.

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.

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.

-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151022/a53a36ea/attachment-0001.html>