Breaking Changes and Long Term Support Haskell

[Gregory Collins]

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.
>

I disagree. The issue is not process, it's posture: e.g. what do we think
the language is for, who are its users, what factors do we take into
consideration when making decisions about how to change things (and
especially: how do we weight those factors), etc. There are several
important constituencies within the Haskell community, and they usually
have very different attitudes towards what's relevant to take into
consideration when deciding what to do.

For example: Haskell has had great success and wide adoption in academic
research within a few fields centred around ICFP, POPL, and the like. We
all like a GHC that serves as a testbed for research and sometimes that is
going to mean churn. The research world would probably be happiest with a
Haskell that evolved quickly and speculatively, and that dispensed with
blemishes with savage efficiency: 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. 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.

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.

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