Breaking Changes and Long Term Support Haskell

[Henrik Nilsson]

Hi Dan,

Thanks for the history lesson. You do make many valid points.
And I also want to say thank you for the hard work that CLC
has put in.

Let me nevertheless react to a handful of things:

 > And the answer was that there should be some body empowered to decide
 > to move forward with these ideas, even if there is some dissent. And
 > frankly, it wasn't going to be the prime committee, because it hadn't
 > shown any activity in something like 3 years at the time, and even
 > when it was active, it didn't make anywhere near the sort of changes
 > that were being discussed.

I have seen criticism of the Haskell committee along similar lines
before, but I think it is overly simplistic, and arguably unfair,
for two reasons. First, squarely measuring accomplishment in terms
of number or scope of changes, which seems to be the gist (apologies
if I misunderstand), is, frankly, naive. In many ways, what didn't
change, for example, can be at least as important as what did for
establishing a language as a viable and attractive proposition for
large scale work. And the value of that for a language community as a
whole is hard to overstate. Now, I have no real data to back up that the
committee achieved that. But it is clear that Haskell has grown
a lot over the past 5 to 10 years, i.e. well before AMP, FTP, etc.
So maybe the last instance of the Haskell committee actually achieved
a great deal more than some seem willing to give it credit for.

Secondly, let us not forget that at least one highly controversial
and very breaking change was adopted for Haskell 2010: dropping
n + k patterns. The reason that went through was that there were very
compelling technical reasons and ultimately a clear case for
the advantages outweighing the disadvantages by a wide margin. So it is
not as if a committee cannot make controversial decisions. That does
presuppose that the majority of its members fundamentally have the 
interest of the community at large at the fore, and are willing to take
good arguments aboard, rather than being prone to take stances mainly
for "political" reasons. Fortunately, I strongly believe the Haskell
community by and large is rational in this sense.

 > Forgive me if I'm wrong, but suggestions that these decisions should
 > have been deferred to a Haskell Prime committee mean, to me, that the
 > hope is that they would have been rejected.

OK, you are forgiven! I can of course only speak for myself, but I have
followed this discussion very carefully, and discussed with many people
in person. And as far as I can tell, there is absolutely nothing to
suggest that the reason that those who are unhappy with the process by
which AMP, FTP etc. happened (or by some of the details of those
proposals)  raise the possibility that the Haskell committee in one way
or another should have been (or in the future be) involved at least as
a vetting instance when it comes to the most far-reaching library
changes, is a secret hope of "death by committee".

Anyway, whether there are one or two committees ultimately does not
really matter, as long as both are widely seen to have a wide mandate
for whatever they are entrusted with, and as long as the process for
far-reaching changes is sufficiently robust and long.

 > That the Haskell Prime
 > committee should have just vetoed these proposals that something like
 > 80% or more of practicing Haskell users (as far as we can tell) wanted
 > for years before they finally happened.

Now, I have no desire to diminish the significance of the outcome of
that poll. Nor have I any desire to be branded as an "anti-democrat".
But if I am, so be it: I am bracing myself.

However, I have to point out that there is a lot more to
well-functioning democracies than simple majority votes. Look at any
developed democracy and there are lots of checks and balances in place
to safe-guard the interests of an as broad part of the population as
possible. In a federated state, just to give one example, there is
often a bicameral parliament where the states (broadly) have equal say
in one of the chambers irrespective of their size.

And yes, the workings of democracies are slow, sometimes painfully
so, but fundamentally that is for good reason.

To return to the case of a programming language community,
it is pretty much by definition going to be the case that a small
part of that community will be hit disproportionately hard by
changes to the language and/or its core libraries.

Their interests need to be adequately safeguarded too, or they will
surely jump ship in search of high and dry ground rather than run the
risk of drowning in the next wave of changes.

This, to the best of my understanding, is where I and others who
are suggesting that far-reaching changes should go past a
committee with a clear mandate and a sufficiently robust and long
process are coming from.

And I believe this is also what underlies Lennart's sentiment:

 > I think voting to decide these kind of issues a terrible idea; we
 > might as well throw dice.

Best,

/Henrik

-- 
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn at cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.