<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 24, 2015 at 5:10 PM, Gershom B <span dir="ltr"><<a href="mailto:gershomb@gmail.com" target="_blank">gershomb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On September 24, 2015 at 2:33:12 AM, Michael Snoyman (<a href="mailto:michael@fpcomplete.com">michael@fpcomplete.com</a>) wrote:<br>
> Firstly, thank you John for working on this.<br>
> <br>
> Secondly, I'd like to make clear what I think the goal for the downloads<br>
> page should be: new users. Experienced Haskellers are unlikely to even<br>
> visit this downloads page, and are likely well aware of the situation<br>
> around tooling to make an informed decision regardless of what this page<br>
> says. I'd like us to constrain discussion to "what's best for a new user."<br>
> I haven't heard anyone object to this idea before.<br>
> <br>
> I'll repeat what I've said in various other places: given the current state<br>
> of the Haskell Platform and the fact that it's known to cause many problems<br>
> - especially for new users - it should not be top option. I recommend<br>
> putting Stack at the top. My arguments are:<br>
<br>
</span>Given the concerns about the current platform and the global package database, I would advocate considering a Minimal-first order. The caveat here is that minimal, which includes stack for Windows and OS X, should also include stack for Linux installs — this is just a  matter of a pull request to add stack instructions to the various install pages, so can be part if this discussion.<br>
<br>
Stack covers certain but not all new-user scenarios well. The main thing is, I think when people go to a “download” page, they expect to be able to directly download a compiler or interpreter. That is to say, they want GHC, and the tools to use it, directly. Which is also how most documentation in the world describes using Haskell. If users download stack first, they must also then use it to download GHC. And at this point, if they want to run or use ghc or ghci, they must do so _via_ stack, and will probably find themselves in situations creating yaml files earlier than they may have otherwise.<br>
<br>
In my mind, this is not an optimal new-user experience, though it is a good curated experience for certain use cases to be sure.<br>
<br>
Pointing people to GHC and cabal and also stack allows them to A) avoid the global package database issue but B) nonetheless use “bare” ghc and ghci when they desire and C) then choose to use cabal or stack to manage their package installs and builds, and hence grow into any particular style they want.<br>
<br>
My point being this — I agree that until we make the platform more minimal, it is perhaps best that it not be the first option on the page. However, I do _not_ want the first option to be something that forces the choices between cabal and stack — rather I want it to be something that enables both choices.<br>
<br>
All of Michael’s points in favor of Stack do not evaporate when it _also_ ships with a ghc and a cabal binary directly. So let’s just make sure all our minimal instructions do this, and it suffices!<br>
<br>
Cheers,<br>
Gershom<br>
<br>
P.S. On another note, I want to warn against the hypothetical one size-fits-all “new user” as a good benchmark in this sense: “experienced haskellers” are more uniformly alike than new users are. This is because experienced haskellers all share a certain common knowledge base. New users are all completely different. Some want to build deployable projects early on, others want to explore books, others want to build a few modules for their own use for recreational math, still others are following along with a particular course. Some have only windows experience and expect to click all the things, some only ruby experience and expect a giant base library, some are old *nix hands and don’t know why everything can’t just use autoconf, etc. Experienced haskell users can adapt themselves to a variety of workflows more easily, because they know what’s going on. Default workflow certainly affects new-users much more. But, because they are all different, the same default workflow won’t be the same pleasant experience for every new user.<br>
</blockquote></div><br></div><div class="gmail_extra">If we're talking about minimal installer + link to Stack documentation vs Stack itself, the difference is getting much slimmer. However, I would like to work out a few different common use cases for which I think there's a big difference:<br><br></div><div class="gmail_extra">* A user wants to write Haskell code, using only libraries shipped with GHC. For this case, the minimal installer is probably preferable, since the user can use either `ghc` directly or `stack`.<br></div><div class="gmail_extra">* A user wants to use lots of upstream libraries. In this case, the ability to run GHC from the command line directly may be a *disadvantage*. The most logical way to get those packages into the global or user package database (instead of a sandbox) is via `cabal install ...`, but we've all been through the pain of non-sandboxed cabal usage already, and don't want to recommend it.<br></div><div class="gmail_extra">* For downloading an installer that will be reused on multiple machines, minimal installers are definitely preferable (in fact, I made a point of drawing that out in my original PR).<br><br></div><div class="gmail_extra">IME with new users - which granted may have selection bias - the vast majority of people fall into category two, which is why I would still recommend Stack over minimal installers as the primary link. Something which may make more sense is to present Stack as a build tool, and then recommend two ways of getting it ("raw" or "with GHC").<br><br></div><div class="gmail_extra">It should also be noted that on Windows, that are some definite advantages to Stack over MinGHC around PATH management. Currently, to account for cabal-install, MinGHC puts all tools (including MSYS2) on the PATH, whereas Stack is able to work with just itself (since it modifies the PATH before calling Cabal-the-library).<br><br></div><div class="gmail_extra">Finally, I think the upgrade story for Stack is still a solid point in its favor in all of this.<br><br></div><div class="gmail_extra">Michael<br></div></div>