<div dir="ltr">I started on Haskell last year and I fall in the category of "discovering it by searching on google" and learning it myself, nobody told me about Haskell and I did not even know about it before. Let me share my perspective on this issue. I can vouch for Haskell being a very high barrier to entry for casually interested and even moderately motivated people. In the long battle most people will quit before the finish line.<div><br></div><div>I assume our goal here is to make Haskell popular, successful and influential. I believe it is already highly successful in the academic community and among a relatively small community of self motivated people who are smart enough to see why it is the right choice. What we need is to make it successful among the bulk of the engineering community who usually don't care what language they use. When I mention Haskell to anyone I know of in my engineering circle, they are usually confident that I meant Pascal. I think Haskell deserves a lot better than that.<div><div><br></div><div><div>I would strongly argue that we should not target the Haskell landing or first download page for those who already know Haskell, they won't even need it. It is for those who do not know enough and want to learn more. It is for luring and then trapping people. Specifically I would say that this page should not be targeted for students or mentored learners in general. It should be targeted to self learners. If you are a student, learning Haskell as part of a course you would have an expert mentor to tell you what to do. If you are a mentor you should know enough to not need that page and if you do then you are in the self learner category anyway. If you are a self motivated person you would anyway find what you need. We need the website to lure the mass engineering community of casual users or moderately motivated self learners usually looking for a better way to solve some problem.</div><div><br></div><div>In the engineering community people have little time. Everybody is busy with their day to day work and nobody has time and motivation to put huge amount of time and effort to learn something that they do not even know whether it will be useful. The way we can lure them is by showing how easily they can solve one of their small day to day problem, using Haskell, without investing a huge amount of time. That means we need a _zero_ learning build tool. Though build tool is not the only hurdle but it is an important first step. In my opinion we should not even talk about build tool user guide for beginners, it should not be required, the tool must be intuitive enough and the help available with it must be really good. Once you graduate to advanced usage it is a different matter altogether.<br></div></div></div><div><br></div><div>Another point that I want to make is that we should list only _one tool_ on the front page. Multiple choice is an immediate psychological barrier for beginners. When the users have a choice they must decide on one out of many. So either you explain the rationale right there or they will have to search the internet for reviews etc. In any case it requires an effort to choose and has a risk of turning them off. The committee should decide on a single choice after gathering enough information on what is best. They can ask for a shootout from the competing tools if that's needed.</div><div><br></div><div>In my opinion and from my experience learning Haskell for last one year or so, stack is a pretty good choice at the moment. It fits most of the requirements of a tool which has an out of the box experience. Though it may not be perfect it seems to be generally in the right direction especially for those who want to get started quickly and effortlessly.</div><div><br></div><div>-harendra</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 1 September 2016 at 12:39, Gershom B <span dir="ltr"><<a href="mailto:gershomb@gmail.com" target="_blank">gershomb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think this is a very good point being made. We should disengangle<br>
the installer question from the “getting started” question.  Someone<br>
on reddit even proposed having two seperate pages entirely.<br>
<br>
A getting started page that promoted a stack centric workflow for<br>
beginners as a good “default path” would be reasonable in my eyes, and<br>
certainly worth discussing. Certainly if it let us lay the downloads<br>
page to rest with a single option for a minimal installer (with<br>
perhaps slightly different branding as discussed on a ticket I linked<br>
earlier — “Haskell Toolchain” or the like) that provided ghc, stack<br>
and cabal all, then I think that would be a very good way to go.<br>
<br>
That way Nicolas and others who wanted to direct people to the<br>
downloads page, and then wanted to teach them with one sort of<br>
approach would be able to do so, people who wanted to direct people to<br>
the downloads page, and teach them with a stack-based approach would<br>
be able to do so, and people coming to the site directly could<br>
immediately find a “getting started page” with a single approach that<br>
got them up and running quickly, and that approach could well be<br>
stack-oriented if that’s what people think gives the best experience<br>
for that particular use case.<br>
<br>
(Again, I give the caveat I’m speaking just for myself here, and<br>
thinking this through as an idea I’d like to hear others’ thoughts<br>
on).<br>
<br>
—gershom<br>
<span class=""><br>
<br>
On August 31, 2016 at 5:48:41 PM, Nicolas Wu (<a href="mailto:nicolas.wu@gmail.com">nicolas.wu@gmail.com</a>) wrote:<br>
> Hi Paolo,<br>
><br>
> On Tue, Aug 30, 2016 at 1:53 PM Paolo Giarrusso<br>
</span><div><div class="h5">> wrote:<br>
><br>
> > > The decision about how to manage projects and their dependencies should<br>
> > be<br>
> > > open and isn't for beginners, whether that be using stack or cabal: both<br>
> > > have their merits, and I don't want to push one over the other.<br>
> ><br>
> > I'm honestly confused what you're arguing. You say this decision isn't<br>
> > for beginners, yet you propose offering the HP. So how should a<br>
> > beginner install a package without first deciding whether to use<br>
> > cabal-install or stack? Or can a beginner meaningfully be expected to<br>
> > learn using both alternatives?<br>
> ><br>
><br>
> Sorry for not being clear, my bad. Hopefully I can clarify and elaborate a<br>
> bit more.<br>
><br>
> I think a beginner doesn't usually make the choice of how to use<br>
> GHC/stack/cabal by themselves; they are usually being instructed by someone<br>
> (or a resource) that has decided that for them. On that front I don't think<br>
> there's a singular best way to approach this; there's diversity in the way<br>
> people approach teaching and that's fine and healthy, there's also<br>
> diversity in the way people learn and the goals they have with the language<br>
> and that's fine and healthy too. We should be supporting people who want to<br>
> learn the language as well as people who want to contribute to teaching. We<br>
> should respect diversity in those roles; if someone wants their students to<br>
> use only stack then by all means they can do so, that shouldn't stop others<br>
> from using ghc or ghci directly.<br>
><br>
> For instance, if a beginner is just trying to run small examples they see<br>
> on a blog, then maybe all they need is a call to ghci. If they're learning<br>
> about making a simple binary they might want ghc. If they want to have a<br>
> whole managed project, perhaps they're after either stack or cabal. The<br>
> point is that they're usually guided by something, and those guides do<br>
> differ on what they prefer and recommend. The default download should<br>
> easily support these different modes of learning and teaching.<br>
><br>
><br>
> > Also, do both tools have their merits *for beginners*? We're talking<br>
> > of cabal as-is, not of the ongoing work on new-build.<br>
> ><br>
><br>
> I'm talking about having a default that bundles tools like ghc, cabal, and<br>
> stack, since these are the main tools our community has for compiling and<br>
> executing Haskell code. I don't want to force people into one of<br>
> these--whether that be students or educators. In all cases the default<br>
> download recommendation should support all of these since they are the<br>
> mainstream tools we use. To avoid confusion I think there should be only<br>
> one recommended option on the main download page (and here the HP minimal<br>
> seems to satisfy this, and stack seems to preclude this). The download page<br>
> should also have a link to other resources (such as the HP Full, stack<br>
> only, and other distributions like Haskell for Mac) on another page.<br>
><br>
> Since there seems to be confusion about how the committee comes to a<br>
> consensus I should note that at this point I'm only speaking for myself<br>
> here. This is just my recommendation, and I'm open and willing to listen to<br>
> other views before considering what I think is best. I am not usually<br>
> overtly vocal in these discussions, but I do read what is said and form my<br>
> own opinions.<br>
><br>
> Best wishes,<br>
><br>
> Nick<br>
</div></div>> ______________________________<wbr>_________________<br>
> Haskell-community mailing list<br>
> <a href="mailto:Haskell-community@haskell.org">Haskell-community@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>community</a><br>
><br>
______________________________<wbr>_________________<br>
Haskell-community mailing list<br>
<a href="mailto:Haskell-community@haskell.org">Haskell-community@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>community</a><br>
</blockquote></div><br></div>