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