Download page and Haskell Platform

[basetunnel]

(Note: this is just a suggestion, I hope to contribute something constructive in this recent heated discussion)

As @gbaz mentioned here:

Are there proposals for how to update the page to make this more clear? Those would be welcome, but ideally tracked under another ticket. This discussion hopefully can stick to the name given to the minimal platform with the additional understanding that there will also be other differentiating text elsewhere.

Here's a quick mock-up:

Other distributions would include Stack and HP full with a more technical motivation (e.g. Haskell platform about the extra libs, why that may be useful for limited network access etc.)

After reading through the recent discussions, it seems that this would address most problems:

• It is completely straightforward what to choose for beginners new to the language, instead of being presented with different options and lengthy descriptions.
• Both cabal and stack workflows are available
• A getting started guide/example is the logical next step for new people (this should probably use stack, as it seems to be quite stable and well-received by new users)
• Other advanced/alternative Haskell distributions are also available (stack/full platform)

I've only seen two convincing technical arguments in the stack vs HP discussion.

• Slow release cycles might result in an outdated stack (and other tools). However, stack has an automated upgrade function.
• Stack in HP does not find installed msys when using system ghc haskell/haskell-platform#251

[bitemyapp]

I think this is a less confusing direction for the downloads page, although I'd note that the Haskell Platform website haskell.org links to is a bit slow. The platform website is also redundant given this kind of presentation, but I'd be in favor of eliding that anyway and just offering the download links for platform directly from haskell.org anyway.

I'd be a lot more comfortable with this presentation of the downloads page if Stack was elided from the HP installers, minimal and full both.

It would probably help if the pages better educated users on what they were actually choosing between, which exactly zero proposals for modifications to Haskell.org have attempted.

It's roughly about:

1. cabal-install vs. Stack for installing, managing packages
2. System installed GHC vs. Stack managed GHC

You can mix and match these choices at will but each have different failure modes that vary substantially depending on user workflow. Nothing is perfect.

I happen to believe based on substantial experience that Stack managed packages + Stack managed GHC is the most reliable, least fraught setup for typical users. I also recognize that it's not ideal for Nix users or people with custom build setups (elaborate Makefiles, Shake, etc.).

[gbaz]

@jaccokrijnen that's really nice looking! did you mock it up in html or just photoshop? If the former, a pointer to the files, etc. would be helpful (assuming this gets traction).

[jwiegley]

I really like the presentation @jaccokrijnen.

[basetunnel]

@gbaz it's some quick html, I could spend some time to make it functional but I think for the purposes of discussion the screenshot might be enough?

[basetunnel]

@bitemyapp I don't really follow your reasoning on why stack should be omitted from the HP (but I'm not a stack user, maybe I'm missing something).

cabal-install vs. Stack for installing, managing packages

As far as I know these tools can easily coexist on a system

System installed GHC vs. Stack managed GHC

