Would you mind sharing these publicly?
I’d rather not share them publicly because they’re not as polished as I would like (and I’ve learned of some improvements that could be made since I wrote them). But I’m happy to pass them on to you off-list, so feel free to shoot me an email at alex@dixonary.co.uk.
OK, email sent! Thanks.
It looks like there’s a "vicious cycle" at work here:
-
[…] I know regressions in Stack with newer GHC/Cabal versions (like overly aggressive recompilation, or broken deregister support for private libraries) causes the Stackage team pain and suffering. […]
-
[…] I wanted to package some Python packages that use
pypandoc, so I started adding haskell packages for packagingpandoc. IIRC this brought the first batch of 100+ haskell packages into the repositories. Then from time to time I added some other useful stuff on request, resulting in the over 600 packages now. Before the dynamic-only change it was somewhat hard to keep up with upstream already due to the very long build+upload time.
…and now this is apparently causing “pain and suffering” here and presumably elsewhere. So what’s the solution?
- We’re not the problem: they are! Let’s just cut 'em loose - then everything will be
awesomeall better…
That seems to be the way to an even smaller Haskell community in the long term - at this rate, we really ought to start working on a Haskell Machine just in case everyone else decides to “cut us loose” (along with Haskell)…
There’s a common problem across Stack, Arch Haskell and apparently here too: not enough people in each project to keep up with its maintenance. If we instead all unite around our shared interest - Haskell - to help solve each other’s problems in addition to our own, then Haskell will have a much better chance of thriving in the midst of newer competitors like Rust, Go, Zig (or existing ones like Standard ML).
1 Like
In the light of feedback, let me attempt a summary of my position and what I am proposing.
Proposal: That a button be added to www.haskell.org that says something like “try haskell” which links to GHCUp.
Technical:
The technical argument is very narrow. There is community consensus that HLS is a core part of “installing Haskell”. GHCUp is the reliable way to install HLS, and is the recommendation of the HLS team:
Direct installation from source, while possible via
cabal install haskell-language-serverandstack install --stack-yaml stack-<GHCVER>.yaml, is not recommended for most people. ~ Installation — haskell-language-server 1.7.0.0 documentation
If this technical judgement is accepted, neither cabal nor stack can be included as valid ways to “install Haskell” for new users.
This is true whether or not the GHCUp installation of stack meets the requirements of the stack team.
Social:
About 6 years ago, I recall sitting in a Haskell course being shamed and ridiculed for choosing to use stack. The instructor stopped presenting and, instead, watched over me as I uninstalled stack, hyperventilating about its shortcomings.
Events such as this are historically ubiquitous and often traumatic for everyone involved. The community has a trauma response whenever something vaguely akin to the old debates pops up, and I apologize if I haven’t handled this with enough sensitivity. There has been fault on both sides - I personally regret public comments about cabal I have made in the past - but it is canon that the stack project has been treated very shabbily.
Political:
it is currently politically untenable to treat ghcup and stack on anything other than an equal footing ~ https://github.com/haskell-infra/www.haskell.org/issues/166#issuecomment-1086726154
Technically, stack and ghcup are not on an equal footing, so the main reason progress towards a single onboarding is impeded is political.
The problem with the politics in this situation is manifold:
- Politics is at its best when it is open and subject to public scrutiny. After reading as widely as I could, I cannot discern who the stack team are and what their positioning is. Private and Board-level only lines of communication are breeding grounds for nepotism and dysfunction (as Michael Snoyman taught me).
- The political tradeoff in place puts the needs of new users in opposition to the need to make amends for past wrongs and build trust with the stack team.
- Setting the problem up as political encourages technical details to be used as ammunition, so that technical correctness is necessarily obfuscated in order to survive the politics.
In this context, set up as a political tradeoff, closely-held opinion and politics will ride roughshod over any appeal to the public good. The stack team will likely see technically valid arguments to promote GHCUp as an excuse to bash stack yet again, and will veto progress, via private comms at senior levels.
Solution:
If the technicals outlined above are correct, the problem doesn’t have to be constructed this way. We can both have a big button that reliably installs a version of what is a “Haskell installation” suitable for new users, and seek to build trust and empowerment of the stack team. They are not inextricably linked and they are both the right thing to do.
Perhaps some of them hang out here, but I also suggest you spread your message on Reddit, haskell-cafe and Twitter, at the very least. … I suspect they’re not particularly interested in chiming in
I can do this, but I worry it will be counter-productive to have the messaging cast by a single community member with little in the way of political clout.
If stack-aligned members of the community do not trust posting on this discourse (perhaps because they are fearful of the big pile-ons that this community is reknown for) then surely this is a core problem for the Foundation.
An alternative to this individualistic approach is for the Foundation to take ownership of the reality that the stack team has not been involved in public discussions, and seek to fix this. Facilitating a transparent, safe and centralised place to work things out must be the minimum standard for the leadership role the Foundation has. I imagine the stack team has representation at Board level, at least, and I would ask the Foundation for public comment representing their point-of-view.
Regardless, the status quo solution is dysfunctional, has low probability of success, and sounds bruising and exhausting. My proposal is to stop making these same mistakes over and over again. Acknowledge and separate the necessary reparation and healing work from the technical decision to promote GHCUp as a reliable way to install Haskell for new users.
1 Like
Alright, here’s a revised suggestion for www.haskell.org:
-
Rename “Downloads” to “Specialised Installations” so it no longer appears in the results of searches (note: the actual folder
downloads/can keep its name); -
Add a “Start Using Haskell Now!” button to
www.haskell.org; -
The URL for “Start Using Haskell Now!” is assigned to GHCUp (for the time being).
This seems to be the “best least-worst of both worlds”:
-
Unlike what happened in that course, Stack isn’t being purged - it’s merely relegated to being another alternative. If some find that annoying, they can help to improve Stack (maybe even to the point of surpassing GHCUp).
-
Keeping
downloads/(albeit under a different label) means there’s still a place on the Haskell site for other new “development suites” (even GHCUp was new once), or revitalised existing ones e.g. a future Stack.
1 Like
This is a fine proposal, and encapsulates the high points. If this issue was to gain some traction, I suggest exactly this as the starting point.
Specialised installation is a nice spot to put caveats about GHCUp as well. Cases where we know it fails, the problem areas, why you would prefer different tools like nix or stack, and any roadmaps or emergent tools that may replace it.
1 Like
Some replies to particulars of Tony’s message, before I write something more substantial.
To be clear, I made this comment specifically with regard to what is mentioned on the www.haskell.org Downloads page, that is to say, it is currently politically untenable to prioritise one or the other on that page. No other meaning of “equal” was intended to be implied. Having said that, it is politically tenable to start doing the community consensus building work needed to change this status quo. It just needs someone with time, will, energy and diplomatic skills.
Perhaps some of them hang out here, but I also suggest you spread your message on Reddit, haskell-cafe and Twitter, at the very least. … I suspect they’re not particularly interested in chiming in
I can do this, but I worry it will be counter-productive to have the messaging cast by a single community member with little in the way of political clout.
On the contrary, I think it could be very helpful to have this messaging come from a Stack user who cannot be interpreted as having a vested interest against Stack.
If stack-aligned members of the community do not trust posting on this discourse
To be clear, I don’t think that Stack community members mistrust posting on this Discourse. I simply don’t think they have much incentive to.
1 Like
Thanks Tony for writing up your thoughts in detail. To reiterate, I agree that simplifying the “Downloads” or “Get started” story on www.haskell.org is a valuable goal. The challenge is not technical. The challenge is to come up with something that has broad community consensus (that is, it is a political and diplomatic challenge).
I recently wrote about how I would tackle that challenge, and I’ll reproduce what I wrote below.
Perhaps the Haskell Foundation would be willing to convene an Onboarding Working Group to tackle this issue. If so, I would be willing to serve on it. Would you be willing too, Tony? The decision about whether to convene the group would be under the purview of Executive Director @david-christiansen.
-
Foster ongoing discussion in the community on the differences between stack and cabal, and stack and ghcup
The aim of the discussion would be to surface knowledge of the differences and to spread that knowledge. The technical differences are fairly well known but it’s still important to resurface them. The social differences are probably more implicit and thus more important to surface. It is important to understand why people use one tool over the other, what they value in the tool they use, and how they interact with the support networks that that tool provides (issue trackers, informal support channels on Haskell forums, etc.). The contemporary discussion on Reddit is an example of this kind of thing, but by “foster ongoing discussion” I mean try to make it a topic of interest across a wide range of community forums over a period of several weeks.
-
Widen the debate to discover whether there are any areas in which the differences between the tools can be reduced
This should be done with a clear understanding of the technical and social differences in mind, so must come after the step above. Examples of reducing the difference include adding Cabal support for Stackage LTS snapshots and having ghcup become an officially-supported installation method for Stack.
-
During this process I hope that trust will develop in the community that it is OK to have hard discussions on these topics without generating acrimony (I think this has actually happened organically over the last few years, but there’s still some more work to do).
-
I hope that one outcome of the process will be a community consensus regarding the different use cases of the different tools and therefore it will become clear and non-contentious how to describe the difference between the tools on www.haskell.org.
This whole process needs to be handled with delicacy, tact and empathy (although I think it’s less likely to become contentious than in years gone by).
By way of comparison, the “big buttons” of Python and Go both link to tarballs, so I think the haskell.org Downloads page is actually better than these!
2 Likes
onboarding working group would be great. It’s worthwhile knowing everything about our ecosystem, what we do and how we do it.
Since no-one has objected to what I’ve suggested, here’s a patch:
--- 000/Haskell Language.html
+++ 002/Haskell Language.html
@@ -25,10 +25,10 @@
</div>
<div id="haskell-menu" class="collapse navbar-collapse">
<ul class="nav navbar-nav navbar-right">
- <li><a href="./downloads/">Downloads</a></li>
<li><a href="./community/">Community</a></li>
<li><a href="./documentation/">Documentation</a></li>
<li><a href="./donations/">Donate</a></li>
+ <li><a href="./downloads/">Specialised Installations</a></li>
</ul>
</div>
</div>
@@ -45,6 +45,7 @@
<div class="branding">
<br class="hidden-xs"><img src="./img/haskell-logo.svg" class="img-responsive">
<h4 class="summary">An advanced, purely functional programming language</h4>
+ <a href="./ghcup/steps">Use it now!</a>
</div>
</div>
<div class=" span6 col-md-6">
All the Haskell site has to do is to refer to the GHCup page: it’s then up to the GHCUp devs as to what happens next. Even the Rust site has this two-step arrangement:
-
https://www.rust-lang.org- the main page, which refers to: -
https://www.rust-lang.org/tools/install- which determines what the OS is and provides a suitable invocation of the actualrustupcommand.
For simplicity, "Use it now! is just a plain ol’ HTML link - the choice of its appearance e.g. as a button can be considered later…
Seems plausible, but it’s not just here that where the consensus must be built, but across the entire Haskell community. If you want to move forward with this I’d suggest posting on Reddit, Twitter and haskell-cafe as well.
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
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
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.)
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?
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
I will submit a new issue, but I don’t really have any good ideas about how to solve it yet.
1 Like
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