[Haskell-community] haskell.org download page

[Michael Snoyman]

Thank you for the thoughtful reply Nick.

On Thu, Sep 1, 2016 at 9:17 AM, Nicolas Wu <nicolas.wu at gmail.com> wrote:

> Hello Michael,
>
> On Thu, Sep 1, 2016 at 6:37 AM Michael Snoyman <michael at fpcomplete.com>
> wrote:
>
>> On Thu, Sep 1, 2016 at 12:41 AM, Nicolas Wu <nicolas.wu at gmail.com> wrote:
>>>
>>> I think a beginner doesn't usually make the choice of how to use
>>> GHC/stack/cabal by themselves; they are usually being instructed by someone
>>> (or a resource) that has decided that for them.
>>>
>>
>> I disagree, and that's where a lot of this debate comes from. Let me give
>> an example from another language. Suppose you know nothing about Rust, and
>> decide you want to learn Rust because you see a blog post talking about how
>> awesome Rust is (with no specific link to "get started here," which is
>> frequently the case). You'd probably go to Google and search "Rust
>> programming language," and show up on their homepage. They have two links
>> that stand out (to me at least):
>>
>> * A big "Download" button, which provides the compiler and build tool
>> (AFAICT it does not include non-standard libraries, so pretty equivalent to
>> HP Minimal)
>> *  A "Show me" link taking you straight to a tutorial, which covers both
>> command line invocation for the compiler _and_ the build tool
>>
>> This is the documentation issue I've raised a few times: a new user
>> coming from nowhere has no way of really getting started with Haskell after
>> downloading the platform. _Some_ kind of "go here next" is necessary if we
>> want to improve the new Haskeller bounce rate (which is all I'm concerned
>> with). By that metric, a solid "how to get far in Haskell with just
>> standard libraries and the ghc executable" would work, as would a tutorial
>> on "writing applications with HP and cabal-install."
>>
>
> If I've understood you correctly, I agree on this point: we should be
> providing a single download that contains something equivalent to the HP
> Minimal. That's what I'm suggesting. I also agree that pointing to a
> tutorial that outlines how to actually use the tools is useful.
>
>
I'd be far less concerned about HP Minimal if:

1. Having a tutorial go along with it was a prereq to bumping its position.
2. The issues that Stack users have been running into are addressed first.
There _are_ bug reports coming into the Stack issue tracker about this
(like there were with GHC for Mac OS X previously), and this is an undue
burden to place on the Stack maintainers.

My reason for an immediate -1 on the proposal is that, as it stands today,
I would describe the HP Minimal content on haskell.org/downloads as a
"brick wall" for anyone not following a preexisting guide. (And for someone
already following a different guide: who cares what haskell.org says?
They'll just follow the guide.)


> However, based on my experience working with new users (both through
>> Yesod, general Haskell work, and at my day job), I believe that Stack
>> covers the job best, since:
>>
>> 1. The Haskell standard libraries are very bare bones, so most users will
>> quickly want an additional library, even just for experimenting
>> 2. I still see users complaining about dependency solving problems with
>> cabal-install, and new users will likely be turned off very quickly by that
>> 3. Stack+curated package sets has produced much lower friction in these
>> regards
>> 4. Stack already has a quick start guide (https://docs.haskellstack.
>> org/en/stable/README/#quick-start-guide), in-depth guide (
>> https://docs.haskellstack.org/en/stable/GUIDE/), and has usage covered
>> by books and tutorials. I don't believe a holistic workflow is included in
>> the HP or the Cabal websites for cabal-install workflow (though if I'm
>> mistaken, please point it out, that would be an interesting comparison).
>>
>
> This is where I think you and I have different use cases, and where I'm
> advocating diversity that will allow us both to teach as we like.
>
> In my experience as a university lecturer that teaches students learning
> Haskell in the first term of their first year, I have a different approach
> that has also seen success. My initial tutorials require students to invoke
> ghc and ghci to familiarise themselves with the concepts of compilers and
> interpreters. They do so on small self-contained exercises. I'm at the
> same time trying to get them used to the command line, since for many this
> will be their first experience of any development at all. They need a
> simple workflow at this point since they are already dealing with so many
> different issues. Later exercises that involve a very small project use
> cabal, but for the most part this is redundant: our university machines are
> pre-configured with all the packages I know they'll need for the tasks they
> need. I try to avoid having them deal with dependency issues at all, since
> that's an area that's tangential to learning about functional programming
> and they have so much to learn and understand at this point.
>
> Let me stress that I'm not trying to change the way you teach the
> newcomers you encounter, I'm just saying that I approach this differently
> (I suspect that it's because the beginners you're describing are newcomers
> to Haskell who already have some programming experience). When my students
> hit the downloads page to install Haskell on their own machines, I want
> them to find at least a minimal toolchain that contains a compiler and an
> interpreter.
>
>
I don't think this tension between goals actually exists. Have you ever
worked with students using Stack? The differences are minor:

* Both HP Minimal and Stack have clear installation instructions. We can
argue about which one is easier, there are issues of root user access that
need to be discussed.
* If you want a repl, you just run `stack ghci` (or, if you want more
control, `stack exec ghci`). I honestly doubt that _this_ is the pain point
that prevents a user from succeeding with the repl.

If you have contradicting experiences, I'd be happy to hear them. But in my
work with people - granted mostly people who are already command line
comfortable - this isn't a big deal. In fact, it's more of a problem for
_existing_ Haskellers who are used to running `ghci` directly.

Beyond that are plenty of arguments around more easily accessing other
packages, e.g. `stack ghci --package turtle` is very straightforward. How
would you recommend achieving the same thing in a cabal-install world?

1. You could install without a sandbox, but that's not recommended
2. You could teach the user to `cabal sandbox init; cabal install turtle;
cabal repl`. But that's clearly more complex, has complications of
dependency solving, and defeats the whole idea of having tools readily
available
3. You could go the new-build route. But my understanding (I could be
wrong) is that the story around package selection for ghci/runghc when
using the nix-style databases is not fully worked out yet.

I'd like to see these very real and common use cases discussed and worked
out before we decide that one way is easier or harder for a new user. Sure,
if we know that every single user will just be compiling and running Hello
World with only the standard library and will only need the version of GHC
provided on the downloads page, HP Minimal wins hands down. I think that's
a very restricted niche.


> PS: The hypothetical example of "reads a great Rust blog post and gets
>> interested" is _exactly_ what I'm hoping to cause to happen in the Haskell
>> community. I want to encourage lots of people to write great content on why
>> Haskell is an amazing language that will solve so many real world problems.
>> My big concern with the direction of haskell.org is that these new users
>> will end up hitting a brick wall very quickly with the content on the site
>> right now.
>>
>
> I want to build up a good community too, and I am grateful the efforts
> that have been put into technologies like stack and cabal. I want to
> explicitly acknowledge and appreciate all the hard work that you and other
> people have been putting into improving our infrastructure: what we have is
> a very valuable resource. I also think the site needs improving, so let's
> work to fix that.
>
> I'm obviously aware that you have been unhappy with the decisions the
> committee has made on this issue, and I'm sorry you've been upset. I can
> only assure you that you have been listened to in the past and that we will
> continue to listen. I think our goal is to foster a community that embraces
> our common interests and accepts diversity.
>
>
>
Thank you, I'm really glad to be having this technical level of
conversation. If we actually talk out the points and make clear what
everyone's goals are, I don't think it's unreasonable at all to come up
with a solution that everyone is happy with. Having more involvement from
the rest of the committee on this discussion is great.

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