So can these tools (with the exception of haskell/haskell-platform#251)

You can mix and match these choices at will but each have different failure modes that vary substantially depending on user workflow. Nothing is perfect.

Can you give an example?

I think the actual point of discussion should be the content of the getting-started guide, somewhat based on the haskell-lang.org:

---

Getting started

1. Create a text file with the following content and save it as HelloWorld.hs

   main :: IO ()
   main = putStrLn "Hello world"

2. Open up a terminal and run runghc HelloWorld.hs

3. Learn more about...

   • The Haskell language with one of the language tutorials.
   • Setting up a project with stack or cabal
   • Text editor and IDE support
   • The Haskell community

---

Perhaps more stuff at step 3, but this is what comes to mind for new users.

This way there is also no need to directly choose between stack or cabal. From a quick look at the first five language tutorials on the wiki I find they all instruct to run ghci.

It would probably help if the pages better educated users on what they were actually choosing between, which exactly zero proposals for modifications to Haskell.org have attempted.

The referred documentation for setting up a project in step 3 (a wiki page?) could explain this.

Perhaps "Downloads" (in the menu) should be renamed "Getting Haskell".

This option is more descriptive than "Downloads" ("Downloads of what?"), and more including than the often proposed alternative, "Getting started" ("Started? I've programmed in Haskell for years!").

[Blaisorblade]

• "Getting started" and "Alternative Download" have indeed different goals. Some people want one path for "Getting started", others want all the options on "Downloads".

A common setup is "Getting started" pointing to "Alternative downloads", but we can hash details. Important: new users do exist and some do need to be handheld to One Way.

@jaccokrijnen

As far as I know these tools can easily coexist on a system

Yes, but:

• Users "getting started" want to learn one tool, not both. Their UIs are significantly different—while I'm a happy stack user, learning stack after cabal experience wasn't immediate, and viceversa.
• Installing a package with one tool doesn't install it with the other (in fact, the question arguably doesn't even make sense because stack doesn't have a single per-user DB, and with cabal without new-build you should not use the per-user DB without great care).
• Try installing a package with cabal (no sandbox) with a stack-managed GHC. Marlow wrote "it doesn't work" on haskell-community, and I mostly agree. There might be tricky incantations that manage that, but there are more that fail.
• With Stack-managed GHC (and @bitemyapp is adamant about that, as he mentioned), ghci doesn't work (on purpose). stack ghci is not equivalent (regardless of the disinformation about it), but might do.

[Blaisorblade]

But I actually came here (as suggested by @gbaz on Reddit) to report a current issue we should beware: for cabal we should ensure we mention a safe path, that is using sandboxes.

Regarding user experience, the current https://www.haskell.org/downloads page still suggests non-sandboxed installations first:

You can install a package using cabal by running:

$ cabal update
$ cabal install the-package

I've seen the warning afterwards about sandboxes, but that's too late. Usability-wise that's still a trap for new users.

[basetunnel]

@Blaisorblade

Important: new users do exist and some do need to be handheld to One Way.

Exactly.

Users "getting started" want to learn one tool, not both. Their UIs are significantly different—while I'm a happy stack user, learning stack after cabal experience wasn't immediate, and viceversa.

Absolutely, that's why I'm proposing that the getting started "guide" just uses runghc and no project tool (stack/cabal). Most newcomers start with the basic language tutorial anyways. And I've done a quick check: most tutorials like Learn you a Haskell start their chapters with simple ghci, not package management etc.

Installing a package with one tool doesn't install it with the other (in fact, the question arguably doesn't even make sense because stack doesn't have a single per-user DB, and with cabal without new-build you should not use the per-user DB without great care).

Right, but this seems a matter of documentation, the link I imagine in step 3 on project tools should clearly explain that there are two seperate tools and probably steer newcomers to stack (it seems to have the best "new user" experience).

Try installing a package with cabal (no sandbox) with a stack-managed GHC. Marlow wrote "it doesn't work" on haskell-community, and I mostly agree. There might be tricky incantations that manage that, but there are more that fail.

But who would do that? Again, it should be obvious from the documentation that these are two completely different tools.

With Stack-managed GHC (and @bitemyapp is adamant about that, as he mentioned), ghci doesn't work (on purpose). stack ghci is not equivalent (regardless of the disinformation about it), but might do.

That's concerning, can you give me more details? I have both stack and cabal on this system and never have problems running ghci. @bitemyapp?

[Blaisorblade]

Let's clarify what most mean by "stack-managed GHC".

Apparently you installed some GHC version system-wide—then stack will use it by default (up to 1.2.0). In that scenario, stack and cabal coexist as you're discussing, and ghci does as well. For me and you that works perfectly.

There, Stack will also install and manage other GHC versions by itself as needed. That's not what we mean by "stack-managed GHC" though. We mean the scenario where no GHC can be found on the PATH, but there are only versions stack installs and knows how to find—while cabal doesn't.

The advantage is: the only GHC you get is the correct one for your project. Hence @bitemyapp is adamant this is more robust and pushed stack to switch to this by default in next cycle.

The disadvantage is: you lack direct access to GHCi and can't use cabal.

Once this is clear, all the claims about stack-managed GHC that you disagreed with should make more sense.

---

Regarding GHCi, a common replacement that works with stack-managed GHC is stack ghci.

Without a project it uses the "global" project, the one where stack install will put libraries go by default till you configure a project.

But in general, stack ghci loads the REPL for your project, similar to cabal repl, which is often a good thing, but doesn't have access to other libraries. Startup is just very slow on big projects (for either tool). That's a slightly more advanced scenario, but this is why I distinguish stack ghci/cabal repl from stack exec ghci (which simply runs the GHCi of the stack-managed GHC).

[basetunnel]

. In that scenario, stack and cabal coexist as you're discussing, and ghci does as well. For me and you that works perfectly.

But that is the scenario after instelling the platform, is it not?

There, stack installs ...

What do you mean with "there"? In the global PATH? I suppose not, since you mention cabal won't find it.

So if I understand correctly, the point you're making is that the ghci or -- interactive command (when run on a stack-managed ghc) does not work.

Running ghci with a globally installed ghc does. Which is the scenario with the platform. You get ghc+cabal and stack which may use the former ghc.

I think I am missing your point.

Once this is clear, all the claims about stack-managed GHC that you disagreed with should make more sense.

I wasn't disagreeing per se , just asking how those scenarios are likely. And that's basically still my question: A user asking cabal to use a stack-managed ghc seems very unlikely. And I understand that there's no problem with the globally installed ghci that comes with the platform.

[Blaisorblade]

The topic is not just "what happens if you install the HP". You also propose having a stack-only install on the webpage, so what happens there is relevant—and by now I hope it's clear cabal won't work well there.
Stack-only also matters because it gives (to this day) the most coherent stack experience—arguably even if you ignore current issues with HP-installed stack.* Hence, I agree with @bitemyapp's comment about the available choices.

*I'm not qualified to fully argue that point and I'm not sure this is the place; taking this point at face value is probably best. But since you'd like some evidence (which is reasonable), here's my 2 cents:

• "this installer works most of the time" is not enough—we're talking about higher reliability (compare with people needing 99.999% reliability though probably the numbers are different).
• @bitemyapp filed issues through the years due to stack used a system-installed GHC, whatever the source. Some affected newbies, some experienced users (even himself). Enough issues from many years to get lost can be found in issues starting from Stop using system-ghc silently…or at all. commercialhaskell/stack#2221 and Change default to not use system-ghc unless otherwise specified. commercialhaskell/stack#1129.
• Furthermore, installing stack through the HP has never worked perfectly. While installers are small, they're tricky to get right, and they don't compose. The HP currently reuses stack installer on Windows, but their approaches are different enough that this is still not robust.
  Both Stack in HP does not find installed msys when using system ghc haskell/haskell-platform#251 and HP 8.0.1 minimal Windows install installs HP system-wide and stack per-user commercialhaskell/stack#2548 are caused by different approaches to installation.

[basetunnel]

The topic is not just "what happens if you install the HP".

Well, this discussion was actually about @bitemyapp not being comfortable with including stack in the HP. I still haven't heard any convincing reason why this shouldn't be the case (except for the obvious open issue on system ghc). @bitemyapp 's argument on "wasted disk space" doesn't seem serious.

But thanks for clarifying the situation on stack-managed ghc and its disabled ghci!

You also propose having a stack-only install on the webpage, so what happens there is relevant—and by now I hope it's clear cabal won't work well there.

Sure, but then you're talking about stack+cabal and no global ghc? (I'd still like this confirmed: are stack-managed GHC's in PATH yes or no? If so, your concerns would make more sense to me)

Stack-only also matters because it gives (to this day) the most coherent stack experience—arguably even if you ignore current issues with HP-installed stack.*

With stack-only, do you mean a stack installation and no cabal/global ghc installation? I would like to think of "stack-only" describing a workflow just like a cabal-only workflow. These workflows should be part of documentation in the getting started guide and I think it should currently be biased to stack for new users. The platform installer should only be concerned with putting executables on a user's system.

I think it's not necessary to go into more detail about the stack & global ghc issues, haskell/haskell-platform#251 obviously has to be solved before a next HP, whether it is on HP's side by instructing stack to no use system GHC or stack defaulting to no-system-ghc.

[bitemyapp]

@jaccokrijnen >@bitemyapp 's argument on "wasted disk space" doesn't seem serious.

That's not the main reason at all. It's an old version of Stack and it currently has issues in how it is packaged with HP.

One is that it shouldn't really default to using the system-ghc furnished by HP at all.

I didn't want to get into it because I know nothing I say will make a difference here. However, in my absence if you could refrain from strawmanning my reasons, that would spare me having to reply again.

Thanks!