<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Dear Ghc-Steering-Committee,</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Here's an email from Tom Ellis about the GHC20xx thread.  Please do read it.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">(Who, if anyone, is the moderator of the ghc-steering-committee mailing list?)</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <b class="gmail_sendername" dir="auto">Tom Ellis</b> <span dir="auto"><<a href="mailto:tom-2019@jaguarpaw.co.uk">tom-2019@jaguarpaw.co.uk</a>></span><br>Date: Tue, 8 Nov 2022 at 08:04<br>Subject: Re: [ghc-steering-committee] GHC2023<br>To: Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@gmail.com</a>><br></div><br><br>Hello Simon, I sent this to the steering committee mailing list on<br>
Saturday but received an email in response saying it was "being held<br>
until the list moderator can review it for approval".  Perhaps no<br>
moderator has had the chance to review it yet, as it hasn't yet<br>
appeared on the mailing list archive<br>
<br>
<a href="https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/thread.html#start" rel="noreferrer" target="_blank">https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/thread.html#start</a><br>
<br>
Perhaps you would be kind enough to forward it to the list for me<br>
directly.  Thanks, Tom<br>
<br>
<br>
<br>
<br>
Thanks Simon.<br>
<br>
On reflection, I'm not particularly motivated to consult the community<br>
because the concerns I have impinge most strongly on members of the<br>
community who are distant from where a consultation could easily<br>
reach, and on non-but-potential-members of the community who are<br>
getting a false impression from afar.<br>
<br>
I will content myself with elaborating on my concerns and then leaving<br>
it to the steering committee to take them into account if they see<br>
fit.  To set the scene, everything I write below is presented from the<br>
point of view of someone who wishes Haskell usage to increase and<br>
believes that we can't increase Haskell usage by appealing to people<br>
who are already comfortable with the way the Haskell ecosystem<br>
currently works: we've already got most of those people.<br>
<br>
For the ten years that I have been in the community, Haskell has had a<br>
(false) reputation, to outsiders, as a fragmented language with<br>
multiple mysterious things called "language extensions" each of which<br>
fractures the language in an incompatible way.  "It's impossible to<br>
learn Haskell because there are so many incompatible Haskells" they<br>
say.  It may be hard to believe that this perception exists: as users<br>
of GHC we know that there are very few extensions that introduce any<br>
incompatibility with others; extensions typically just remove<br>
unneccesary restrictions.  But, for those of you who don't spend<br>
far-too-much of your time on discussion fora such as Hacker News and<br>
Reddit, I can guarantee to you that this objection to Haskell comes up<br>
*a lot*.<br>
<br>
Haskell also has, to both insiders and outsiders, a (true) reputation<br>
for being an unstable moving target.  "It's impossible to learn or use<br>
Haskell because the language and libraries keep changing", they say.<br>
This one is easier to believe.<br>
<br>
GHC2021 is a wonderful way of dealing with all of the first and part<br>
of the second objection!  I can now respond to complaints of language<br>
fragmentation and language instability by simply saying "Turn on<br>
GHC2021 and be happy".  This is great news!<br>
<br>
(GHC2021 doesn't deal with instability in libraries of course, but I'm<br>
pleased that there are many people making efforts in that area too.)<br>
<br>
I am concerned that GHC2023 would weaken the power of my rejoinder<br>
"Turn on GHC2021 and be happy".  Now I am at risk of the responses<br>
"But why not GHC2023?", "Haskell introduced a new, incompatible<br>
language just two years after standardising on GHC2021", "I just spent<br>
my precious time learning GHC2021, now I have to spend time learning<br>
GHC2023.".  Sure, these responses are based on misunderstandings of<br>
the technical details.  But perceptions really, really matter!  If we<br>
want a large increase in Haskell usage then we have to take<br>
perceptions into account.  We can't substantially increase Haskell<br>
usage any more by appealing just to our techncial excellence.<br>
<br>
If we choose to prioritise business-as-usual, that is, the<br>
incorporation of highly technically excellent features on a regular<br>
basis, with no thought to the costs, then the consequence will be<br>
Haskellers-as-usual: people who value that kind of thing in spite of<br>
the costs.  We already have most of those people.  We can't increase<br>
Haskell adoption that way.  If we choose to change tack then we have<br>
the chance of changing the types of people we pick up as new<br>
Haskellers, from among those who would never otherwise have considered<br>
the language.<br>
<br>
To put it pithily, Joachim writes in a sibling thread "The point of<br>
the GHC20xx series is to get (proven, useful, uncontroversial) goodies<br>
into the hands of our users".  Are members of the Haskell community,<br>
and indeed non-but-potential-members, screaming out for new "goodies"?<br>
Or are they screaming out for a brief respite from the unforgiving<br>
churn of the Haskell ecosystem, both real and not-real-but-perceived.<br>
My experience of the last ten years tells me it's the latter.<br>
<br>
To be clear, I personally am very much looking forward to more highly<br>
technically excellent features, including the exciting ongoing work on<br>
dependent types, WASM, GHCJS, and so on.  It's one of the aspects of<br>
the community that really inspires and excites me! I personally can<br>
tolerate the churn.  But I don't want those things at the *cost* of<br>
continuing to push away potential new users who are currently peering<br>
over the fence, discouraged because they can't tolerate the churn that<br>
they see, real or perceived.<br>
<br>
Now, with my stability hat on, looking from the point of view of<br>
process design, it's actually *better* for changes to happen in small<br>
increments, so maybe having GHC20xx every year is actually *better*<br>
than every five years.  I don't wish to advocate for one choice or<br>
another.  Rather I wish to advocate for the point of view that:<br>
<br>
  Technical excellence matters.  Stability and the perception of<br>
  stability matter too.<br>
