GHCUp button on www.haskell.org

#63

Sorry for the slow reply to your suggestion here @tomjaguarpaw - first I wanted to think carefully for a bit, and then I got sick. But I’m feeling better and I’ve done some thinking.

On the one hand, I do think that our “Download” page is confusing, and that this is not a good situation. Getting better at helping new people join the Haskell community is valuable.

On the other hand, I’m a bit nervous at forming a working group to bite off the most politically and emotionally difficult part of the process first. Earlier on this thread, the download page was described as low-hanging fruit, but I think that the emotional pitch of the discussion demonstrates that it really isn’t, despite what one might think. I think that a working group for onboarding new Haskellers is much more likely to be productive and successful if it first works on other things. Having built trust, both with each other and with members of the broader community, more contentious things can come into reach.

I wish we lived in a world where our feelings of identity weren’t tied up with our build tools, but we don’t. Here are some other onboarding-related things that could be interesting to look at, but with less potential to step on toes that are already sore from too many prior mis-steps:

  • The documentation page is quite overwhelming - how should a reader choose a particular book to read? Can we recommend materials based on the reader’s background and interests? Why do we use so much space to provide Git instructions to clone the 2010 report?
  • Reading typical Haddocks is a skill that takes time to develop. How can we speed this process up?
  • How do new Haskellers go about finding libraries for various tasks? Can we find a way to help them learn the “lore”?
  • Some compiler versions achieve “classic” status and are widely supported for a long time, while others pass by more quickly. How can we guide new Haskellers to the right version at the right time? The Stackage LTS choice is part of the answer, and the “recommended” tag in GHCup is part of the answer, but can we do more?
  • Can we make other updates to our tools and libraries that would make some of this documentation unnecessary? Are there ways to better coordinate community efforts here?

I’m sure that some of these also contain sore toes that I am simply not aware of, so please avoid those! I’m also quite certain that I am missing things that put off new Haskellers, and getting a proper inventory of that would be useful.

To summarize: I think that focusing on the difficulties faced by new Haskellers is absolutely valuable, but I don’t think we should try to fix this by dealing with the download page first. It is no fun to show wanting to work on one thing, and have someone say “but what about this other thing?”, so I understand if you don’t want to do a group on that basis.

What do you think?

6 Likes
#64

Why do we use so much space to provide Git instructions to clone the 2010 report?

This specific issue is easily dealt with:

I would welcome more such small patches on non-controversial issues from the community.

2 Likes
#65

Hello David, thanks for taking the time to write that up. All that you say makes a lot of sense, particularly your suggestion to progressively build trust by starting with less controversial issues.

I think convening an Onboarding Working Group on that basis is a viable and useful project.

(If you’re asking me whether I personally would want to get involved on that basis, then the answer is probably not. Most likely I’ll reserve my time and energy for contributing only to the most gnarly problems in the community, when necessary.)

#66

I really like that @hasufell just lists two high quality courses at the end of the “First Steps” page for GHCup. The haskell.org documentation page also already lists CIS 194 as the go-to course for beginners:

If you are new to Haskell and are not sure where to start from, we recommend CIS194. CIS194 is the introductory Haskell course of the University of Pennsylvania; it is free, thorough, practical and will guide you from the basics to advanced features of the language.

However that is not very noticeable with all the large headers and shiny links right below it.

Aren’t people from the stability working group already kind of working on this?

#67

Yes, true. Would you be willing to submit a PR to fix this? If not, would you be willing to submit a new issue about it? If not I’d like to tackle it but it will remain dependent on remembering it and having enough time.

1 Like
#68

I will submit a new issue, but I don’t really have any good ideas about how to solve it yet.

1 Like
#69

I totally understand that. I want to solve gnarly problems as well, and we all have to prioritize our time carefully!

