Breaking Changes and Long Term Support Haskell

[Edward Kmett]

On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins <greg at gregorycollins.net>
wrote:

>
> On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland <mainland at apeiron.net>
> wrote:
>
>> My original email stated my underlying concern: we are losing valuable
>> members of the community not because of the technical decisions that are
>> being made, but because of the process by which they are being made.
>>
> [If] you're doing research you're on the treadmill, almost by definition,
> and you're delighted that we're finally making some rapid progress on
> fixing up some of the longstanding warts.
>
> If you're a practitioner, you are interested in using Haskell for, y'know,
> writing programs. You're probably in one of two camps: you're in "green
> field" mode writing a lot of new code (early stage startups, prototype
> work, etc), or you're maintaining/extending programs you've already written
> that are out "in the field" for you doing useful work. Laura Wingerd calls
> this the "annealing temperature" of software, and I think this is a nice
> metaphor to describe it. How tolerant you are of ecosystem churn depends on
> what your temperature is: and I think it should be obvious to everyone that
> Haskell having "success" for programming work would mean that lots of
> useful and correct programs get written, so everyone who is in the former
> camp will cool over time to join the latter.
>

I've made the point before and I don't really want to belabor it: our de
> facto collective posture towards breaking stuff, especially in the past few
> years, has been extremely permissive, and this alienates people who are
> maintaining working programs.
>

Even among people who purported to be teaching Haskell or using Haskell
today in industry the margin of preference for the concrete FTP proposal
was ~79%. This was considerably higher than I expected in two senses. One:
there were a lot more people who claimed to be in one of those two roles
than I expected by far, and two: their appetite for change was higher than
I expected. I initially expected to see a stronger "academic vs. industry"
split in the poll, but the groups were only distinguishable by a few
percentage point delta, so while I expected roughly the end percentage of
the poll, based on the year prior I'd spent running around the planet to
user group meetings and the like, I expected it mostly because I expected
more hobbyists and less support among industrialists.

>
I'm actually firmly of the belief that the existing committee doesn't
> really have process issues, and in fact, that often it's been pretty
> careful to minimize the impact of the changes it wants to make. As others
> have pointed out, lots of the churn actually comes from platform libraries,
> which are out of the purview of this group.
>

Historically we've had a bit of a split personality on this front. Nothing
that touches the Prelude had changed in 17 years. On the other hand the
platform libraries had maintained a pretty heavy rolling wave of breakage
the entire time I've been around in the community. On a more experimental
feature front, I've lost count of the number of different things we've done
to Typeable or template-haskell.


> 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,
1 release that incorporated changes that were designed to minimize impact,
to the point that the majority of the objections against them are of the
form where people would prefer that we broke _more_ code, to get a more
sensible state. Going forward, it looks like the next 2 GHC releases will
have basically nothing affecting the Prelude, and there will be another
punctuation in the equilibrium around 8.4 as the next set of changes kicks
in over 8.4 and 8.6 That gives 2 years worth of advance notice of pending
changes, and a pretty strong guarantee from the committee that you should
be able to maintain code with a 3 release window without running afoul of
warnings or needing CPP.

So, out of curiosity, what additional stability policy is it that you seek?

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151022/8f6e0fb8/attachment-0001.html>