[Haskell-community] Request for comment: New haskell.org download page

Michael Snoyman michael at fpcomplete.com
Thu Sep 24 14:49:28 UTC 2015


On Thu, Sep 24, 2015 at 5:10 PM, Gershom B <gershomb at gmail.com> wrote:

> On September 24, 2015 at 2:33:12 AM, Michael Snoyman (
> michael at fpcomplete.com) wrote:
> > Firstly, thank you John for working on this.
> >
> > Secondly, I'd like to make clear what I think the goal for the downloads
> > page should be: new users. Experienced Haskellers are unlikely to even
> > visit this downloads page, and are likely well aware of the situation
> > around tooling to make an informed decision regardless of what this page
> > says. I'd like us to constrain discussion to "what's best for a new
> user."
> > I haven't heard anyone object to this idea before.
> >
> > I'll repeat what I've said in various other places: given the current
> state
> > of the Haskell Platform and the fact that it's known to cause many
> problems
> > - especially for new users - it should not be top option. I recommend
> > putting Stack at the top. My arguments are:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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!
>
> Cheers,
> Gershom
>
> 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.
>

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:

* 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`.
* 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.
* 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).

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").

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).

Finally, I think the upgrade story for Stack is still a solid point in its
favor in all of this.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-community/attachments/20150924/36ec0874/attachment.html>


More information about the Haskell-community mailing list