On Sat, Apr 02, 2022 at 11:19:01PM +0300, Gleb Popov wrote:

On Sat, Apr 2, 2022 at 9:51 PM Tom Ellis < tom-lists-haskell-cafe-2017@jaguarpaw.co.uk> wrote:

...

The Haskell.org committee is considering removing the "alternative installation options" section from the [downloads page of haskell.org](https://www.haskell.org/downloads/) and we seek the opinion of the community. If you would like to share your opinion we prefer that you do so [on the haskell.org issue tracker](https://github.com/haskell-infra/www.haskell.org/issues/170), but failing that, in this email thread is fine too.

### Background

The [downloads page of haskell.org](https://www.haskell.org/downloads/) suggests using ghcup and stack to obtain a toolchain. These two tools are widely used in the community, actively maintained and kept up-to-date. The page also provides a number of "alternative installation options" (see below, or on the page itself, for the list).

Huh, why does this page say

...

To install stack, follow the instructions here (N.B. stack does not support FreeBSD)

?

Stack works on FreeBSD just fine for a long time.

I took the decision to make that claim following the (lack of) discussion at https://github.com/commercialhaskell/stack/issues/5674 If the claim is wrong perhaps you could add some commentary to that ticket. N.B. as reported by Julian Ospald the 'curl | sh' in the Stack Install/ugrade guide[1] doesn't work on FreeBSD. How are FreeBSD users supposed to install it? Tom [1] https://docs.haskellstack.org/en/stable/install_and_upgrade/

* I don't know where you are getting info about which project is used more or less* Well, that's why we have the State of Haskell survey, right?.. Which installation methods do you use for your Haskell compiler? https://taylor.fausak.me/2021/11/16/haskell-survey-results/#s2q1 Here are results for options gathered >10%. [image: Screenshot from 2022-04-02 22-39-01.png]

Since I'm already writing this, I add my 2c. I've been using HVR's PPA for years, switched to ghcup and never regretted it. It's strictly better in terms of 1) UI/UX, 2) maintenance (shout out to ghcup's maintenance team: it's just amazing). I believe haskell.org should refer to the most modern, nice-looking, wide-used (see results above), well-maintained solutions that deliver reasonably fresh versions of the toolchain. This contradicts with trying to survey most known solutions (because e.g. some of those will not be maintained or will have outdated versions, etc.). Alternative methods section requires crowdsourcing, and the best way to handle that imo is a wiki page. I think the current section for "alternative methods" should be turned into one and referenced from the Downloads page with the asterisk "for the curious". If only we had a healthy functioning wiki, sigh… -- Kind regards, Artem On Sat, 2 Apr 2022 at 18:26, Ivan Perez wrote:

I think it's perfect as they are and I'd advise against changing it.

I personally discourage the use of stack or ghcup, and would certainly prefer to see more installation methods based on package-management tools that each OS provides. I think there's something to be said in favor of using standard package-management tools that install the compiler in global space.

In particular, the PPA-based installation method for Debian/Ubuntu/Mint that HVR used to maintain was excellent. It's still my preferred method (even though it's not maintained). I don't know where you are getting info about which project is used more or less, and I fear there may be a strong bias.

Leaving them there is more fair, makes more people aware of their existence, and makes it more likely that newcomers will be able to participate in other efforts.

For Haskell to remain a community project, it's good that we keep mentioning less popular projects, even when attention temporarily sways one way or another. If you remove other projects from the web page, you create an effect of compound interest (or compound attention) towards those projects, where they get the most contributions because they are the ones that most people are aware of because they are on the front page because they get the most contributions, and so on and so forth.

Ivan

On Sat, 2 Apr 2022 at 14:51, Tom Ellis < tom-lists-haskell-cafe-2017@jaguarpaw.co.uk> wrote:

...