<br>
Tom<br>
<br>
<br>
<br>
<br>
On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:<br>
> Another year has passed, and if we are serious with the idea that<br>
>> GHC20xx is a continuous thing, we should probably start defining<br>
>> GHC2023 – even if it is just a small delta.<br>
>><br>
><br>
> Indeed, we originally said we'd review GHC20xx annually, but I think we<br>
> might want to consult the community to see if that is too often.  There has<br>
> been an interesting thread<br>
> <<a href="https://discourse.haskell.org/t/quo-vadis-ghc2023/5220" rel="noreferrer" target="_blank">https://discourse.haskell.org/t/quo-vadis-ghc2023/5220</a>>on the Haskell<br>
> Discourse.<br>
><br>
> The HF Stability Working Group discussed this on Monday, and I think Tom<br>
> Ellis (a member of the SWG) is willing to lead a consultation.  I think<br>
> that would be great -- we have no axe to grind here, and I think we'll be<br>
> delighted to do whatever makes the maximal number of people happy.<br>
><br>
> Tom (cc'd) will write with more info shortly.  Sound OK?<br>
><br>
> Simon<br>
><br>
> On Mon, 24 Oct 2022 at 20:49, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>><br>
> wrote:<br>
><br>
>> Hi Committee,<br>
>><br>
>> when we defined the process for GHC20xx, as written in<br>
>><br>
>> <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst</a><br>
>> we wrote<br>
>><br>
>>    Likely, the first iteration of this process will be vastly different<br>
>>    from the following ones: The first one is expected to add a large<br>
>>    number of uncontroversial extensions; so the next iteration will<br>
>>    likely only make a smaller, but more controversial change.<br>
>><br>
>>    Therefore, this proposal does not commit to a fixed cadence.<br>
>>    Instead, 6 months after the first release of a version of GHC that<br>
>>    supports a GHC20xx set, we evaluate the outcome, the process, and<br>
>>    the perceived need of a next release. At that time we will refine<br>
>>    the processes, if needed, and set a cadence.<br>
>><br>
>> The first version of GHC that supported GHC2021 was 9.2, released in<br>
>> October 2022.<br>
>><br>
>> Last fall we said that not enough time has passed to do such an<br>
>> evaluation, and we skipped defining GHC2022.<br>
>><br>
>> Another year has passed, and if we are serious with the idea that<br>
>> GHC20xx is a continuous thing, we should probably start defining<br>
>> GHC2023 – even if it is just a small delta. This e-mail tries to<br>
>> kickstart that process.<br>
>><br>
>><br>
>> Last time we did a relative elaborate thing where we voted on<br>
>> essentially _every_ extension. I think that made sense for the first<br>
>> iteration, where we had to winddow down the likely extensions. But now<br>
>> we have a base line (GHC2021), and are asked to find a suitable delta,<br>
>> and I’d go for a nomination-based approach: Committee members can<br>
>> propose adding (or removing, in theory) specific extensions, and then<br>
>> we vote only on those. Does that sound reasonable?<br>
>><br>
>> Does anyone have any insight from the real world? Has GHC2021 helped<br>
>> our users? And if not, why not?<br>
>><br>
>> What kind of hard data would you like to see, if any?<br>
>><br>
>> (I’m a bit wary of spending too much time writing scripts to scrape<br>
>> hackage, for example to see which extensions people tend to enable _in<br>
>> addition_ to GHC2021, only to see that libraries on hackage are<br>
>> understandably slow to use default-language: GHC2021, as that’s not<br>
>> great for backward compat for now. But I am also not sure where to look<br>
>> for good data…)<br>
</div></div>