Language Change Management

[Bardur Arantsson]

On 10/06/2015 02:49 AM, wren romano wrote:
> On Mon, Oct 5, 2015 at 5:23 PM, Adam Foltzer <acfoltzer at gmail.com> wrote:
>>>  Also I'm not sure if there would be less complaints if
>>> AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on all
>>> at once in e.g. `base-5.0`, breaking almost *every* single package out there
>>> at once.
>>
>> I doubt the number of complaints-per-change would be fewer, but I'm strongly
>> in favor of moving away from what feels like a treadmill that doesn't value
>> the time of developers and that doesn't account for the
>> more-than-sum-of-parts cost of the "constant flux".
> 
> Broadly speaking, I'm a "fix it now rather than later" sort of person
> in Haskell because I've seen how long things can linger before finally
> getting fixed (even when everyone agrees on what the fix should be and
> agrees that it should be done). However, as I mentioned in the
> originating thread, I think that —at this point— when it comes to
> AMP/FTP/MFP/MRP/etc we should really aim for the haskell' committee to
> work out a comprehensive solution (as soon as possible), and then
> enact all the changes at once when switching to
> Haskell201X/base-5.0/whatevs.

In general: Yes, when everybody more or less agrees what the Right Thing
then this is probably the way to go. (But it still carries the risk of
e.g. C++ "template exports" which seemed a good idea a the time, but was
unimplementable.)

In this specific case: Isn't the proposal under discussion here more or
less the end game for the change to Applicative/Monad? (I mean, I don't
think anyone's seriously suggesting *removing* "return" completely any
time soon.)

If so, then I think the only thing punting this specific proposal to the
new Haskell' committe will achieve is to postpone the stream of
complaints :).

Plus, we still haven't seen that the new committe will actually achieve
anything of note. There seem to be be good signs, but we've been here
before...

> I understand the motivations for wanting
> things to be field-tested before making it into the report, but I
> don't think having a series of rapid incremental changes is the
> correct approach here. Because we're dealing with the Prelude and the
> core classes, the amount of breakage (and CPP used to paper over it)
> here is much higher than our usual treadmill of changes; so we should
> take that into account when planning how to roll the changes out.
> 

This seems to be ignoring the huge amount of planning that actually
*did* go into this proposal (and the BPP, etc.).

No amount of planning can get around the fact that some people simply
*don't want any change*.

Regards,