The Haskell.org committee is considering removing the "alternative installation options" section from the [downloads page of haskell.org](https://www.haskell.org/downloads/) and we seek the opinion of the community. If you would like to share your opinion we prefer that you do so [on the haskell.org issue tracker](https://github.com/haskell-infra/www.haskell.org/issues/170), but failing that, in this email thread is fine too.

### Background

The [downloads page of haskell.org](https://www.haskell.org/downloads/) suggests using ghcup and stack to obtain a toolchain. These two tools are widely used in the community, actively maintained and kept up-to-date. The page also provides a number of "alternative installation options" (see below, or on the page itself, for the list).

The Haskell.org committee does not have the resources to ensure that these alternative installation options are kept maintained and confirmed working. We don't even know if anyone uses them. Anyone who uses them is likely to be an "advanced user" anyway, since they require more expertise to implement. stack and ghcup presumably work well on all those platforms, are the most well-maintained installation options and most suitable for beginners.

### Possibilities

We have a couple of options:

1. Remove all the alternative installation options. 2. Keep (some of) the alternative installation options and find community volunteers to maintain them. The volunteers will be responsible for ensuring verifying on a regular basis that their instructions are still working, submitting timely corrections when necessary, and responding promptly on the issue tracker to questions about their installation instructions.

### What we would like from you

* Please share your opinion about removing the alternative installation options, especially if you are a user of one of them! * If you are willing to maintain an alternative installation option, please speak up!

### Current alternative installation options

* Linux Ubuntu (confusing (see https://github.com/haskell-infra/www.haskell.org/issues/16) and probably outdated) * Linux Debian (links to https://downloads.haskell.org/~debian/ which doesn't support Debian 11 Bullseye) * Linux Fedora * Linux EPEL for RHEL/CentOS/etc * Linux Arch * Linux openSUSE Leap * Linux openSUSE Tumbleweed * Linux Gentoo * Windows Chocolatey

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

On Sun, Apr 03, 2022 at 01:26:55PM -0400, Ivan Perez wrote:

On Sat, 2 Apr 2022 at 22:58, Artem Pelenitsyn wrote:

...

...

* I don't know where you are getting info about which project is used more or less* Well, that's why we have the State of Haskell survey, right?..

I've been programming in Haskell for more than 20 years (more than half of those professionally to some extent).

In all that time, I think I filled in one, and just one, of those, when I was first aware of their existence (years ago).

Even basing a decision on that survey carries with it a strong bias: you'd be basing that decision on the kind of respondent who would participate in the first place.

Who are you leaving behind?

Well, good question, but back at you: who are you discouraging from Haskell by keeping a large number of complex, unmaintained, possibly completely wrong, installation instruction on the Downloads page? Tom

On Sun, Apr 03, 2022 at 07:57:47PM +0200, Bardur Arantsson wrote:

On 03/04/2022 19.34, Tom Ellis wrote:

...

Well, good question, but back at you: who are you discouraging from Haskell by keeping a large number of complex, unmaintained, possibly completely wrong, installation instruction on the Downloads page?

I have no strong feelings either way, but would it perhaps be viable to just leave that "Alternative installation options" as a simple link to a separate page perhaps be sufficent to guide people to use either of the two 'main' options while still leaving the alternatives semi-documented? Has that been considered?

(I think just adding a disclaimer that the 'alternative methods' are not supported per se, but perhaps simultaneously encouraging corrections might be a way to lessen the maintenance burden?)

The problem that I am trying to solve is that no one with maintenance responsibility for the haskell.org website knows if those alternative installation methods work, are up-to-date, are currently supported by the (external) teams that put them together, etc.. It is not doing right by the community to publish information that we cannot support or verify. If someone is willing to be the "owner" of a particular installation method, to ensure it is kept up to date and high quality, then we'll keep it! To reiterate what I said in my first email, we can ... "Keep (some of) the alternative installation options and find community volunteers to maintain them. The volunteers will be responsible for ensuring verifying on a regular basis that their instructions are still working, submitting timely corrections when necessary, and responding promptly on the issue tracker to questions about their installation instructions" Tom

There's no need to keep them on a separate page. If the purpose of keeping them around (on the same or on a separate page) is to make people aware that these methods exist, putting them away on a separate page achieves none of the goals (near to no awareness) and has the same drawbacks in terms of effort required. It's sufficient to keep them on the same page in a separate section. If you are clean and organized, nobody will be confused or distracted. Ivan On Sun, 3 Apr 2022 at 14:29, Bardur Arantsson wrote:

On 03/04/2022 20.10, Tom Ellis wrote:

...

On Sun, Apr 03, 2022 at 07:57:47PM +0200, Bardur Arantsson wrote:

...

On 03/04/2022 19.34, Tom Ellis wrote:

...

Well, good question, but back at you: who are you discouraging from Haskell by keeping a large number of complex, unmaintained, possibly completely wrong, installation instruction on the Downloads page?

I have no strong feelings either way, but would it perhaps be viable to just leave that "Alternative installation options" as a simple link to a separate page perhaps be sufficent to guide people to use either of the two 'main' options while still leaving the alternatives semi-documented? Has that been considered?

(I think just adding a disclaimer that the 'alternative methods' are not supported per se, but perhaps simultaneously encouraging corrections might be a way to lessen the maintenance burden?)

The problem that I am trying to solve is that no one with maintenance responsibility for the haskell.org website knows if those alternative installation methods work, are up-to-date, are currently supported by the (external) teams that put them together, etc.. It is not doing right by the community to publish information that we cannot support or verify.

If someone is willing to be the "owner" of a particular installation method, to ensure it is kept up to date and high quality, then we'll keep it! To reiterate what I said in my first email, we can ...

"Keep (some of) the alternative installation options and find community volunteers to maintain them. The volunteers will be responsible for ensuring verifying on a regular basis that their instructions are still working, submitting timely corrections when necessary, and responding promptly on the issue tracker to questions about their installation instructions"

I did read the OP. My point was simply that it might be acceptable to have half-working (or whatever) instructions if they were squirreled away behind a link + disclaimer. That might be better for people who (for whatever reason) don't want either of the officially supported methods.

Regards,

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

I have to imagine various distributions' maintainers would be unhappy to find their packaging referred to as "unverified". (Aside from Arch's, who apparently just don't care how much of a painful mess they make for their users.) On Sun, Apr 3, 2022 at 2:36 PM Tom Ellis wrote:

On Sun, Apr 03, 2022 at 08:23:58PM +0200, Bardur Arantsson wrote:

...

I did read the OP. My point was simply that it might be acceptable to have half-working (or whatever) instructions if they were squirreled away behind a link + disclaimer. That might be better for people who (for whatever reason) don't want either of the officially supported methods.

My personal point of view is that it is counterproductive to have unverified, unmaintained information on the website anywhere, even squirreled away. But thank you for this suggestion. We will take it into consideration and enact it if there is sufficient support.

Tom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- brandon s allbery kf8nh allbery.b@gmail.com

On Sun, 3 Apr 2022 at 14:48, Tom Ellis < tom-lists-haskell-cafe-2017@jaguarpaw.co.uk> wrote:

Yet, their work has not been (recently) confirmed working by those responsible for maintaining www.haskell.org, nor do we have the resources to perform such confirmations.

You (I don't mean necessarily you personally) are still making a decision based on your lack of resources to determine if something is up to date. Is not that they are not up to date, it's that you don't know if they are (and you know that you don't know, since you are acknowledging it). But you are still willing to not list them. Since people are putting a lot of effort into maintaining that work, by ignoring that (due to lack of resources) you are contributing to that compound effect I was describing. They are doing this for the community, but the community seems to ignore them. I think it's more fair to acknowledge those efforts, to let people list what they think is useful for them. If the problem is understanding if those methods still work, perhaps what we need is a mechanism to keep track of installation methods available and the last time they were verified. That detailed info can be used to keep the page up to date. Ivan

I think I remember myself as an inexperienced user. I might've walked away from Haskell, if I was given an instruction like "to install thing X, first install thing A, then use it to install think K, and then use that to install thing X". The longer the way between becoming curious about something and actually producing an executable, the less new users you have.

On 3 Apr 2022, at 23:24, Tom Ellis wrote:

On Sun, Apr 03, 2022 at 02:58:03PM -0400, Ivan Perez wrote:

...

On Sun, 3 Apr 2022 at 14:48, Tom Ellis wrote:

...

Yet, their work has not been (recently) confirmed working by those responsible for maintaining www.haskell.org, nor do we have the resources to perform such confirmations.

You (I don't mean necessarily you personally) are still making a decision

So far no decision has been taken. The Haskell.org committee has a made a proposal and is seeking community feedback. Action will be taken based on consideration of the feedback received.

...

based on your lack of resources to determine if something is up to date. Is not that they are not up to date, it's that you don't know if they are (and you know that you don't know, since you are acknowledging it). But you are still willing to not list them.

You are correct that the proposal is to err on the side of removing information that may be unhelpful, rather than keeping information that may be helpful. I prefer the former since it seems to strike a good balance between providing a clear onboarding path to inexperienced users, providing a uniform onboarding path to make providing support easier, providing sufficient experieced users with a wide range of options, and allowing maintenance by a small group of volunteers with not much time on their hands.

That said, the current downloads page says

"EPEL 5 and 6 have ghc-7.0.4 and cabal-install-0.10.2"

and I know for a fact that is about five years out of date. Indeed it seems that EPEL 5 was EOLed in 2017

https://fedoramagazine.org/the-end-of-the-line-for-epel-5/

...

Since people are putting a lot of effort into maintaining that work, by ignoring that (due to lack of resources) you are contributing to that compound effect I was describing. They are doing this for the community, but the community seems to ignore them.

I think it's more fair to acknowledge those efforts, to let people list what they think is useful for them.

I'm very much in favour of letting people list what they think is useful for them, and to promote the OS packaging work that people have put a lot of effort in to. We simply need to find volunteers who are willing to put in the effort to keep the information we provide correct, up to date, and thus, useful. Part of this proposal is to reach out to potential volunteers. Would you be willing to volunteer? If so then please introduce yourself at the following GitHub discussion:

https://github.com/haskell-infra/www.haskell.org/discussions/169

...

If the problem is understanding if those methods still work, perhaps what we need is a mechanism to keep track of installation methods available and the last time they were verified. That detailed info can be used to keep the page up to date.

That sounds like a great idea. Would you be willing to implement that idea?

Tom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

On 2022-04-03, MigMit wrote:

I think I remember myself as an inexperienced user. I might've walked away from Haskell, if I was given an instruction like "to install thing X, first install thing A, then use it to install think K, and then use that to install thing X". The longer the way between becoming curious about something and actually producing an executable, the less new users you have.

Hear, hear. We use Haskell in our first-year course. Almost all students turn up with bog-standard commodity hardware: Windows laptops, Macs, or Chromebooks, with a small proportion of Linux laptops (those people are usually ok). Every year it takes the first two weeks of semester to handhold them all through the process of getting Haskell installed and working. I don't do Windows or Mac, so I don't even know why some (but not all) have problems - but they do. They don't have the choice to walk away, but it wastes valuable learning time, and gives a negative impression. Some of them then find out that they like Haskell, and some that they hate it - I suspect more would like it if they weren't put off by the initial hurdle of getting the damn thing working at all. Having a one-click install for the popular architectures would do a lot for new users, especially if it includes popular stuff like QuickCheck (I suppose QuickCheck is popular - I don't do Haskell, I just have to tutor it:) )

However, I'm a bit puzzled by the experience of your students. The Downloads page[1] already contains a link to ghcup which is a one-click installer (or rather a one-click-to-paste-into-the-terminal installer) for the popular architectures. It should work as well on Windows and Mac as it does on Linux.

Sad to say, but even among computer science students there is a world of difference between a '1 click' installer and one line of shell code to run. Sent from my phone with K-9 Mail. On 4 April 2022 13:28:56 UTC, Tom Ellis wrote:

On Mon, Apr 04, 2022 at 10:03:11AM +0100, Julian Bradfield wrote:

...

On 2022-04-03, MigMit wrote:

...

I think I remember myself as an inexperienced user. I might've walked away from Haskell, if I was given an instruction like "to install thing X, first install thing A, then use it to install think K, and then use that to install thing X". The longer the way between becoming curious about something and actually producing an executable, the less new users you have.

We use Haskell in our first-year course. Almost all students turn up with bog-standard commodity hardware: Windows laptops, Macs, or Chromebooks, with a small proportion of Linux laptops (those people are usually ok). Every year it takes the first two weeks of semester to handhold them all through the process of getting Haskell installed and working. I don't do Windows or Mac, so I don't even know why some (but not all) have problems - but they do. They don't have the choice to walk away, but it wastes valuable learning time, and gives a negative impression. Some of them then find out that they like Haskell, and some that they hate it - I suspect more would like it if they weren't put off by the initial hurdle of getting the damn thing working at all.

Having a one-click install for the popular architectures would do a lot for new users, especially if it includes popular stuff like QuickCheck (I suppose QuickCheck is popular - I don't do Haskell, I just have to tutor it:) )

Hello Julian,

Thanks very much for sharing this perspective. The more different perspectives we hear the better idea we have of how to improve the situation for a broad range of users and use cases.

However, I'm a bit puzzled by the experience of your students. The Downloads page[1] already contains a link to ghcup which is a one-click installer (or rather a one-click-to-paste-into-the-terminal installer) for the popular architectures. It should work as well on Windows and Mac as it does on Linux.

If there is any way you could share more detailed experience reports with us I would be very grateful. Perhaps there's something we can fix or improve, but I don't know yet what!

Tom

[1] https://www.haskell.org/downloads/ _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

On Mon, Apr 04, 2022 at 01:44:24PM +0000, Keith wrote:

...

However, I'm a bit puzzled by the experience of your students. The Downloads page[1] already contains a link to ghcup which is a one-click installer (or rather a one-click-to-paste-into-the-terminal installer) for the popular architectures. It should work as well on Windows and Mac as it does on Linux.

Sad to say, but even among computer science students there is a world of difference between a '1 click' installer and one line of shell code to run.

I can certainly believe that, but without more precise details of exactly what form that difference takes I can't do much about improving the situation. Tom

There is already a good Haskell toolchain installer for VS Code, which is hopefully already available in a suitable form. Not a web IDE, but might start to address some of these problems. As for web IDEs, I believe tomsmeding has something in the works that might also be a good start. On Mon, Apr 4, 2022 at 10:53 AM Richard Eisenberg wrote:

For what it's worth, I completely agree that installation problems are very bad for students, along at least two axes: students can never seem to install software, and their inability to install software gives them a negative outlook on the course.

If we wish to optimize for students, I think the only way forward is to get something in the e.g. Mac App Store. They know how to install from their system's app store. (I don't know what Windows uses.) Or equivalently their distribution's package manager. Anything beyond that is a struggle. This is not an easy problem to fix! To me, the real solution is to have a fully-featured web IDE. A professor might encourage students to install locally, but with a web IDE backstop, the student's failure to install won't stop them from making progress -- and maybe even the professor delays encouraging the local install by a few weeks, to get students motivated by showing them how fun Haskell is.

Developing a web IDE is beyond the scope of this discussion. But maybe this post suggests that OS-oriented packagers are important and should get a mention on the page. It could be something as simple as "Your system's package manager or app store may also have installers for the Haskell toolchain, maintained by community contributors." at the bottom of the page.

Richard

...

On Apr 4, 2022, at 9:51 AM, Tom Ellis wrote:

On Mon, Apr 04, 2022 at 01:44:24PM +0000, Keith wrote:

...

...

However, I'm a bit puzzled by the experience of your students. The Downloads page[1] already contains a link to ghcup which is a one-click installer (or rather a one-click-to-paste-into-the-terminal installer) for the popular architectures. It should work as well on Windows and Mac as it does on Linux.

Sad to say, but even among computer science students there is a world of difference between a '1 click' installer and one line of shell code to run.

I can certainly believe that, but without more precise details of exactly what form that difference takes I can't do much about improving the situation.

Tom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- brandon s allbery kf8nh allbery.b@gmail.com

On Sun, 3 Apr 2022 at 14:11, Tom Ellis < tom-lists-haskell-cafe-2017@jaguarpaw.co.uk> wrote:

On Sun, Apr 03, 2022 at 07:57:47PM +0200, Bardur Arantsson wrote:

...

On 03/04/2022 19.34, Tom Ellis wrote:

It is not doing

right by the community to publish information that we cannot support or verify.

A key factor with respect to the problem I am seeing at large, over large periods of time, is that the Haskell community has a very, very strong tendency to start new efforts instead of contributing to existing ones. We have witnessed it in the appearance of installation tools, language extensions, competing libraries, efforts to control/guide the discourse regarding key parts of the Haskell infrastructure, you name it. There were excellent, excellent methods to install and setup haskell quickly that did not warrant the creation of yet more methods. And yet, those have been created, standard installation methods abandoned, and here we are. The feeling I have is that we are going around in circles. That has left a lot of people burned out. What was once a joy (programming in Haskell) has become, for many, a drain, and they have abandoned their work when a competing effort was hyped up. I'm sure you can all identify Haskellers who have left and/or taken very long breaks due to burn out. The attitude we should have with respect to these efforts is not "can we focus on advertising what is maintained", but rather "what is the story we would like to tell, about the language, and the community". I would like the community to avoid giving a few people control over the conversation. I would like technical merit to trump over hype. And there's a lot of technical merit in solutions outside ghcup/stack that deserve attention and recognition. And the fact that not all of us agree indicates that, as a community, we should recognize those efforts and not erase them. To achieve that effect, it's enough to keep them at the bottom of the page, and anyone who determines that the effort is maintained should be welcome to move it to the top. Ivan

On Sun, Apr 3, 2022 at 5:29 PM Tom Ellis wrote:

On Sun, Apr 03, 2022 at 09:38:20PM +0200, Dominik Schrempf wrote:

...

I also think that Stack should be capitalized.

We are willing to follow the advice of the s/Stack team on this matter, but even its own documentation is ambiguous on the capitalization:

I'm inclined to agree about the capitalization just because "stack" (lowercase) already has a meaning and it could be confusing. -- brandon s allbery kf8nh allbery.b@gmail.com

PR suggesting capitalized Stack: https://github.com/haskell-infra/www.haskell.org/pull/192. Best, Dominik Tom Ellis writes:

On Sun, Apr 03, 2022 at 05:31:22PM -0400, Brandon Allbery wrote:

...

On Sun, Apr 3, 2022 at 5:29 PM Tom Ellis wrote:

...

On Sun, Apr 03, 2022 at 09:38:20PM +0200, Dominik Schrempf wrote:

...

I also think that Stack should be capitalized.

We are willing to follow the advice of the s/Stack team on this matter, but even its own documentation is ambiguous on the capitalization:

I’m inclined to agree about the capitalization just because “stack” (lowercase) already has a meaning and it could be confusing.

That rationale makes sense to me. Practicality dictates that this issue is more likely to be resolved if someone opens an issue about it (or better yet, submits a PR).

https://github.com/haskell-infra/www.haskell.org/issues/new

Tom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.