[Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP

[Gregory Collins]

On Tue, Oct 6, 2015 at 6:18 PM, Gershom B <gershomb at gmail.com> wrote:


>
> With that in mind, I think the _concrete_ voices of concern have been the
> most useful. Gregory Collins’ list of issues requiring CPP should be very
> sobering. Of note, I think they point to areas where the core libraries
> committee has not paid _enough_ attention (or perhaps has not been
> sufficiently empowered: recall that not all core libraries fall under its
> maintenance [2]). Things like the newtype FFI issue, the changes to prim
> functions, the splitup of old-time and the changes to exception code were
> _not_ vetted as closely as the AMP and FTP were, or as the MRP is currently
> being. I don’t know all the reasons for this, but I suspect they just
> somewhat slipped under the radar.


In fact, more often than I would like, I can recall arguing against a
particular change
<https://www.mail-archive.com/ghc-devs@haskell.org/msg02133.html> on the
grounds that it would break user code, and in Haskell land this is a battle
I usually lose. Usually the argument on the other side boils down to
expediency or hygiene/aesthetics -- it's *difficult* to engineer a change
to some core infra in a way that minimizes impact on people downstream, and
it takes a long time. Often "this change is going to cause a small amount
of work for all of my users" is something that seems to not be taken into
consideration at all.

For this particular proposal, every user will have some small amount of
work *w* to do (to read the change notes, understand why 'return' is going
away, train yourself to use "pure" now instead of "return" like you've been
using for 15 years, etc). It might feel like *w* is small and so the change
isn't burdensome, but *n* is literally everyone who uses the language, so
the total work *w***n* is going to amount to quite a few person-hours. I
just want to make sure that everyone is keeping that in mind and weighing
that effort against the benefits.

Outside of that, the most disruptive changes to my code that I can recall
> have been from changes to the aeson library over the years — particularly
> but not only regarding its handling of doubles. I don’t begrudge these
> changes — they iteratively arrived at a _much_ better library than had they
> not been made. [3] After than, I made a few changes regarding Happstack and
> Snap API changes if I recall. Additionally, the addition of “die” to
> System.Exit caused a few name clashes. My point is simply that there are
> many packages outside of base that also move, and “real” users with “real”
> code will these days often have quite a chain of dependencies, and will
> encounter movement and change from across many of them. So if we say “base
> never changes” that does not mean “packages will never break” — it just
> means that base will not have the same opportunity to improve that other
> packages do, which will eventually lead to frustration, just as it did in
> the past and in the leadup to the BBP.
>

Culturally, we have a problem with library authors of all stripes being too
cavalier about breaking user programs: we definitely lean towards "move
fast and break things" vs "stay stable and don't make work for users". As
you write more and more Haskell code, you depend on more and more of these
libraries, and this means that once you go beyond a certain threshold you
will be spending a significant amount of your time just running to keep up
with the treadmill. Personally I just don't have enough time for writing
Haskell code as I used to (or I would like), so I would say for me that the
treadmill tax is now probably exceeding 50% of my total hours invested.

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151007/9f1c0f7c/attachment.html>