Request for comment: New haskell.org download page
As mentioned earlier, I've been working on a draft version of the new Haskell download page in consultation with Simon PJ, Michael Snoyman, and Gershom Bazerman. The goal has been twofold: a) add stack as an explicit option, and b) add text to each option indicating clearly what it provides and where to get further help, so users can understand the options and make an informed choice. We've sought to keep the text factual, rather than imply that one option is "best" for any particular class of user, since opinions vary so widely on this point. At the following link, you'll find a draft version of the new page for comment: https://gist.github.com/jwiegley/153d968ddfc9046ee4c9 Hopefully it can go live on haskell.org next week, so please contribute your edits here, or by pull request. The goal is to explain each option so that people can make an informed decision. However, the order of presentation does imply that whatever comes first is "preferred" even if that is not the intent. The order currently given is HP, Stack, Minimal. Chris has already made a few points about changing this order, so let's continue that discussion and see where it leads us. Bear in mind that this is (hopefully) only an interim state. The plan is to add Stack to the Platform, and render the Platform minimal, which will consolidate this page down to a single, recommended download path. At the bottom of the gist are incomplete sections on third party libraries and alternate installation approaches. These have yet to be written. The hope is to resolve the top content first and sort the rest out after; however, ideas for that content is most welcome too. Thank you, John Wiegley
On Thu, Sep 24, 2015 at 8:20 AM, John Wiegley
As mentioned earlier, I've been working on a draft version of the new Haskell download page in consultation with Simon PJ, Michael Snoyman, and Gershom Bazerman. The goal has been twofold:
a) add stack as an explicit option, and
b) add text to each option indicating clearly what it provides and where to get further help, so users can understand the options and make an informed choice.
We've sought to keep the text factual, rather than imply that one option is "best" for any particular class of user, since opinions vary so widely on this point.
At the following link, you'll find a draft version of the new page for comment:
https://gist.github.com/jwiegley/153d968ddfc9046ee4c9
Hopefully it can go live on haskell.org next week, so please contribute your edits here, or by pull request. The goal is to explain each option so that people can make an informed decision.
However, the order of presentation does imply that whatever comes first is "preferred" even if that is not the intent. The order currently given is HP, Stack, Minimal. Chris has already made a few points about changing this order, so let's continue that discussion and see where it leads us.
Bear in mind that this is (hopefully) only an interim state. The plan is to add Stack to the Platform, and render the Platform minimal, which will consolidate this page down to a single, recommended download path.
At the bottom of the gist are incomplete sections on third party libraries and alternate installation approaches. These have yet to be written. The hope is to resolve the top content first and sort the rest out after; however, ideas for that content is most welcome too.
Thank you, John Wiegley _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
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: 1. It's being designed from the ground up to give a good new user experience in terms of UX 2. Curated package sets by default is (IMO) the best option for new users. We don't want a new user to download a massive installer, run `cabal install foo`, only to find out that there's a bug in the most recent version of foo preventing it from installing. (That's not even getting into issues of dependency solving.) 3. There's a complete guide to using Stack available which is targeted at new users. A common complaint we see about people starting with cabal is that they trash their package databases by not using sandboxes, and then being told they did it the wrong way. Both the change in default behavior and the guide will help that problem. 4. New users will often not know in advance which version of GHC they really need. Stack can handle that for them by downloading the appropriate GHC for their project. 5. There's a clear upgrade story for Stack, including: upgrading Stack itself, upgrading to new snapshots, and upgrading GHC. 6. It's already built for a large number of OSes 7. On Windows, it's the only solution right now that provides a full MSYS2 + Pacman setup, allowing both building the network package without modifying the PATH, and installing new system libraries via pacman[1] I'll stop there, it's already a pretty long list. I'd like to make a request for the rest of this discussion: instead of arguing about what the current state of the downloads page is, or what may be happening in the future, can we focus on what will be best for new users today? If someone wants to make an argument for putting the HP at the top, for example, it should be based on "the HP is the best choice for new users today because X." Michael [1] https://twitter.com/snoyberg/status/638359459304239104
This is intended to be an interim page.
Perhaps it then makes sense to explicitly list the environments where the
current HP is known to install cleanly, or alternatively the ones where it
is known not to. This can help a new user to decide which option to use.
Alan
On Thu, Sep 24, 2015 at 8:32 AM, Michael Snoyman
On Thu, Sep 24, 2015 at 8:20 AM, John Wiegley
wrote: As mentioned earlier, I've been working on a draft version of the new Haskell download page in consultation with Simon PJ, Michael Snoyman, and Gershom Bazerman. The goal has been twofold:
a) add stack as an explicit option, and
b) add text to each option indicating clearly what it provides and where to get further help, so users can understand the options and make an informed choice.
We've sought to keep the text factual, rather than imply that one option is "best" for any particular class of user, since opinions vary so widely on this point.
At the following link, you'll find a draft version of the new page for comment:
https://gist.github.com/jwiegley/153d968ddfc9046ee4c9
Hopefully it can go live on haskell.org next week, so please contribute your edits here, or by pull request. The goal is to explain each option so that people can make an informed decision.
However, the order of presentation does imply that whatever comes first is "preferred" even if that is not the intent. The order currently given is HP, Stack, Minimal. Chris has already made a few points about changing this order, so let's continue that discussion and see where it leads us.
Bear in mind that this is (hopefully) only an interim state. The plan is to add Stack to the Platform, and render the Platform minimal, which will consolidate this page down to a single, recommended download path.
At the bottom of the gist are incomplete sections on third party libraries and alternate installation approaches. These have yet to be written. The hope is to resolve the top content first and sort the rest out after; however, ideas for that content is most welcome too.
Thank you, John Wiegley _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
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:
1. It's being designed from the ground up to give a good new user experience in terms of UX 2. Curated package sets by default is (IMO) the best option for new users. We don't want a new user to download a massive installer, run `cabal install foo`, only to find out that there's a bug in the most recent version of foo preventing it from installing. (That's not even getting into issues of dependency solving.) 3. There's a complete guide to using Stack available which is targeted at new users. A common complaint we see about people starting with cabal is that they trash their package databases by not using sandboxes, and then being told they did it the wrong way. Both the change in default behavior and the guide will help that problem. 4. New users will often not know in advance which version of GHC they really need. Stack can handle that for them by downloading the appropriate GHC for their project. 5. There's a clear upgrade story for Stack, including: upgrading Stack itself, upgrading to new snapshots, and upgrading GHC. 6. It's already built for a large number of OSes 7. On Windows, it's the only solution right now that provides a full MSYS2 + Pacman setup, allowing both building the network package without modifying the PATH, and installing new system libraries via pacman[1]
I'll stop there, it's already a pretty long list. I'd like to make a request for the rest of this discussion: instead of arguing about what the current state of the downloads page is, or what may be happening in the future, can we focus on what will be best for new users today? If someone wants to make an argument for putting the HP at the top, for example, it should be based on "the HP is the best choice for new users today because X."
Michael
[1] https://twitter.com/snoyberg/status/638359459304239104
_______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
It's not really a question of specific environments (though the situation
is worse on Windows). The main problem is that the presence of extra
packages in the global package database leads to lots of problems (usually
in the form of user confusion, since cabal-install warns them about
breaking things). In addition, the platform is currently only shipping with
cabal-install, and not with Stack, making the points I make in favor of
Stack's defaults (isolation-by-default, curation) relevant.
We can discuss the future when the HP is no longer shipping with global
packages and includes Stack in terms of my points above, but I think we
should save that for a separate thread once those changes land.
On Thu, Sep 24, 2015 at 2:08 PM, Alan & Kim Zimmerman
This is intended to be an interim page.
Perhaps it then makes sense to explicitly list the environments where the current HP is known to install cleanly, or alternatively the ones where it is known not to. This can help a new user to decide which option to use.
Alan
On Thu, Sep 24, 2015 at 8:32 AM, Michael Snoyman
wrote: On Thu, Sep 24, 2015 at 8:20 AM, John Wiegley
wrote: As mentioned earlier, I've been working on a draft version of the new Haskell download page in consultation with Simon PJ, Michael Snoyman, and Gershom Bazerman. The goal has been twofold:
a) add stack as an explicit option, and
b) add text to each option indicating clearly what it provides and where to get further help, so users can understand the options and make an informed choice.
We've sought to keep the text factual, rather than imply that one option is "best" for any particular class of user, since opinions vary so widely on this point.
At the following link, you'll find a draft version of the new page for comment:
https://gist.github.com/jwiegley/153d968ddfc9046ee4c9
Hopefully it can go live on haskell.org next week, so please contribute your edits here, or by pull request. The goal is to explain each option so that people can make an informed decision.
However, the order of presentation does imply that whatever comes first is "preferred" even if that is not the intent. The order currently given is HP, Stack, Minimal. Chris has already made a few points about changing this order, so let's continue that discussion and see where it leads us.
Bear in mind that this is (hopefully) only an interim state. The plan is to add Stack to the Platform, and render the Platform minimal, which will consolidate this page down to a single, recommended download path.
At the bottom of the gist are incomplete sections on third party libraries and alternate installation approaches. These have yet to be written. The hope is to resolve the top content first and sort the rest out after; however, ideas for that content is most welcome too.
Thank you, John Wiegley _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
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:
1. It's being designed from the ground up to give a good new user experience in terms of UX 2. Curated package sets by default is (IMO) the best option for new users. We don't want a new user to download a massive installer, run `cabal install foo`, only to find out that there's a bug in the most recent version of foo preventing it from installing. (That's not even getting into issues of dependency solving.) 3. There's a complete guide to using Stack available which is targeted at new users. A common complaint we see about people starting with cabal is that they trash their package databases by not using sandboxes, and then being told they did it the wrong way. Both the change in default behavior and the guide will help that problem. 4. New users will often not know in advance which version of GHC they really need. Stack can handle that for them by downloading the appropriate GHC for their project. 5. There's a clear upgrade story for Stack, including: upgrading Stack itself, upgrading to new snapshots, and upgrading GHC. 6. It's already built for a large number of OSes 7. On Windows, it's the only solution right now that provides a full MSYS2 + Pacman setup, allowing both building the network package without modifying the PATH, and installing new system libraries via pacman[1]
I'll stop there, it's already a pretty long list. I'd like to make a request for the rest of this discussion: instead of arguing about what the current state of the downloads page is, or what may be happening in the future, can we focus on what will be best for new users today? If someone wants to make an argument for putting the HP at the top, for example, it should be based on "the HP is the best choice for new users today because X."
Michael
[1] https://twitter.com/snoyberg/status/638359459304239104
_______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
On September 24, 2015 at 2:33:12 AM, Michael Snoyman (michael@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.
On Thu, Sep 24, 2015 at 5:10 PM, Gershom B
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
On September 24, 2015 at 2:33:12 AM, Michael Snoyman ( michael@fpcomplete.com) wrote: 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
We had our first haskell meetup here in SLC a month or so ago and had everyone use stack to get going. Seemed to go quite well. Almost no
I agree with Michael in his characterization of the usage scenarios and how
common they are. When I mentioned Stack in my previous email, it had more
to do with my own fussing about smoothing out any possible wrinkles. My
coauthor Julie and I are going to collaborate on a tutorial for Stack soon.
Here's some feedback from one of the users in #haskell-beginners on IRC:
problems and everyone from experienced to new was up and running pretty
quick.
So, my preference is Stack, followed by Minimal (those that want it, will
know they want it) - and that's it. I don't think a hybrid makes sense.
To be clear, my priority is that Platform get _off_ the downloads page for
now.
If we can get Stack as the primary recommendation, I think that would be a
benefit to the new users of Haskell. Much of the industry is moving towards
tools that manage your entire programming language environment (OPAM, rvm,
nvm, etc.) and Stack is stealing all the right ideas here, putting things
together in a way I think is close to ideal for Haskellers.
On Thu, Sep 24, 2015 at 9:49 AM, Michael Snoyman
On Thu, Sep 24, 2015 at 5:10 PM, Gershom B
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
On September 24, 2015 at 2:33:12 AM, Michael Snoyman ( michael@fpcomplete.com) wrote: 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
_______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
-- Chris Allen Currently working on http://haskellbook.com
On September 24, 2015 at 11:37:08 AM, Christopher Allen (cma@bitemyapp.com) wrote:
To be clear, my priority is that Platform get _off_ the downloads page for now.
We can discuss the order of the downloads page, but I think it will not be acceptable to remove the platform. —gershom
On Thu, Sep 24, 2015 at 6:38 PM, Gershom B
On September 24, 2015 at 11:37:08 AM, Christopher Allen (cma@bitemyapp.com) wrote:
To be clear, my priority is that Platform get _off_ the downloads page
for
now.
We can discuss the order of the downloads page, but I think it will not be acceptable to remove the platform.
I have to say Gershom, in a discussion that is otherwise full of logical justifications and well thought out reasonings, this comment comes off as out of character. Can you give a rationale of _why_ it won't be acceptable to remove the platform? Michael
On September 24, 2015 at 11:45:51 AM, Michael Snoyman (michael@fpcomplete.com) wrote:
On Thu, Sep 24, 2015 at 6:38 PM, Gershom B wrote:
On September 24, 2015 at 11:37:08 AM, Christopher Allen (cma@bitemyapp.com) wrote:
To be clear, my priority is that Platform get _off_ the downloads page
for
now.
We can discuss the order of the downloads page, but I think it will not be acceptable to remove the platform.
I have to say Gershom, in a discussion that is otherwise full of logical justifications and well thought out reasonings, this comment comes off as out of character. Can you give a rationale of _why_ it won't be acceptable to remove the platform?
I have to ask Michael, since we just had an extensive correspondence in which removing the platform was not once discussed, in order to come up with the draft proposal which John sent, and which was written with your input, do you now want to change your mind on the process which got us there? I mean, I’m happy to expand, but I honestly had thought we were on the same page there. The short story — and there are many more reasons — is that while beginners may go to the page to look for “what first,” experienced users are accustomed to go there as well to look for the latest versions of things — and many of them still want/prefer the platform. Students may also be directed by professors to download the platform, etc. So while we may want to say “whatever is first should be optimized for the new user experience” (whatever that means) we must also bear in mind that the page is used by others as well, who are not new, and they may want the platform (whatever you personally think of it), and it would be a terrible shame if it were not easy for them to find it. —Gershom
On Thu, Sep 24, 2015 at 6:49 PM, Gershom B
On Thu, Sep 24, 2015 at 6:38 PM, Gershom B wrote:
On September 24, 2015 at 11:37:08 AM, Christopher Allen ( cma@bitemyapp.com) wrote:
To be clear, my priority is that Platform get _off_ the downloads
On September 24, 2015 at 11:45:51 AM, Michael Snoyman ( michael@fpcomplete.com) wrote: page
for
now.
We can discuss the order of the downloads page, but I think it will not be acceptable to remove the platform.
I have to say Gershom, in a discussion that is otherwise full of logical justifications and well thought out reasonings, this comment comes off as out of character. Can you give a rationale of _why_ it won't be acceptable to remove the platform?
I have to ask Michael, since we just had an extensive correspondence in which removing the platform was not once discussed, in order to come up with the draft proposal which John sent, and which was written with your input, do you now want to change your mind on the process which got us there?
I mean, I’m happy to expand, but I honestly had thought we were on the same page there.
The short story — and there are many more reasons — is that while beginners may go to the page to look for “what first,” experienced users are accustomed to go there as well to look for the latest versions of things — and many of them still want/prefer the platform. Students may also be directed by professors to download the platform, etc.
So while we may want to say “whatever is first should be optimized for the new user experience” (whatever that means) we must also bear in mind that the page is used by others as well, who are not new, and they may want the platform (whatever you personally think of it), and it would be a terrible shame if it were not easy for them to find it.
—Gershom
I'm content to let the platform be at the bottom of the page. I was just a little surprised to see you completely dismiss Chris's opinion without any form of explanation at all. Chris made a lot of very valid points, and you essentially shut him down with "no." I do respectfully disagree with your arguments here: I don't know of any experienced user who wants to specifically use the platform and wouldn't be able to find it without a link on the downloads page[1]. Furthermore, the line of reasoning of "someone may want it" means that we should also include about a dozen other download options on the page... Michael [1] http://lmgtfy.com/?q=haskell+platform
On September 24, 2015 at 11:58:17 AM, Michael Snoyman (michael@fpcomplete.com) wrote:
I do respectfully disagree with your arguments here: I don't know of any experienced user who wants to specifically use the platform and wouldn't be able to find it without a link on the downloads page[1]. Furthermore, the line of reasoning of "someone may want it" means that we should also include about a dozen other download options on the page…
I have personally spoken with many many people who want to find that link on the downloads page. Certainly they _could_ google for it, but they are used to going to the homepage, and clicking download, and finding it. Certainly the haskell.org homepage should be accessible to new users, but it genuinely does service others as well, and anything we do should bear that in mind. —Gershom
On Thu, Sep 24, 2015 at 12:01:26PM -0400, Gershom B wrote:
On September 24, 2015 at 11:58:17 AM, Michael Snoyman (michael@fpcomplete.com) wrote:
I do respectfully disagree with your arguments here: I don't know of any experienced user who wants to specifically use the platform and wouldn't be able to find it without a link on the downloads page[1]. Furthermore, the line of reasoning of "someone may want it" means that we should also include about a dozen other download options on the page…
I have personally spoken with many many people who want to find that link on the downloads page. Certainly they _could_ google for it, but they are used to going to the homepage, and clicking download, and finding it.
I'll start with a caveat. Since I don't know anyone who likes or uses the HP, I think hearing their perspective would be valuable. What do they use it for? How do they avoid its problems? Do they recommend it to others, who also use it happily? Do they think it needs to change, or is it fine as-is? If there are existing discussions I missed because of coming into this late, please point me to them! I will present my opinion now, having presented that caveat. This opinion is subject to change if I hear the perspectives of HP proponents. I agree that having the HP on the downloads page is harmful, and I will even go so far as to question its very necessity. It seems to be geared towards letting people use GHC as a build tool. Although that is an old and storied paradigm, it's a broken one that serves no language especially well. Using a language should start at the build tool, not at the compiler. Whatever the HP represents should eventually be found in spirit in stack and cabal. The HP itself should not be on the Downloads page until it can fulfil its purpose without hamstringing its users. If — as I suspect — it can never manage such a feat, it should go away entirely, to be replaced by new features of stack and/or cabal.
On Sep 24, 2015, at 1:38 PM, Bryan Richter wrote:
Since I don't know anyone who likes or uses the HP, I think hearing their perspective would be valuable.
At the threat of being booed out of the community, I'll stand up and say I like the HP. Of course it should improve -- and I like the direction it's going -- but I've used it as it is and would do so again. I think the observation that the HP promotes a ghc-centric view is why I like it. When working with a new language, I really do just want to think about the compiler. Only when I get around to trying to actually produce software do I care about a build tool. Starting with stack or cabal, instead of with ghc, means a much bigger cognitive load right away. Not only to you have Haskell files, but you also have .cabal files, and perhaps stack.yaml files. You have to think about directory structure -- both `cabal` and `stack` behave differently when they're run in or under a directory with project files than elsewhere. But, when I'm starting out, and when my students are starting out, I just want to think about the language. Compilers have, at their core, a simple interface: program text in, program binary out. Simple! It may be totally insufficient for producing portable libraries and distributable software, but I'm not tackling those issues on my first day. The fact that the HP means I can install something and right away tinker in GHCi and explore some common libraries is great. I'm not trying to derail the conversation. Or even to urge strongly that HP remain on the downloads page. I've not followed the thread closely enough to be able to make such a stand. But while scrolling through, I saw Bryan's request, and I thought I'd answer it. Happy booing! :) Richard
On Thu, Sep 24, 2015 at 10:54 AM, Richard Eisenberg
On Sep 24, 2015, at 1:38 PM, Bryan Richter wrote:
Since I don't know anyone who likes or uses the HP, I think hearing their perspective would be valuable.
At the threat of being booed out of the community, I'll stand up and say I like the HP. Of course it should improve -- and I like the direction it's going -- but I've used it as it is and would do so again.
I think the observation that the HP promotes a ghc-centric view is why I like it. When working with a new language, I really do just want to think about the compiler. Only when I get around to trying to actually produce software do I care about a build tool. Starting with stack or cabal, instead of with ghc, means a much bigger cognitive load right away. Not only to you have Haskell files, but you also have .cabal files, and perhaps stack.yaml files. You have to think about directory structure -- both `cabal` and `stack` behave differently when they're run in or under a directory with project files than elsewhere.
But, when I'm starting out, and when my students are starting out, I just want to think about the language. Compilers have, at their core, a simple interface: program text in, program binary out. Simple! It may be totally insufficient for producing portable libraries and distributable software, but I'm not tackling those issues on my first day. The fact that the HP means I can install something and right away tinker in GHCi and explore some common libraries is great.
I'm not trying to derail the conversation. Or even to urge strongly that HP remain on the downloads page. I've not followed the thread closely enough to be able to make such a stand. But while scrolling through, I saw Bryan's request, and I thought I'd answer it.
Happy booing! :)
Richard _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
[Sorry all about my previous email, I accidentally clicked "Send" before
typing anything.]
I don't personally get value from the HP, but my understanding is that
universities do. In particular, I've heard stories of professors teaching
Haskell courses and being able to ask their admin staff to "Install the
Haskell Platform" on the lab machines and then they tailor the course
materials to content in the HP.
If the HP were to go away, I feel strongly that we should have a
deprecation phase. Otherwise the users who do use it will feel like the rug
was pulled out from under them. Let's not cause that sort of pain if we
have the power to avoid it.
I agree with Gershom that having a minimal installer is the right way to
get going for professionals and hackers. I'm less in tune with beginners
these days, but I think Gershom is basically right when he says the are a
very diverse group and there isn't just one profile that fits the majority
of them.
On a personal side, I'm not sure what is entailed in giving objective info
about stack vs. cabal. I'm probably OK with it for some definitions, but if
it means giving stack equal status, then I feel that is a bit premature at
this point. In particular, cabal has the advantage of being established,
mature, and battle hardened. Stack, in my opinion, still needs time to
prove itself. Both have flaws, both have advantages, but only cabal has a
track record at the moment. Yes, I'm being conservative here, but I think
that's reasonable if we're talking about making recommendations to such a
wide audience.
On Thu, Sep 24, 2015 at 10:54 AM, Richard Eisenberg
On Sep 24, 2015, at 1:38 PM, Bryan Richter wrote:
Since I don't know anyone who likes or uses the HP, I think hearing their perspective would be valuable.
At the threat of being booed out of the community, I'll stand up and say I like the HP. Of course it should improve -- and I like the direction it's going -- but I've used it as it is and would do so again.
I think the observation that the HP promotes a ghc-centric view is why I like it. When working with a new language, I really do just want to think about the compiler. Only when I get around to trying to actually produce software do I care about a build tool. Starting with stack or cabal, instead of with ghc, means a much bigger cognitive load right away. Not only to you have Haskell files, but you also have .cabal files, and perhaps stack.yaml files. You have to think about directory structure -- both `cabal` and `stack` behave differently when they're run in or under a directory with project files than elsewhere.
But, when I'm starting out, and when my students are starting out, I just want to think about the language. Compilers have, at their core, a simple interface: program text in, program binary out. Simple! It may be totally insufficient for producing portable libraries and distributable software, but I'm not tackling those issues on my first day. The fact that the HP means I can install something and right away tinker in GHCi and explore some common libraries is great.
I'm not trying to derail the conversation. Or even to urge strongly that HP remain on the downloads page. I've not followed the thread closely enough to be able to make such a stand. But while scrolling through, I saw Bryan's request, and I thought I'd answer it.
Happy booing! :)
Richard _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
I feel compelled to defend the honor of Unix users here.
On 24/09/2015, Gershom B
some are old *nix hands and don’t know why everything can’t just use autoconf
Rather old GNU hands; autoconf is emphatically NOT part of Research Unix or early BSD.
Michael Snoyman
writes:
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 couldn't agree more, Michael. The new user is first in my mind with all of this. Perhaps we need a poll. So far the presented options are: 1. HP Stack Minimal 2. Stack HP Minimal 3. Stack Minimal HP 4. Minimal HP Stack 5. Minimal Stack HP I'll open voting at the current state, choosing #4. My reason is that HP and Stack will soon merge, and I'm willing to put Minimal first based on Christopher's and Gershom's arguments. Further, the reason HP is staying on the list for now is that I'd prefer not to conflate issues. I'm happy to start a new discussion, recommending to the committee that we remove HP, if others wish to. John
Given that: Most preferred -> Least preferred 3 5 2 4 1
I'm happy to start a new discussion, recommending to the committee that we remove HP, if others wish to.
Please do.
On Thu, Sep 24, 2015 at 12:23 PM, John Wiegley
Michael Snoyman
writes: 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 couldn't agree more, Michael. The new user is first in my mind with all of this.
Perhaps we need a poll. So far the presented options are:
1. HP Stack Minimal 2. Stack HP Minimal 3. Stack Minimal HP 4. Minimal HP Stack 5. Minimal Stack HP
I'll open voting at the current state, choosing #4. My reason is that HP and Stack will soon merge, and I'm willing to put Minimal first based on Christopher's and Gershom's arguments.
Further, the reason HP is staying on the list for now is that I'd prefer not to conflate issues. I'm happy to start a new discussion, recommending to the committee that we remove HP, if others wish to.
John _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
-- Chris Allen Currently working on http://haskellbook.com
On Thu, Sep 24, 2015 at 8:23 PM, John Wiegley
Michael Snoyman
writes: 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 couldn't agree more, Michael. The new user is first in my mind with all of this.
Perhaps we need a poll. So far the presented options are:
1. HP Stack Minimal 2. Stack HP Minimal 3. Stack Minimal HP 4. Minimal HP Stack 5. Minimal Stack HP
I'll open voting at the current state, choosing #4. My reason is that HP and Stack will soon merge, and I'm willing to put Minimal first based on Christopher's and Gershom's arguments.
Further, the reason HP is staying on the list for now is that I'd prefer not to conflate issues. I'm happy to start a new discussion, recommending to the committee that we remove HP, if others wish to.
John
3 > 5 > 2 > 4 > 1 (checks next email) Huh, exact same as Chris ;) Michael
My vote is 4, followed by 5. —Gershom On September 24, 2015 at 1:43:52 PM, Michael Snoyman (michael@fpcomplete.com) wrote:
On Thu, Sep 24, 2015 at 8:23 PM, John Wiegley wrote:
> Michael Snoyman writes:
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 couldn't agree more, Michael. The new user is first in my mind with all of this.
Perhaps we need a poll. So far the presented options are:
1. HP Stack Minimal 2. Stack HP Minimal 3. Stack Minimal HP 4. Minimal HP Stack 5. Minimal Stack HP
I'll open voting at the current state, choosing #4. My reason is that HP and Stack will soon merge, and I'm willing to put Minimal first based on Christopher's and Gershom's arguments.
Further, the reason HP is staying on the list for now is that I'd prefer not to conflate issues. I'm happy to start a new discussion, recommending to the committee that we remove HP, if others wish to.
John
3 > 5 > 2 > 4 > 1
(checks next email)
Huh, exact same as Chris ;)
Michael _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
I'll vote for #4 from this list, looking forward to a time when HP and Stack are the same option. (At which point it might be better than Minimal.)
On Sep 24, 2015, at 1:23 PM, John Wiegley
Michael Snoyman
writes: 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 couldn't agree more, Michael. The new user is first in my mind with all of this.
Perhaps we need a poll. So far the presented options are:
1. HP Stack Minimal 2. Stack HP Minimal 3. Stack Minimal HP 4. Minimal HP Stack 5. Minimal Stack HP
I'll open voting at the current state, choosing #4. My reason is that HP and Stack will soon merge, and I'm willing to put Minimal first based on Christopher's and Gershom's arguments.
Further, the reason HP is staying on the list for now is that I'd prefer not to conflate issues. I'm happy to start a new discussion, recommending to the committee that we remove HP, if others wish to.
John _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
I'm not too sure about the idea of voting directly - this seems like exactly what we have a committee for, to represent everyone rather than just the people who happen to be reading the right list at the right time. But anyway, if this is a poll of the whole list, I vote for #4. On Thu, 24 Sep 2015, John Wiegley wrote:
Michael Snoyman <michael at fpcomplete.com> writes:
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 couldn't agree more, Michael. The new user is first in my mind with all of this.
Perhaps we need a poll. So far the presented options are:
1. HP Stack Minimal 2. Stack HP Minimal 3. Stack Minimal HP 4. Minimal HP Stack 5. Minimal Stack HP
I'll open voting at the current state, choosing #4. My reason is that HP and Stack will soon merge, and I'm willing to put Minimal first based on Christopher's and Gershom's arguments.
Further, the reason HP is staying on the list for now is that I'd prefer not to conflate issues. I'm happy to start a new discussion, recommending to the committee that we remove HP, if others wish to.
John
On 09/24/2015 10:22 PM, Ganesh Sittampalam wrote:
I'm not too sure about the idea of voting directly - this seems like exactly what we have a committee for, to represent everyone rather than just the people who happen to be reading the right list at the right time.
For the committee to represent everyone, shouldn't the committee be *elected* by everyone? With all due respect to the committee and the work they do, I don't remember voting for them.
But anyway, if this is a poll of the whole list, I vote for #4.
I trust Michael's judgment; my vote goes to whatever he thinks is best. Roman
On 25/09/2015 07:27, Roman Cheplyaka wrote:
On 09/24/2015 10:22 PM, Ganesh Sittampalam wrote:
I'm not too sure about the idea of voting directly - this seems like exactly what we have a committee for, to represent everyone rather than just the people who happen to be reading the right list at the right time.
For the committee to represent everyone, shouldn't the committee be *elected* by everyone? With all due respect to the committee and the work they do, I don't remember voting for them.
That does feel like something that should happen at some point, but it would be a fair amount of effort to organise. In the meantime AFAIK the committee does make an effort to select its own successors in a balanced/representative way and I think it's the best thing we've got at present. Ganesh
If "Minimal" means "MinGHC" and if MinGHC, on Windows installations, puts the MSys2 tools onto the user's PATH, which is harmful, then the Minimal will not be "doing the least harm" for some users. So, if my "ifs" above are correct, is it possible to change minGHC before using it as the "Minimal" to address the PATH issue? (Apologies if I am out of date on any of these questions implied by my "ifs", and thanks for any clarifications.) ----------------------------------------
From: johnw@newartisans.com To: michael@fpcomplete.com Date: Thu, 24 Sep 2015 10:23:04 -0700 CC: haskell-community@haskell.org Subject: Re: [Haskell-community] Request for comment: New haskell.org download page
Michael Snoyman
writes: 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 couldn't agree more, Michael. The new user is first in my mind with all of this.
Perhaps we need a poll. So far the presented options are:
1. HP Stack Minimal 2. Stack HP Minimal 3. Stack Minimal HP 4. Minimal HP Stack 5. Minimal Stack HP
I'll open voting at the current state, choosing #4. My reason is that HP and Stack will soon merge, and I'm willing to put Minimal first based on Christopher's and Gershom's arguments.
Further, the reason HP is staying on the list for now is that I'd prefer not to conflate issues. I'm happy to start a new discussion, recommending to the committee that we remove HP, if others wish to.
John _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
My understanding is that minghc now provides a switcher script, and so does not stomp on a user’s path, but does require running a switcher before full access to the environment is provided. So that’s not an ideal situation, but certainly tolerable for the moment, and a marked improvement from the issues there before. —gershom On September 24, 2015 at 11:00:19 PM, Randy Polen (randyhaskell@outlook.com) wrote:
If "Minimal" means "MinGHC" and if MinGHC, on Windows installations, puts the MSys2 tools onto the user's PATH, which is harmful, then the Minimal will not be "doing the least harm" for some users.
So, if my "ifs" above are correct, is it possible to change minGHC before using it as the "Minimal" to address the PATH issue? (Apologies if I am out of date on any of these questions implied by my "ifs", and thanks for any clarifications.)
From: johnw@newartisans.com To: michael@fpcomplete.com Date: Thu, 24 Sep 2015 10:23:04 -0700 CC: haskell-community@haskell.org Subject: Re: [Haskell-community] Request for comment: New haskell.org download
---------------------------------------- page
> Michael Snoyman writes:
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 couldn't agree more, Michael. The new user is first in my mind with all of this.
Perhaps we need a poll. So far the presented options are:
1. HP Stack Minimal 2. Stack HP Minimal 3. Stack Minimal HP 4. Minimal HP Stack 5. Minimal Stack HP
I'll open voting at the current state, choosing #4. My reason is that HP and Stack will soon merge, and I'm willing to put Minimal first based on Christopher's and Gershom's arguments.
Further, the reason HP is staying on the list for now is that I'd prefer not to conflate issues. I'm happy to start a new discussion, recommending to the committee that we remove HP, if others wish to.
John _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
_______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
On Thu, Sep 24, 2015 at 8:23 PM, John Wiegley
Michael Snoyman
writes: 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 couldn't agree more, Michael. The new user is first in my mind with all of this.
Perhaps we need a poll. So far the presented options are:
1. HP Stack Minimal 2. Stack HP Minimal 3. Stack Minimal HP 4. Minimal HP Stack 5. Minimal Stack HP
I'll open voting at the current state, choosing #4. My reason is that HP and Stack will soon merge, and I'm willing to put Minimal first based on Christopher's and Gershom's arguments.
Further, the reason HP is staying on the list for now is that I'd prefer not to conflate issues. I'm happy to start a new discussion, recommending to the committee that we remove HP, if others wish to.
John
There was a lot of discussion on Twitter about this thread, but almost none of those participants wrote into this discussion. When I asked why[1], I got (at least[2]) two forms of response: 1. I don't want to sign up for another mailing list just to vote 2. Previous actions made it seem like the voting would be inconsequential to the outcome To try and lower the barrier to entry, I created a Google Form with the same questions as above: https://docs.google.com/forms/d/1w2wKSxn5YN4LtSXYHvFT2IFw_BDaT_2cjUkP9pDeqLQ... I've avoided sending it to "obviously biased" sources, like the Stack mailing list itself. It has 21 responses so far (including one from me for "Stack Minimal HP", so please don't count my vote twice). Given the obvious sentiment around (2) mentioned above, I think it's important to pay attention to what people are saying outside of this mailing list. Michael [1] https://twitter.com/snoyberg/status/647243155734155266 [2] One person commented that "If they are arguing against you, they aren't going to take my opinion seriously...". That might imply a variant of (2) above.
On Fri, Sep 25, 2015 at 08:41:31AM +0300, Michael Snoyman wrote:
There was a lot of discussion on Twitter about this thread, but almost none of those participants wrote into this discussion. When I asked why[1], I got (at least[2]) two forms of response:
1. I don't want to sign up for another mailing list just to vote 2. Previous actions made it seem like the voting would be inconsequential to the outcome
To try and lower the barrier to entry, I created a Google Form with the same questions as above:
[...]
Subscribing haskell-community is extremely useful and exciting! One can: 1. cast their vote on this particular issue 2. express their opinion in 'longhand' (which could be very useful towards reaching consensus) 3. get engaged with other persons (which could be useful for 2. or general "see what other people are thinking" benefit) 4. keep in touch with what the committee is discussing and contribute with his/her ideas even in the future A Google Form, as convenient as it is, doesn't allow/encourage 2., 3. and 4. (plus it seems to require a Google account, which I don't have). To the folks out there: join the fun! Haskell-community was created with this spirit in mind [1] (as this request for comments/votes show!) and subscribing to this mailing list is one way to contribute to the community we all love being part of. [1] https://mail.haskell.org/pipermail/haskell-cafe/2015-September/121328.html
On 25/09/2015 06:41, Michael Snoyman wrote:
Given the obvious sentiment around (2) mentioned above, I think it's important to pay attention to what people are saying outside of this mailing list.
This is exactly why I think committee@haskell.org should decide on this for itself (after listening to all constituencies), rather than relying on polls with rather confused electorates. For FTP it was worth making a serious effort to poll the whole community. This is only a short-term decision about something relatively minor and isn't worth that kind of undertaking. Ganesh
Friends
I’m a little worried at how many cycles we might burn to determine the order of three items in a list, when
· hopefully it’ll become largely irrelevant when we get the new HP (months not years)
· if the consequences of choices are clearly articulated, the order is not very important
I know that high-contributing members of our community have differing, strongly held views; and that these differences are not mere whims but are based on a thoughtful judgements. If we can’t come to a common view (and we should not take that as failure – professional judgements often differ), perhaps the two points suggest a path to a holding position we can all live with?
(John: that might mean that the download page has more info than you’d really like, but I think that’s a lesser evil. In any case, as a possibly-weird user, I think that most download pages are dismayingly short of information.)
Simon
From: Haskell-community [mailto:haskell-community-bounces@haskell.org] On Behalf Of Michael Snoyman
Sent: 25 September 2015 06:42
To: John Wiegley
Cc: haskell-community@haskell.org
Subject: Re: [Haskell-community] Request for comment: New haskell.org download page
On Thu, Sep 24, 2015 at 8:23 PM, John Wiegley
Michael Snoyman
mailto:michael@fpcomplete.com> writes:
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 couldn't agree more, Michael. The new user is first in my mind with all of this. Perhaps we need a poll. So far the presented options are: 1. HP Stack Minimal 2. Stack HP Minimal 3. Stack Minimal HP 4. Minimal HP Stack 5. Minimal Stack HP I'll open voting at the current state, choosing #4. My reason is that HP and Stack will soon merge, and I'm willing to put Minimal first based on Christopher's and Gershom's arguments. Further, the reason HP is staying on the list for now is that I'd prefer not to conflate issues. I'm happy to start a new discussion, recommending to the committee that we remove HP, if others wish to. John There was a lot of discussion on Twitter about this thread, but almost none of those participants wrote into this discussion. When I asked why[1], I got (at least[2]) two forms of response: 1. I don't want to sign up for another mailing list just to vote 2. Previous actions made it seem like the voting would be inconsequential to the outcome To try and lower the barrier to entry, I created a Google Form with the same questions as above: https://docs.google.com/forms/d/1w2wKSxn5YN4LtSXYHvFT2IFw_BDaT_2cjUkP9pDeqLQ...https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdocs.google.com%2fforms%2fd%2f1w2wKSxn5YN4LtSXYHvFT2IFw_BDaT_2cjUkP9pDeqLQ%2fviewform%3fusp%3dsend_form&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c9698b16b5e4e4294ffba08d2c56c0b66%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CPki0hqUyLiyUsklBCLrJID7BgvkL0iJ2PkXLvTFlrU%3d I've avoided sending it to "obviously biased" sources, like the Stack mailing list itself. It has 21 responses so far (including one from me for "Stack Minimal HP", so please don't count my vote twice). Given the obvious sentiment around (2) mentioned above, I think it's important to pay attention to what people are saying outside of this mailing list. Michael [1] https://twitter.com/snoyberg/status/647243155734155266https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftwitter.com%2fsnoyberg%2fstatus%2f647243155734155266&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c9698b16b5e4e4294ffba08d2c56c0b66%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EGGyQKaJI51A1lkrXXq1%2fb08GFGViynlO37qz5%2fWlyQ%3d [2] One person commented that "If they are arguing against you, they aren't going to take my opinion seriously...". That might imply a variant of (2) above.
Michael Snoyman
writes:
There was a lot of discussion on Twitter about this thread, but almost none of those participants wrote into this discussion. When I asked why[1], I got (at least[2]) two forms of response:
1. I don't want to sign up for another mailing list just to vote
I've been there before.
2. Previous actions made it seem like the voting would be inconsequential to the outcome
This is most unfortunate. The voting certainly matters, since I'm looking for community feedback to finalize the edits.
To try and lower the barrier to entry, I created a Google Form with the same questions as above:
https://docs.google.com/forms/d/1w2wKSxn5YN4LtSXYHvFT2IFw_BDaT_2cjUkP9pDeqLQ...
Thanks for this additional data. I've counted the most votes on the ML for #4. Several of those voting for #4 also voted for #5. The Google Form seems to strongly prefer #3 and #5. So let's drop this down to the three main choices: (A) Stack Minimal HP (B) Minimal HP Stack (C) Minimal Stack HP (A) has a very strong showing on the Google Form, but not on the ML. The arguments I've collected right now for not preferring (A) are: - Stack hasn't proven itself over time yet, the way cabal has. - Stack doesn't actually download a Haskell compiler. - Stack does not make using "ghci" easy. As for whether HP should be first or not (B or C), I don't have strong feelings, since we *are* going to merge the two options. I'd like to open a second round of voting now on these three options, unless someone wishes to make a case for those that were dropped.
Given the obvious sentiment around (2) mentioned above, I think it's important to pay attention to what people are saying outside of this mailing list.
If you know of discussions happening elsewhere (SO, reddit, Google+, etc), please let me know, since I don't follow those communities. I only happened upon your Twitter discussion because Gabriel retweeted it. John
On Fri, Sep 25, 2015 at 9:25 PM, John Wiegley
Michael Snoyman
writes: There was a lot of discussion on Twitter about this thread, but almost none of those participants wrote into this discussion. When I asked why[1], I got (at least[2]) two forms of response:
1. I don't want to sign up for another mailing list just to vote
I've been there before.
2. Previous actions made it seem like the voting would be inconsequential to the outcome
This is most unfortunate. The voting certainly matters, since I'm looking for community feedback to finalize the edits.
To try and lower the barrier to entry, I created a Google Form with the same questions as above:
https://docs.google.com/forms/d/1w2wKSxn5YN4LtSXYHvFT2IFw_BDaT_2cjUkP9pDeqLQ...
Thanks for this additional data.
I've counted the most votes on the ML for #4. Several of those voting for #4 also voted for #5. The Google Form seems to strongly prefer #3 and #5. So let's drop this down to the three main choices:
(A) Stack Minimal HP (B) Minimal HP Stack (C) Minimal Stack HP
(A) has a very strong showing on the Google Form, but not on the ML. The arguments I've collected right now for not preferring (A) are:
- Stack hasn't proven itself over time yet, the way cabal has. - Stack doesn't actually download a Haskell compiler. - Stack does not make using "ghci" easy.
As for whether HP should be first or not (B or C), I don't have strong feelings, since we *are* going to merge the two options.
I'd like to open a second round of voting now on these three options, unless someone wishes to make a case for those that were dropped.
Given the obvious sentiment around (2) mentioned above, I think it's important to pay attention to what people are saying outside of this mailing list.
If you know of discussions happening elsewhere (SO, reddit, Google+, etc), please let me know, since I don't follow those communities. I only happened upon your Twitter discussion because Gabriel retweeted it.
John
I don't think another round of voting is necessary, and I think asking for it is a clear message of not listening to people who voted the first time. I'm also cognizant of Simon's comments about spending too much time on this, which frankly I've already far overextended on. This response is probably going to get a bit meander-y, but I want to make sure we're on the same page about things. The point has been raised multiple times that - in the future - Stack and HP will really be the same option. I actually have a very different read on the situation: today, Stack and *minimal installers* are the same option. I would never have categorized them as being two separate choices, but as really being the same choice with a few distinguishing characteristics: * Stack: easily download multiple versions of GHC, easier upgrade path, doesn't add a lot of binaries to your PATH. Allow easily downloading and building all additional tools (alex, happy, cabal-install, etc) * Minimal installers: provide Stack, alex, happy, cabal-install, and GHC out of the box. Preferable if: you don't want a build tool downloading your compiler, you'll be reusing the downloaded file on multiple machines, you want to use cabal-install instead of Stack, or you want to make sure you have GHC and friends on the PATH. My proposal - which is very much in line with the voting results - would be to make this section first, and the Haskell Platform section second. I'm not sure if opening this can of worms now is a good idea or not, but I'll ask it: I don't understand what the future vision is for the Haskell Platform relative to the minimal installers. As I see it, in the future the Haskell Platform will be indistinguishable from today's MinGHC/GHC for Mac OS X, with the possible addition of some global constraint file that is still too ill-defined for me to be certain what it's going to do[1]. Richard: your concern seems to be having a GHC available on the path that students can use today. Where do the minimal installers fall short on this? The big area I see where that will happen is that HP includes more packages in the global database. But that's exactly the aspect of HP which is planned to change in the next release, meaning the advantage you're going for is going to disappear anyway. I realize I've muddled many things together here (and perhaps a separate "future of HP" thread is in order), but I've just been getting more confused reading the various responses. So to sum up, here's what I'd really see as the future of the downloads page: * Links provided for a minimal installer and Stack itself * I picture that at some point, instead of having HP and MinGHC/GHC for Mac OS X, we'll just have one option. I don't care what that option is called, so may as well call it HP * Explanation along the lines I gave above about difference between Stack and minimal installer, possibly also about difference between Stack and cabal-install (I'd focus on curation vs dependency solving, even though that's not technically the primary difference between the two) * Including "getting started" style guides for using each tool. The Stack guide could work for both Stack itself and the minimal installer, and in the future a link to a cabal-install guide could be provided as well With this approach, I think we can give very concrete advice to new users, collapse the download options down significantly, and streamline the community efforts on installers substantially. In the short term: we keep a link to the HP at the bottom of the page, explaining that it ships with more packages than minimal installers, and that in some cases it can be difficult to upgrade those packages. As a side note, this is not terribly different from what I proposed originally in my pull request[2]. Michael [1] https://mail.haskell.org/pipermail/cabal-devel/2015-September/010247.html [2] https://github.com/haskell-infra/hl/pull/130
Michael Snoyman
writes:
With this approach, I think we can give very concrete advice to new users, collapse the download options down significantly, and streamline the community efforts on installers substantially. In the short term: we keep a link to the HP at the bottom of the page, explaining that it ships with more packages than minimal installers, and that in some cases it can be difficult to upgrade those packages.
As a side note, this is not terribly different from what I proposed originally in my pull request[2].
I think that in the interests of time, I'm going to close this discussion now (thanks for all who sent second round votes by e-mail), and will go with the following order, to be published by Monday: Minimal, Stack, HP We can open follow-on discussions after that to tweak the page with whatever clarifications or simplifications we feel are necessary. The only remaining edits to be applied are the clarifications from Mathieu, and to finish out the bottom of the page (the third-party stuff). John
John Wiegley
writes:
We can open follow-on discussions after that to tweak the page with whatever clarifications or simplifications we feel are necessary. The only remaining edits to be applied are the clarifications from Mathieu, and to finish out the bottom of the page (the third-party stuff).
I did forget to mention: Thanks to everyone who participated in this marathon! It was clear there was no one choice that suited everyone's fancy, but at least we arrived at a way to inch forward to the next step. John
On Sat, Sep 26, 2015 at 10:51 PM, John Wiegley
John Wiegley
writes: We can open follow-on discussions after that to tweak the page with whatever clarifications or simplifications we feel are necessary. The only remaining edits to be applied are the clarifications from Mathieu, and to finish out the bottom of the page (the third-party stuff).
I did forget to mention: Thanks to everyone who participated in this marathon! It was clear there was no one choice that suited everyone's fancy, but at least we arrived at a way to inch forward to the next step.
John
I said it privately, but it's deserved publicly: thank you very much John, I know you're putting a lot of effort into making the best decisions possible here. I agree with your call on this for now, and will continue the discussion when I have something to add in the (probably near) future. Michael
I said it privately, but it's deserved publicly: thank you very much John, I know you're putting a lot of effort into making the best decisions possible here. I agree with your call on this for now, and will continue the discussion when I have something to add in the (probably near) future.
Yes, thank you John! There are lots of considerations here, for different classes of users and purposes, and it’s been extremely helpful to have you chair the discussion and bring it to a conclusion.
I think the debate will also provide helpful guidance for what we want the new HP to do, to make the new story simpler to tell than the current one.
Anyway, thank you.
Simon
From: Haskell-community [mailto:haskell-community-bounces@haskell.org] On Behalf Of Michael Snoyman
Sent: 26 September 2015 21:03
To: John Wiegley
Cc: haskell-community@haskell.org
Subject: Re: [Haskell-community] Request for comment: New haskell.org download page
On Sat, Sep 26, 2015 at 10:51 PM, John Wiegley
John Wiegley
mailto:johnw@newartisans.com> writes:
We can open follow-on discussions after that to tweak the page with whatever clarifications or simplifications we feel are necessary. The only remaining edits to be applied are the clarifications from Mathieu, and to finish out the bottom of the page (the third-party stuff).
I did forget to mention: Thanks to everyone who participated in this marathon! It was clear there was no one choice that suited everyone's fancy, but at least we arrived at a way to inch forward to the next step. John I said it privately, but it's deserved publicly: thank you very much John, I know you're putting a lot of effort into making the best decisions possible here. I agree with your call on this for now, and will continue the discussion when I have something to add in the (probably near) future. Michael
I'm pleased with and encouraged by the conversation that was had.
Thank you John, looking forward to collaborating with you more in the
future :)
On Mon, Sep 28, 2015 at 2:59 AM, Simon Peyton Jones
I said it privately, but it's deserved publicly: thank you very much John, I know you're putting a lot of effort into making the best decisions possible here. I agree with your call on this for now, and will continue the discussion when I have something to add in the (probably near) future.
Yes, thank you John! There are lots of considerations here, for different classes of users and purposes, and it’s been extremely helpful to have you chair the discussion and bring it to a conclusion.
I think the debate will also provide helpful guidance for what we want the new HP to do, to make the new story simpler to tell than the current one.
Anyway, thank you.
Simon
*From:* Haskell-community [mailto:haskell-community-bounces@haskell.org] *On Behalf Of *Michael Snoyman *Sent:* 26 September 2015 21:03 *To:* John Wiegley *Cc:* haskell-community@haskell.org *Subject:* Re: [Haskell-community] Request for comment: New haskell.org download page
On Sat, Sep 26, 2015 at 10:51 PM, John Wiegley
wrote: John Wiegley
writes: We can open follow-on discussions after that to tweak the page with whatever clarifications or simplifications we feel are necessary. The only remaining edits to be applied are the clarifications from Mathieu, and to finish out the bottom of the page (the third-party stuff).
I did forget to mention: Thanks to everyone who participated in this marathon! It was clear there was no one choice that suited everyone's fancy, but at least we arrived at a way to inch forward to the next step.
John
I said it privately, but it's deserved publicly: thank you very much John, I know you're putting a lot of effort into making the best decisions possible here. I agree with your call on this for now, and will continue the discussion when I have something to add in the (probably near) future.
Michael
_______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
-- Chris Allen Currently working on http://haskellbook.com
Christopher Allen
writes:
I'm pleased with and encouraged by the conversation that was had. Thank you John, looking forward to collaborating with you more in the future : )
Thank you, Christopher, Michael, Simon, Gershom, and everyone else who participated these past weeks. I'm also happy with the progress we made -- but especially with how we made it. The technical details have unfolded at a maddeningly slow rate, but we made significant progress at broadening the field of collaboration between several principle contributors in the community. We (the committee) are going to continue this process in the future: of using -community to discuss issues on a broader scale, with myself continuing to act as a sort of "secretary" to ensure that the community-wide discussion is heard by the committee and recorded, and nothing is ignored. Whatever issues people have to discuss, feel free to bring them up here! and invite others to do so who have any ideas or knowledge to contribute. John
On 24/09/2015 18:23, John Wiegley wrote:
Michael Snoyman
writes: 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 couldn't agree more, Michael. The new user is first in my mind with all of this.
Perhaps we need a poll. So far the presented options are:
1. HP Stack Minimal 2. Stack HP Minimal 3. Stack Minimal HP 4. Minimal HP Stack 5. Minimal Stack HP
I'll open voting at the current state, choosing #4. My reason is that HP and Stack will soon merge, and I'm willing to put Minimal first based on Christopher's and Gershom's arguments.
Further, the reason HP is staying on the list for now is that I'd prefer not to conflate issues. I'm happy to start a new discussion, recommending to the committee that we remove HP, if others wish to.
I think it would be strange to download and install Haskell from the download page and then not be able to type "ghci" and get a prompt, or use ghc to compile some code. I appreciate that there are now a lot of users and use cases that just don't use Haskell this way, but there are also a lot who do. We won't be able to figure out the relative size of these two groups easily, and I suspect a vote/poll is likely to give misleading results. But since there are few downsides to the minimal installer for those who want to use Stack, that seems like the best overall choice. Hence, #4/#5 for me equally. Ideally the Linux minimal installer would include Stack too, for consistency and so that we don't have to have the explicit special-case text on the download page. Cheers Simon
Exactly my thoughts. With all the love I have for Stack, if you want to
just run ghc(i), you wouldn't be able to do so after installing stack.
You'd need to:
1. run `stack setup`
2. edit your PATH to point wherever ghc(i) is installed
And these aren't even clear out of current instructions for a newbie.
So, for me, ideal option would be: Minimal which always provides stack (and
recommends it for managing projects). Before that happens, I voted for
"stack minimal HP" way, because it's better to learn how stack works than
to fall into "I don't have stack, I don't want to waste my time on it,
let's just use everything global" way.
On Fri, Sep 25, 2015 at 10:10 AM, Simon Marlow
On 24/09/2015 18:23, John Wiegley wrote:
Michael Snoyman
writes: >
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 couldn't agree more, Michael. The new user is first in my mind with all of this.
Perhaps we need a poll. So far the presented options are:
1. HP Stack Minimal 2. Stack HP Minimal 3. Stack Minimal HP 4. Minimal HP Stack 5. Minimal Stack HP
I'll open voting at the current state, choosing #4. My reason is that HP and Stack will soon merge, and I'm willing to put Minimal first based on Christopher's and Gershom's arguments.
Further, the reason HP is staying on the list for now is that I'd prefer not to conflate issues. I'm happy to start a new discussion, recommending to the committee that we remove HP, if others wish to.
I think it would be strange to download and install Haskell from the download page and then not be able to type "ghci" and get a prompt, or use ghc to compile some code. I appreciate that there are now a lot of users and use cases that just don't use Haskell this way, but there are also a lot who do. We won't be able to figure out the relative size of these two groups easily, and I suspect a vote/poll is likely to give misleading results. But since there are few downsides to the minimal installer for those who want to use Stack, that seems like the best overall choice.
Hence, #4/#5 for me equally.
Ideally the Linux minimal installer would include Stack too, for consistency and so that we don't have to have the explicit special-case text on the download page.
Cheers Simon
_______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Hi John,
this is a nice summary of all options. May I suggest the following
refinements to the summaries:
"
There are three widely used ways to install the Haskell toolchain on
supported platforms. Currently these are:
* Minimal installers: install just GHC (the compiler) in a global
location on your system, using your system's package manager. (On
Windows and OS X, also installs build tools.)
* Stack: nothing is installed globally, except the stack command.
Stack is a project-centric build tool that will automatically download
and manage compiler and library versions locally on a project by
project basis.
* Haskell Platform: installs all of GHC (the compiler), cabal-install
(a build tool), misc tools and a starter set of libraries in a global
location on your system.
If you opt for the minimal installer option for your platform, you'll
likely still need to install one or more build tools (cabal-install or
stack) separately.
"
The important point is that these options only differ in what gets
installed globally, as opposed to (semantically speaking)
locally-within-your-project (stack, cabal-install+sandboxes) or
locally-within-your-homedir (cabal-install sans sandboxes). There
ought be a paragraph somewhere near the top discussing upfront the
tradeoffs, which include:
* globally installed resources are conveniently and straightforwardly
available to all users, and need only be downloaded once for all
users. But,
* globally installed resources are inflexible: it's hard to have
multiple versions installed simultaneously, _because conflicts tend to
arise_. This is particularly bad in the case of globally installed
libraries.
I think this paragraph should specifically mention the problems
related to HP as it stands today. That paragraph can be removed once
the HP no longer installs libraries globally.
In my mind, it doesn't really matter what order things are in, from
the moment that the main differentiators of each option are crisply
and clearly defined. That said, the rationale behind the order above
is:
* minimal first, because that's what people normally expect (get the
compiler, no bells and whistles).
* HP last, because unless you're a student and the instructor
specifically told you to download the HP, chances are you're going to
run into trouble with this option (will change in the future, at which
point we'll just have HP + minimal anyways).
Any other order should work just as well.
On 24 September 2015 at 07:20, John Wiegley
As mentioned earlier, I've been working on a draft version of the new Haskell download page in consultation with Simon PJ, Michael Snoyman, and Gershom Bazerman. The goal has been twofold:
a) add stack as an explicit option, and
b) add text to each option indicating clearly what it provides and where to get further help, so users can understand the options and make an informed choice.
We've sought to keep the text factual, rather than imply that one option is "best" for any particular class of user, since opinions vary so widely on this point.
At the following link, you'll find a draft version of the new page for comment:
https://gist.github.com/jwiegley/153d968ddfc9046ee4c9
Hopefully it can go live on haskell.org next week, so please contribute your edits here, or by pull request. The goal is to explain each option so that people can make an informed decision.
However, the order of presentation does imply that whatever comes first is "preferred" even if that is not the intent. The order currently given is HP, Stack, Minimal. Chris has already made a few points about changing this order, so let's continue that discussion and see where it leads us.
Bear in mind that this is (hopefully) only an interim state. The plan is to add Stack to the Platform, and render the Platform minimal, which will consolidate this page down to a single, recommended download path.
At the bottom of the gist are incomplete sections on third party libraries and alternate installation approaches. These have yet to be written. The hope is to resolve the top content first and sort the rest out after; however, ideas for that content is most welcome too.
Thank you, John Wiegley _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
I am traveling/conferencing and cannot keep fully up to date with this
conversation, but I'd like to appreciate the work of the folks contributing
to this thread. I'm happy that the creation of this mailing list has opened
up these processes to a broader audience. My preference here is option 4
for now, with the hope that the upcoming HP changes will render moot the
split between these options.
On Thu, Sep 24, 2015 at 2:22 PM, Boespflug, Mathieu
Hi John,
this is a nice summary of all options. May I suggest the following refinements to the summaries:
" There are three widely used ways to install the Haskell toolchain on supported platforms. Currently these are:
* Minimal installers: install just GHC (the compiler) in a global location on your system, using your system's package manager. (On Windows and OS X, also installs build tools.) * Stack: nothing is installed globally, except the stack command. Stack is a project-centric build tool that will automatically download and manage compiler and library versions locally on a project by project basis. * Haskell Platform: installs all of GHC (the compiler), cabal-install (a build tool), misc tools and a starter set of libraries in a global location on your system.
If you opt for the minimal installer option for your platform, you'll likely still need to install one or more build tools (cabal-install or stack) separately. "
The important point is that these options only differ in what gets installed globally, as opposed to (semantically speaking) locally-within-your-project (stack, cabal-install+sandboxes) or locally-within-your-homedir (cabal-install sans sandboxes). There ought be a paragraph somewhere near the top discussing upfront the tradeoffs, which include:
* globally installed resources are conveniently and straightforwardly available to all users, and need only be downloaded once for all users. But, * globally installed resources are inflexible: it's hard to have multiple versions installed simultaneously, _because conflicts tend to arise_. This is particularly bad in the case of globally installed libraries.
I think this paragraph should specifically mention the problems related to HP as it stands today. That paragraph can be removed once the HP no longer installs libraries globally.
In my mind, it doesn't really matter what order things are in, from the moment that the main differentiators of each option are crisply and clearly defined. That said, the rationale behind the order above is:
* minimal first, because that's what people normally expect (get the compiler, no bells and whistles). * HP last, because unless you're a student and the instructor specifically told you to download the HP, chances are you're going to run into trouble with this option (will change in the future, at which point we'll just have HP + minimal anyways).
Any other order should work just as well.
As mentioned earlier, I've been working on a draft version of the new Haskell download page in consultation with Simon PJ, Michael Snoyman, and Gershom Bazerman. The goal has been twofold:
a) add stack as an explicit option, and
b) add text to each option indicating clearly what it provides and where to get further help, so users can understand the options and make an informed choice.
We've sought to keep the text factual, rather than imply that one option is "best" for any particular class of user, since opinions vary so widely on this point.
At the following link, you'll find a draft version of the new page for comment:
https://gist.github.com/jwiegley/153d968ddfc9046ee4c9
Hopefully it can go live on haskell.org next week, so please contribute your edits here, or by pull request. The goal is to explain each option so
people can make an informed decision.
However, the order of presentation does imply that whatever comes first is "preferred" even if that is not the intent. The order currently given is HP, Stack, Minimal. Chris has already made a few points about changing this order, so let's continue that discussion and see where it leads us.
Bear in mind that this is (hopefully) only an interim state. The plan is to add Stack to the Platform, and render the Platform minimal, which will consolidate this page down to a single, recommended download path.
At the bottom of the gist are incomplete sections on third party
On 24 September 2015 at 07:20, John Wiegley
wrote: that libraries and alternate installation approaches. These have yet to be written. The hope is to resolve the top content first and sort the rest out after; however, ideas for that content is most welcome too.
Thank you, John Wiegley _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Voting for option #4 for now, in order to give stack a longer test-of-time.
Stack may evolve to be more universally adopted, or changes to cabal may
alleviate the complaints about HP. It seems wise to see what happens and to
limit the turn-over of preferred install options confronting new Haskellers.
On Thu, Sep 24, 2015 at 3:43 PM, Adam Foltzer
I am traveling/conferencing and cannot keep fully up to date with this conversation, but I'd like to appreciate the work of the folks contributing to this thread. I'm happy that the creation of this mailing list has opened up these processes to a broader audience. My preference here is option 4 for now, with the hope that the upcoming HP changes will render moot the split between these options.
On Thu, Sep 24, 2015 at 2:22 PM, Boespflug, Mathieu
wrote: Hi John,
this is a nice summary of all options. May I suggest the following refinements to the summaries:
" There are three widely used ways to install the Haskell toolchain on supported platforms. Currently these are:
* Minimal installers: install just GHC (the compiler) in a global location on your system, using your system's package manager. (On Windows and OS X, also installs build tools.) * Stack: nothing is installed globally, except the stack command. Stack is a project-centric build tool that will automatically download and manage compiler and library versions locally on a project by project basis. * Haskell Platform: installs all of GHC (the compiler), cabal-install (a build tool), misc tools and a starter set of libraries in a global location on your system.
If you opt for the minimal installer option for your platform, you'll likely still need to install one or more build tools (cabal-install or stack) separately. "
The important point is that these options only differ in what gets installed globally, as opposed to (semantically speaking) locally-within-your-project (stack, cabal-install+sandboxes) or locally-within-your-homedir (cabal-install sans sandboxes). There ought be a paragraph somewhere near the top discussing upfront the tradeoffs, which include:
* globally installed resources are conveniently and straightforwardly available to all users, and need only be downloaded once for all users. But, * globally installed resources are inflexible: it's hard to have multiple versions installed simultaneously, _because conflicts tend to arise_. This is particularly bad in the case of globally installed libraries.
I think this paragraph should specifically mention the problems related to HP as it stands today. That paragraph can be removed once the HP no longer installs libraries globally.
In my mind, it doesn't really matter what order things are in, from the moment that the main differentiators of each option are crisply and clearly defined. That said, the rationale behind the order above is:
* minimal first, because that's what people normally expect (get the compiler, no bells and whistles). * HP last, because unless you're a student and the instructor specifically told you to download the HP, chances are you're going to run into trouble with this option (will change in the future, at which point we'll just have HP + minimal anyways).
Any other order should work just as well.
As mentioned earlier, I've been working on a draft version of the new Haskell download page in consultation with Simon PJ, Michael Snoyman, and Gershom Bazerman. The goal has been twofold:
a) add stack as an explicit option, and
b) add text to each option indicating clearly what it provides and where to get further help, so users can understand the options and make an informed choice.
We've sought to keep the text factual, rather than imply that one
"best" for any particular class of user, since opinions vary so widely on this point.
At the following link, you'll find a draft version of the new page for comment:
https://gist.github.com/jwiegley/153d968ddfc9046ee4c9
Hopefully it can go live on haskell.org next week, so please contribute your edits here, or by pull request. The goal is to explain each option so
people can make an informed decision.
However, the order of presentation does imply that whatever comes first is "preferred" even if that is not the intent. The order currently given is HP, Stack, Minimal. Chris has already made a few points about changing this order, so let's continue that discussion and see where it leads us.
Bear in mind that this is (hopefully) only an interim state. The plan is to add Stack to the Platform, and render the Platform minimal, which will consolidate this page down to a single, recommended download path.
At the bottom of the gist are incomplete sections on third party
On 24 September 2015 at 07:20, John Wiegley
wrote: option is that libraries and alternate installation approaches. These have yet to be written. The hope is to resolve the top content first and sort the rest out after; however, ideas for that content is most welcome too.
Thank you, John Wiegley _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
_______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Running through the thread up to this point my preferences would run to
options 4 or 5. I'm almost equally split between the two, but both put the
minimal installer at the top of the list addressing the bulk of the
objections raised here, and avoid letting the platform scribble all over
the global package database.
The minimal install seems to "do the least harm" while ensuring that folks
have an actual compiler in hand when they get done with our download page.
The user is at a download page for Haskell, downloading and not getting a
GHC install out of the box (stack first) seems to run contrary to the
primary motivation for folks to come to the page.
If it also bundled stack as well across all systems I think it'd address
most of the concerns addressed by the 'stack only' option. To split hairs,
I think while the linux installer for the minimal distribution doesn't
include stack I lean slightly towards 5 over 4, and when and if we can fix
it so that it does include stack then I'd lean towards 4 over 5.
If in the future Ed Yang's "no-reinstall" cabal stuff gets into mainline,
and/or stack gets incorporated into the platform, and the attendant issues
get worked out in good faith by all parties, then the landscape could
likely change considerably and the pros of putting the Haskell Platform at
the top of the list may well outweigh the cons, but we're not yet in that
world.
-Edward
On Thu, Sep 24, 2015 at 3:43 PM, Adam Foltzer
I am traveling/conferencing and cannot keep fully up to date with this conversation, but I'd like to appreciate the work of the folks contributing to this thread. I'm happy that the creation of this mailing list has opened up these processes to a broader audience. My preference here is option 4 for now, with the hope that the upcoming HP changes will render moot the split between these options.
On Thu, Sep 24, 2015 at 2:22 PM, Boespflug, Mathieu
wrote: Hi John,
this is a nice summary of all options. May I suggest the following refinements to the summaries:
" There are three widely used ways to install the Haskell toolchain on supported platforms. Currently these are:
* Minimal installers: install just GHC (the compiler) in a global location on your system, using your system's package manager. (On Windows and OS X, also installs build tools.) * Stack: nothing is installed globally, except the stack command. Stack is a project-centric build tool that will automatically download and manage compiler and library versions locally on a project by project basis. * Haskell Platform: installs all of GHC (the compiler), cabal-install (a build tool), misc tools and a starter set of libraries in a global location on your system.
If you opt for the minimal installer option for your platform, you'll likely still need to install one or more build tools (cabal-install or stack) separately. "
The important point is that these options only differ in what gets installed globally, as opposed to (semantically speaking) locally-within-your-project (stack, cabal-install+sandboxes) or locally-within-your-homedir (cabal-install sans sandboxes). There ought be a paragraph somewhere near the top discussing upfront the tradeoffs, which include:
* globally installed resources are conveniently and straightforwardly available to all users, and need only be downloaded once for all users. But, * globally installed resources are inflexible: it's hard to have multiple versions installed simultaneously, _because conflicts tend to arise_. This is particularly bad in the case of globally installed libraries.
I think this paragraph should specifically mention the problems related to HP as it stands today. That paragraph can be removed once the HP no longer installs libraries globally.
In my mind, it doesn't really matter what order things are in, from the moment that the main differentiators of each option are crisply and clearly defined. That said, the rationale behind the order above is:
* minimal first, because that's what people normally expect (get the compiler, no bells and whistles). * HP last, because unless you're a student and the instructor specifically told you to download the HP, chances are you're going to run into trouble with this option (will change in the future, at which point we'll just have HP + minimal anyways).
Any other order should work just as well.
As mentioned earlier, I've been working on a draft version of the new Haskell download page in consultation with Simon PJ, Michael Snoyman, and Gershom Bazerman. The goal has been twofold:
a) add stack as an explicit option, and
b) add text to each option indicating clearly what it provides and where to get further help, so users can understand the options and make an informed choice.
We've sought to keep the text factual, rather than imply that one
"best" for any particular class of user, since opinions vary so widely on this point.
At the following link, you'll find a draft version of the new page for comment:
https://gist.github.com/jwiegley/153d968ddfc9046ee4c9
Hopefully it can go live on haskell.org next week, so please contribute your edits here, or by pull request. The goal is to explain each option so
people can make an informed decision.
However, the order of presentation does imply that whatever comes first is "preferred" even if that is not the intent. The order currently given is HP, Stack, Minimal. Chris has already made a few points about changing this order, so let's continue that discussion and see where it leads us.
Bear in mind that this is (hopefully) only an interim state. The plan is to add Stack to the Platform, and render the Platform minimal, which will consolidate this page down to a single, recommended download path.
At the bottom of the gist are incomplete sections on third party
On 24 September 2015 at 07:20, John Wiegley
wrote: option is that libraries and alternate installation approaches. These have yet to be written. The hope is to resolve the top content first and sort the rest out after; however, ideas for that content is most welcome too.
Thank you, John Wiegley _______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
_______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
I like the way Mathieu sets things out here. Facts, and the factual consequences of choices, are very helpful. If they are clearly stated, order should be nigh irrelevant.
Simon
| -----Original Message-----
| From: Haskell-community [mailto:haskell-community-bounces@haskell.org] On
| Behalf Of Boespflug, Mathieu
| Sent: 24 September 2015 20:23
| To: John Wiegley
| Cc: haskell-community@haskell.org
| Subject: Re: [Haskell-community] Request for comment: New haskell.org
| download page
|
| Hi John,
|
| this is a nice summary of all options. May I suggest the following
| refinements to the summaries:
|
| "
| There are three widely used ways to install the Haskell toolchain on
| supported platforms. Currently these are:
|
| * Minimal installers: install just GHC (the compiler) in a global
| location on your system, using your system's package manager. (On
| Windows and OS X, also installs build tools.)
| * Stack: nothing is installed globally, except the stack command.
| Stack is a project-centric build tool that will automatically download
| and manage compiler and library versions locally on a project by
| project basis.
| * Haskell Platform: installs all of GHC (the compiler), cabal-install
| (a build tool), misc tools and a starter set of libraries in a global
| location on your system.
|
| If you opt for the minimal installer option for your platform, you'll
| likely still need to install one or more build tools (cabal-install or
| stack) separately.
| "
|
| The important point is that these options only differ in what gets
| installed globally, as opposed to (semantically speaking)
| locally-within-your-project (stack, cabal-install+sandboxes) or
| locally-within-your-homedir (cabal-install sans sandboxes). There
| ought be a paragraph somewhere near the top discussing upfront the
| tradeoffs, which include:
|
| * globally installed resources are conveniently and straightforwardly
| available to all users, and need only be downloaded once for all
| users. But,
| * globally installed resources are inflexible: it's hard to have
| multiple versions installed simultaneously, _because conflicts tend to
| arise_. This is particularly bad in the case of globally installed
| libraries.
|
| I think this paragraph should specifically mention the problems
| related to HP as it stands today. That paragraph can be removed once
| the HP no longer installs libraries globally.
|
| In my mind, it doesn't really matter what order things are in, from
| the moment that the main differentiators of each option are crisply
| and clearly defined. That said, the rationale behind the order above
| is:
|
| * minimal first, because that's what people normally expect (get the
| compiler, no bells and whistles).
| * HP last, because unless you're a student and the instructor
| specifically told you to download the HP, chances are you're going to
| run into trouble with this option (will change in the future, at which
| point we'll just have HP + minimal anyways).
|
| Any other order should work just as well.
|
|
|
| On 24 September 2015 at 07:20, John Wiegley
Boespflug, Mathieu
writes:
this is a nice summary of all options. May I suggest the following refinements to the summaries:
Hi Mathieu, I like your enhancements, but I'm worried about it becoming *too* informative for new users. At a certain level of detail, it turns into a wall of text that no one reads. Like a lens, too little or too much focus is equally bad. Can we make the text at the top both pithy and communicative, without repeating details that are given in the click-through sections? We currently discuss "what you get" at the click-through. We haven't really presented "consequences", and I'm loathe to add yet another section, unless people here think otherwise. This is just the download page, after all. It's not meant to be an in-depth presentation of each option's pros and cons. Those capable of following such a discussion would probably not go to the download page to find it. John
Hi John,
agreed, overdoing the downloads page is certainly a risk. And the
added text does cover ground that is expanded on in the click-through
sections. My concern is that as things stand, I find it unlikely that
a new user will grok the subtleties of going for one option rather
than the other. Summarizing the trade-offs (which I think by this
point no one is disputing) right at the top should help the user
_understand how to weigh his/her options_. I think it's not a problem
if some info ends up being repeated: few users will be reading the
entire Downloads page top-to-bottom (already 5.5 screen-fulls over
here!).
Without the tradeoffs explained pithily at the top, as as new user, I
go the downloads page and I see that e.g. HP gives me plenty that I
probably want. Sounds good to me! :) The page tells me that Stack
gives me "the capacity to download and install" the same thing too,
rather than that happening out-of-the-box. That doesn't sound very
compelling. Why wouldn't I want everything just there from the get-go?
Turns out there are good reasons why at this point you probably
_don't_ want to be using the HP if you want to hack on multiple
projects at once, reason being simply that HP assumes all projects can
make do with a shared instance of the exact same versions of the
libraries and tools that it ships with, when this assumption does not
hold true in practice (again, in the future this may change).
On 25 September 2015 at 02:30, John Wiegley
Boespflug, Mathieu
writes: this is a nice summary of all options. May I suggest the following refinements to the summaries:
Hi Mathieu,
I like your enhancements, but I'm worried about it becoming *too* informative for new users. At a certain level of detail, it turns into a wall of text that no one reads. Like a lens, too little or too much focus is equally bad.
Can we make the text at the top both pithy and communicative, without repeating details that are given in the click-through sections? We currently discuss "what you get" at the click-through. We haven't really presented "consequences", and I'm loathe to add yet another section, unless people here think otherwise.
This is just the download page, after all. It's not meant to be an in-depth presentation of each option's pros and cons. Those capable of following such a discussion would probably not go to the download page to find it.
John
Boespflug, Mathieu
writes:
Without the tradeoffs explained pithily at the top, as as new user, I go the downloads page and I see that e.g. HP gives me plenty that I probably want. Sounds good to me! :) The page tells me that Stack gives me "the capacity to download and install" the same thing too, rather than that happening out-of-the-box. That doesn't sound very compelling. Why wouldn't I want everything just there from the get-go? Turns out there are good reasons why at this point you probably _don't_ want to be using the HP if you want to hack on multiple projects at once, reason being simply that HP assumes all projects can make do with a shared instance of the exact same versions of the libraries and tools that it ships with, when this assumption does not hold true in practice (again, in the future this may change).
Ok, you and Simon have a good point, we need more readily visible guidance on choice selection. I'll try to incorporate your changes as briefly as I can. John
Hello Haskell.org committee,
On Thu, Sep 24, 2015 at 7:20 AM, John Wiegley
The plan is to add Stack to the Platform, and render the Platform minimal, which will
consolidate this page down to a single, recommended download path.
The Haskell Platform includes Stack now, and comes in a minimal variant, but the downloads page [1] still lists 3 different download options (4 if you count platform classic). Do you still plan to recommend just a single download path at some point? Thanks, Thomas [1] https://www.haskell.org/downloads
There was some discussion within the committee of dropping the minimal installers from the page the other day. However, stack-only does appear to remain a fairly popular download option. I feel if we ever hope to heal the haskell-lang rift that removing the stack option at this time would be actively harmful. -Edward
On Jul 12, 2016, at 10:07 AM, Thomas Miedema
wrote: Hello Haskell.org committee,
On Thu, Sep 24, 2015 at 7:20 AM, John Wiegley
wrote: The plan is to add Stack to the Platform, and render the Platform minimal, which will consolidate this page down to a single, recommended download path. The Haskell Platform includes Stack now, and comes in a minimal variant, but the downloads page [1] still lists 3 different download options (4 if you count platform classic). Do you still plan to recommend just a single download path at some point?
Thanks, Thomas
[1] https://www.haskell.org/downloads
_______________________________________________ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
participants (21)
-
Adam Foltzer -
Alan & Kim Zimmerman -
Boespflug, Mathieu -
Bryan Richter -
Christopher Allen -
Edward Kmett -
Francesco Ariis -
Ganesh Sittampalam -
Gershom B -
Greg Hale -
Jason Dagit -
John Wiegley -
Kostiantyn Rybnikov -
M Farkas-Dyck -
Michael Snoyman -
Randy Polen -
Richard Eisenberg -
Roman Cheplyaka -
Simon Marlow -
Simon Peyton Jones -
Thomas Miedema