New subject: Fwd: GHC2023

8 Nov 2022

      Dear Ghc-Steering-Committee,

Here's an email from Tom Ellis about the GHC20xx thread.  Please do read it.

(Who, if anyone, is the moderator of the ghc-steering-committee mailing
list?)

Simon

---------- Forwarded message ---------
From: Tom Ellis 
Date: Tue, 8 Nov 2022 at 08:04
Subject: Re: [ghc-steering-committee] GHC2023
To: Simon Peyton Jones 

Hello Simon, I sent this to the steering committee mailing list on
Saturday but received an email in response saying it was "being held
until the list moderator can review it for approval".  Perhaps no
moderator has had the chance to review it yet, as it hasn't yet
appeared on the mailing list archive

https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/thre...

Perhaps you would be kind enough to forward it to the list for me
directly.  Thanks, Tom

Thanks Simon.

On reflection, I'm not particularly motivated to consult the community
because the concerns I have impinge most strongly on members of the
community who are distant from where a consultation could easily
reach, and on non-but-potential-members of the community who are
getting a false impression from afar.

I will content myself with elaborating on my concerns and then leaving
it to the steering committee to take them into account if they see
fit.  To set the scene, everything I write below is presented from the
point of view of someone who wishes Haskell usage to increase and
believes that we can't increase Haskell usage by appealing to people
who are already comfortable with the way the Haskell ecosystem
currently works: we've already got most of those people.

For the ten years that I have been in the community, Haskell has had a
(false) reputation, to outsiders, as a fragmented language with
multiple mysterious things called "language extensions" each of which
fractures the language in an incompatible way.  "It's impossible to
learn Haskell because there are so many incompatible Haskells" they
say.  It may be hard to believe that this perception exists: as users
of GHC we know that there are very few extensions that introduce any
incompatibility with others; extensions typically just remove
unneccesary restrictions.  But, for those of you who don't spend
far-too-much of your time on discussion fora such as Hacker News and
Reddit, I can guarantee to you that this objection to Haskell comes up
*a lot*.

Haskell also has, to both insiders and outsiders, a (true) reputation
for being an unstable moving target.  "It's impossible to learn or use
Haskell because the language and libraries keep changing", they say.
This one is easier to believe.

GHC2021 is a wonderful way of dealing with all of the first and part
of the second objection!  I can now respond to complaints of language
fragmentation and language instability by simply saying "Turn on
GHC2021 and be happy".  This is great news!

(GHC2021 doesn't deal with instability in libraries of course, but I'm
pleased that there are many people making efforts in that area too.)

I am concerned that GHC2023 would weaken the power of my rejoinder
"Turn on GHC2021 and be happy".  Now I am at risk of the responses
"But why not GHC2023?", "Haskell introduced a new, incompatible
language just two years after standardising on GHC2021", "I just spent
my precious time learning GHC2021, now I have to spend time learning
GHC2023.".  Sure, these responses are based on misunderstandings of
the technical details.  But perceptions really, really matter!  If we
want a large increase in Haskell usage then we have to take
perceptions into account.  We can't substantially increase Haskell
usage any more by appealing just to our techncial excellence.

If we choose to prioritise business-as-usual, that is, the
incorporation of highly technically excellent features on a regular
basis, with no thought to the costs, then the consequence will be
Haskellers-as-usual: people who value that kind of thing in spite of
the costs.  We already have most of those people.  We can't increase
Haskell adoption that way.  If we choose to change tack then we have
the chance of changing the types of people we pick up as new
Haskellers, from among those who would never otherwise have considered
the language.

To put it pithily, Joachim writes in a sibling thread "The point of
the GHC20xx series is to get (proven, useful, uncontroversial) goodies
into the hands of our users".  Are members of the Haskell community,
and indeed non-but-potential-members, screaming out for new "goodies"?
Or are they screaming out for a brief respite from the unforgiving
churn of the Haskell ecosystem, both real and not-real-but-perceived.
My experience of the last ten years tells me it's the latter.

