<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland <span dir="ltr"><<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":21q" class="" style="overflow:hidden">My original email stated my underlying concern: we are losing valuable<br>
members of the community not because of the technical decisions that are<br>
being made, but because of the process by which they are being made.</div></blockquote></div><br>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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br>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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div>-- <br></div><div class="gmail_signature">Gregory Collins <<a href="mailto:greg@gregorycollins.net" target="_blank">greg@gregorycollins.net</a>></div>
</div></div>