"Is cabal-install stable enough yet that GHC should be inflicting it on newbies?"

[Volsand]

Yes, but that’s yet another thing imposed on newbies, which goes against the general idea of this thread of simplifying things.

Just to make it clear @Bodigrim , I agree with the sentiment that we should not go back to sandboxes, but I do think that we should change cabal (lib, tool and format) to decouple building from publishing, make it easier to start a new project and make it easier to do as much as possible without having to manually edit the cabal file (without also installing other tools).

[mpilgrem]

I second @andreabedini’s request for feedback from students and educators.

On the topic of newcomers to Haskell being diverse, the Stack project finds it useful to have an audience in mind for its documentation, which is currently:

A person who is about to begin to study computing as an undergraduate but who has not previously coded using Haskell. That person may be familiar with one popular operating system but may not be familiar with others.

Prompted by this discussion, I am part way through a re-review of the form and content of Stack’s online documentation at The Haskell Tool Stack. Does it meet that hypothetical person’s needs? All feedback, gratefully received - here, on Matrix, or at Stack’s GitHub repository.

[garrett]

I can provide one data point here, based on having taught Haskell-based courses since 2017. My teaching experience is at non-selective US state institutions, so my students have been diverse in terms of their background, technical expertise, and motivation for pursuing a CS degree.

I’ve always provided students with scaffolding for their assignments, nowadays using GitHub. That scaffolding includes the relevant .cabal file. We tell students to use cabal repl to explore their code. None of this has ever caused problems.

In final projects, I have given students the option of using additional libraries, and pointed them to the Cabal documentation. Several (motivated) students have followed this approach, and did not report problems using Cabal.

In olden times, I had to tell students how to install Haskell on their machines. My instructions seem to have switched from the Haskell platform to GHCup in 2022. More recently, I have encouraged students to use Docker, via VS Code, and now to use Codespaces. (Gitpod would work as well, but would have required more manual plumbing and cooperation from our IT folks).

The primary issues we had to debug were library conflicts (every so often, someone managed to get GHC and Python to conflict on Windows IIRC) , and a brief bit of nonsense with the first Apple Silicon devices. We did not run into issues with students being unable or unwilling to follow either the Haskell platform or GHCup installation instructions on any operating system.

To summarize: in my teaching, the mechanics of setting up GHC and interacting with Cabal fall primarily on the instructor and course staff. It is easy enough to set up student assignments in such a way that only students independently interested in learning about Haskell and its ecosystem have any need to interact with these tools. Finally, while I may be ahead of the curve in switching to hosted development environments, I suspect this will very shortly be the norm in many educational institutions—the reduction in overhead and increases in accessibility are just too much to be ignored.

[sclv]

@garrett

Finally, while I may be ahead of the curve in switching to hosted development environments, I suspect this will very shortly be the norm in many educational institutions—the reduction in overhead and increases in accessibility are just too much to be ignored.

This is a return of the repressed of course. Back when, students were expected to development at the lab, not on their personal machines, and lab machines were exactly these sorts of hosted development environments – another advantage being that they act as equalizers, ensuring students all have the same access to the same resources to do their work.

[garrett]

There are dueling accessibility issues here: hosted environments give everyone access to the same setup, but at the cost of requiring access to the hosting service.

The nice thing about using Codespaces or Gitpod is that your hosted environment is Docker-based. So students are free to: rely on the hosted environment, run virtual machines locally (VSCode has very nice support for this actually), or recreate the required environment on their own machines.

[AntC2]

@garrett

To summarize: in my teaching, the mechanics of setting up GHC and interacting with Cabal fall primarily on the instructor and course staff. It is easy enough …

Thank you Garrett, that is the sort of experience I was hoping to hear from.

@AntC2

So when I can make some time, I’ll have a crack at setting up a newbie-style sandbox avoiding all of the above.

Ok done. I merely downloaded the .tar from Hackage; unpacked the .hs's into a dedicated folder/subfolders; compiled. It worked. No hell. I’m not seeing how all those cabal-install options would have helped.

@garrett

I’ve always provided students with scaffolding for their assignments, …

Wise words. I’m kinda concluding it’s the “scaffolding” that’s the important part; the specific technology supporting it less so. Because …

On Hackage there seems to be a large amount of … emm … cruft: packages that were more “Hello World” experiments than anything widely useful; not maintained; don’t/haven’t recently/haven’t ever compiled. That’s where teaching-staff guidance would have helped.

So I’ve persuaded myself (personal opinion only) to eschew Cabal and all its pomps.

[hasufell]

@AntC2

On Hackage there seems to be a large amount of … emm … cruft: packages that were more “Hello World” experiments than anything widely useful; not maintained;

Yes, hackage is not a curated set of packages.

Mildly related: Maintainership standards · Issue #7 · haskellfoundation/stability · GitHub

[AntC2]

@atravers

How about…“someone not expecting to deal with this garbage in 2024” :

I don’t pretend to know if this answer (arrived today) is correct, or is over-complicating the explanation/too much info; I would put myself in the category “not expecting to deal with this” complexity … really, ever [**]. This paragraph caught my eye:

This is not asking about the HLS you think it’s asking about. There is an hls package on Hackage, but it is not the Haskell language server. That package is named haskell-language-server .

(There is indeed a package named haskell-language-server. There are also plenty of packages named hls-blah-blah – as far as I can tell, they all relate to haskell-language-server. I don’t see a package named bare hls. Ah, Hoogle tells me " [hls]: Haskell Lindenmayer Systems", not on Stackage, Deprecated.)

[**] When I was a professional programmer, I just cut code, unit tested, checked it in. There was a dedicated artefacts/version/distribution control team. Quite possibly I was present at their explanations parallel to that SO answer. If, so I glazed over.

[atravers]

“Is cabal-install stable enough yet that GHC should be inflicting it on newbies?”

No:

Hidden package text and module not loading

As I’m still just beginner in Haskell, this was the first time I tried building a package. So I believe I have surely made one or more errors which may have caused some issues. For example, in the very beginning of the project, I made this: cabal install Colourista I read later I should have request: ```cabal -lib install It didn’t allow reinstall it as it was there internal and only building was left as option. As nothing was succeeded in cabal I wanted to uninstall my project but there is…

(…cabal -lib install: another one for the collection).