While we’ve made a lot of progress as a community, I still think that a frontal attack on this particular issue is very risky, and if we alienate one or another half of the community, then it will undermine the ability of the HF to solve lots of other less-fraught issues. I think everyone agrees that the current state of the download page is not great, and I think you’re absolutely right when you point out that fixing it is a matter of building consensus between factions rather than finding a technical solution. But I think that the proposed committee and structure is too big of a risk for us to take in July 2022 - this may change over time, so let’s keep it in our minds.

(And I’m of course open to being persuaded on everything!)

3 Likes
#70

Yes, there’s the tick-tock release suggestion, which is another part of solving the issue for the future.

My goal was not so much to enumerate a list of particular things to discuss in detail, though - I wanted to define a category of onboarding issue by giving the first few examples that struck me, along with the formal definition of “issues that don’t require special sensitivity”.

1 Like
#71

Seems a reasonable point of view to me!

3 Likes
#72

I demanded GHC devs to make that distinction, but this was rejected: Advertise "latest" vs "recommended" GHC versions (#19901) · Issues · Glasgow Haskell Compiler / GHC · GitLab

1 Like
#73

GHCUp is already the reality, if you want a new user to have HLS installed, and has been battle-tested for a good while now. Any contention is solely due to poor form in the past, how we arrived at the current reality, and better dealt with separately.

If you reread the thread and the various issues lists, there has not been a single argument against it, other than let’s not scare the horses. Before we privilege community politics above the new user experience, let’s make sure the horses are even still in the paddock.

These dice were thrown long ago, and the risk event has already happened - alienation and fracturing of the community has been long-lasting and obvious.

I see an opportunity to just rip off the bandaid and enjoy delivering a single onboarding experience to the world. There are fences to be mended either way.

#74

There’s a book on this topic: Haskell (almost)… by Alejandro Serrano Mena [PDF/iPad/Kindle]
Maybe the author will be willing to make it freely available for a price, and maybe this is something the Haskell foundation could consider funding.

#75

Thanks to hellwolf:

As I dimly recall, there was also a lot of drama about this decision, but in the end it was also made for technical reasons…

#76

I’ve thought about this for quite a while and I’ve come to the conclusion that it’s not going to happen (wrt the two main tooling clans).

At this point, I don’t think it makes sense to invest energy into combining forces, being particularly diplomatic or discussing the same topic over and over again.

What makes sense is to focus on solving the issues that affect users. The driving attitude of this effort should be:

  1. whatever tooling gets the job done first and
  2. whatever tooling demonstrates exceptional openness to contributions and feedback

If this is stack and haskup, so be it. If it’s cabal and nix, so be it. The Haskell Foundation can reasonably drive improvement by staying politically neutral and favoring tools that meet the 2 criteria above. If someone misinterprets this approach as politically biased, then you can’t do anything about it. It is my opinion that the Haskell Foundation will take a bigger trust hit if it stays paralyzed and inactive on topics that have emotional baggage. This is really only about formulating very clear expectations and supporting the projects that meet these expectations, whichever those are at a given moment, as well as giving all potential projects the opportunity to demonstrate their fitness to meet these goals (this is what didn’t happen during the unified installer proposal: fairness).

Open source is constantly in flux. Some projects die off in a matter of months after having been active for decades. This is normal open source evolution.

Stack was a major milestone in Haskell tooling and wiped the floor with cabal that had pretty bad UX back then. I actually doubt that cabal today would be the same if stack maintainers had kept trying to improve cabal itself. They would have burnt out long before any noticable improvement.

It’s not always collaboration that drives improvement, sometimes it’s competition.

For collaboration, I think responsiveness is key. For competition, fairness is key. HF can foster both.

6 Likes
#77

This is certainly a gnarly problem, but I would urge the HF to not walk away from this.

At it’s creation, the HF was dedicated to broadening the adoption of Haskell, and support the Haskell tooling and infrastructure ecosystem.

The first major milestone of the HF was identification of the lack of a unified installation method as the major roadblock to Haskell adoption.

The project is listed as a proposal on the projects page:

https://haskell.foundation/projects/

Following this proposal, @hasufell and the GHCUp team went away and did the work (the work of angels) to get GHCUp up to scratch, adding stack to the tool list, solving the Windows issues and obviously striving to be the unified installer that the HF envisaged.

On establishment of these capabilities, a PR to simplify the installation section of www.haskell.org was opened.

In this PR, @chris, who is a HF Board member and the project leader of the HF unified installer project, commented:

Maybe at a future point a meaningful process for developing widely recognised universal installers can be established — I certainly hope so — but, as I see it, those conditions have yet to be met. In the meantime I think stack and ghcup should both be offered as methods of installing Haskell development environments on the dowload page.

This represents and remains the status quo, and what is being called into question.

This is a HF Board member and the project lead for the unification project declaring in a lone PR that it unification cannot happen and announcing that stack and ghcup must be treated equally, without any further commentary or discussion. Has there been any further communication from the HF about failure of the unification project?

Has it failed? I use GHCUp after years of stack-only usage and rate it a marvellous success. It unifies us. It wants to get better and compete with new and emergent tools. It has demonstrated due care and attention towards stack usage. I want new users to enjoy this success and for the Haskell community to celebrate this win.

This is why, within this context, I contend that it is a mistake for the HF to walk away from this issue because, well, politics. The evidence suggests that, in fact, the activities of the HF has been prime causal in creating this gnarly milieu within which we are now stuck. Avoiding contention creates an impregnable defence against progress when the contentious bits are coming, in large part, from within your own tent.

Politics be damned, support GHCUp now, based on technical merit.

7 Likes
#78

I agree with pretty much everything Tony has said here – ghcup has really proved itself as a universal tool with very wide adoption across the whole community and, in my view, that should be reflected in the download page.

At the time that I wrote the above this wasn’t really true, or sufficiently true – at least as I saw it. Sometimes it is worth waiting a while rather than forcing things. (The reason we have ended up where we have, in my view, is because various parties in the past have tried to force things too quickly in the community.)

I will certainly do what I can to support @david-christiansen in getting things moved along.

7 Likes
#79

Thanks for the support, Chris. I certainly still agree with much of your commentary, especially that GHCUp might not be an ideal way to install stack for a stack-based workflow, especially if HLS isn’t important (or out-of-order).

#80

I’m sorry if I gave the impression that I don’t think this problem (a confusing downloads page on haskell.org) is worth solving, because I absolutely do think that it is. On the other hand, I remain unconvinced that the proposed working group is the best way to get to a solution, because I think it carries a substantial risk of falling apart in a way that gets in the way of our ability to do other important things, and that this risk is not commensurate to the reward if successful. This assessment is based in part on what happened the last time around.

Why do you think that this particular suggestion is the best way to go, @tonyday567? Or does our miscommunication run deeper? My goal here is not to “win” a debate - I really want to make the best possible decisions, and there very well could be changes that I’m not aware of!

1 Like
#81

Let me try another suggestion then. I suggest we have an initial one hour meeting to bring together people who are interested in tackling the “one download tool problem”. The meeting should be for the purpose of sharing perspectives and widening the of understanding of each participant, with regard to difficulties we might face in tackling it. It should not be for the purpose of taking action!

If it turns out that attendees at that meeting do not cover a broad enough range of community perspectives then it may well be that there is no follow up that can be made, at least for now. But we will all come out a little wiser.

Alternatively we can continue to discuss asynchronously here or elsewhere.

#82

The GHC hook PR was merged: https://github.com/commercialhaskell/stack/pull/5585

This means that ghcup has a path to integrate better with stack. This will also fix a lot of issues users have with stack+HLS and ABI incompatibilities . It also means ghcup will by default install both stack and cabal.

The progress is tracked here: Finalize stack integration (#392) · Issues · Haskell / ghcup-hs · GitLab

10 Likes