<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins <span dir="ltr"><<a href="mailto:greg@gregorycollins.net" target="_blank">greg@gregorycollins.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 dir="ltr"><div class="gmail_extra"><span class=""><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 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></span></div><div class="gmail_extra">[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></blockquote><div><br></div><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 dir="ltr"><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. </div></div></blockquote><div><br></div><div><div>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.</div><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 dir="ltr"><div class="gmail_extra"></div></div></blockquote></div><div><br></div><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 dir="ltr"><div class="gmail_extra">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></blockquote><div><br></div><div>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.</div><div> </div><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 dir="ltr"></div></blockquote><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 dir="ltr"><div class="gmail_extra"></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></blockquote><div><br></div><div>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.</div><div><br></div><div>So, out of curiosity, what additional stability policy is it that you seek?<br></div><div><br></div><div>-Edward</div></div></div></div>