To be clear, I personally am very much looking forward to more highly
technically excellent features, including the exciting ongoing work on
dependent types, WASM, GHCJS, and so on.  It's one of the aspects of
the community that really inspires and excites me! I personally can
tolerate the churn.  But I don't want those things at the *cost* of
continuing to push away potential new users who are currently peering
over the fence, discouraged because they can't tolerate the churn that
they see, real or perceived.

Now, with my stability hat on, looking from the point of view of
process design, it's actually *better* for changes to happen in small
increments, so maybe having GHC20xx every year is actually *better*
than every five years.  I don't wish to advocate for one choice or
another.  Rather I wish to advocate for the point of view that:

  Technical excellence matters.  Stability and the perception of
  stability matter too.

Tom

On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones 
wrote:
...
Another year has passed, and if we are serious with the idea that
...
GHC20xx is a continuous thing, we should probably start defining
GHC2023 – even if it is just a small delta.
Indeed, we originally said we'd review GHC20xx annually, but I think we
might want to consult the community to see if that is too often.  There
has
been an interesting thread
https://discourse.haskell.org/t/quo-vadis-ghc2023/5220on the Haskell
Discourse.
The HF Stability Working Group discussed this on Monday, and I think Tom
Ellis (a member of the SWG) is willing to lead a consultation.  I think
that would be great -- we have no axe to grind here, and I think we'll be
delighted to do whatever makes the maximal number of people happy.
Tom (cc'd) will write with more info shortly.  Sound OK?
Simon
On Mon, 24 Oct 2022 at 20:49, Joachim Breitner 
wrote:
...
Hi Committee,
when we defined the process for GHC20xx, as written in
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-gh...
...
we wrote
Likely, the first iteration of this process will be vastly different
   from the following ones: The first one is expected to add a large
   number of uncontroversial extensions; so the next iteration will
   likely only make a smaller, but more controversial change.
Therefore, this proposal does not commit to a fixed cadence.
   Instead, 6 months after the first release of a version of GHC that
   supports a GHC20xx set, we evaluate the outcome, the process, and
   the perceived need of a next release. At that time we will refine
   the processes, if needed, and set a cadence.
The first version of GHC that supported GHC2021 was 9.2, released in
October 2022.
Last fall we said that not enough time has passed to do such an
evaluation, and we skipped defining GHC2022.
Another year has passed, and if we are serious with the idea that
GHC20xx is a continuous thing, we should probably start defining
GHC2023 – even if it is just a small delta. This e-mail tries to
kickstart that process.
Last time we did a relative elaborate thing where we voted on
essentially _every_ extension. I think that made sense for the first
iteration, where we had to winddow down the likely extensions. But now
we have a base line (GHC2021), and are asked to find a suitable delta,
and I’d go for a nomination-based approach: Committee members can
propose adding (or removing, in theory) specific extensions, and then
we vote only on those. Does that sound reasonable?
Does anyone have any insight from the real world? Has GHC2021 helped
our users? And if not, why not?
What kind of hard data would you like to see, if any?
(I’m a bit wary of spending too much time writing scripts to scrape
hackage, for example to see which extensions people tend to enable _in
addition_ to GHC2021, only to see that libraries on hackage are
understandably slow to use default-language: GHC2021, as that’s not
great for backward compat for now. But I am also not sure where to look
for good data…)

Fwd: GHC2023

Simon Peyton Jones

Joachim Breitner

Arnaud Spiwack

Joachim Breitner

Arnaud Spiwack

Joachim Breitner

Joachim Breitner

Chris Dornan

Simon Peyton Jones

Joachim Breitner

Simon Peyton Jones

Joachim Breitner

Arnaud Spiwack

Richard Eisenberg

Simon Marlow

Simon Peyton Jones

Simon Marlow

Arnaud Spiwack

Simon Peyton Jones

Richard Eisenberg

Joachim Breitner

Richard Eisenberg

tags

participants (6)