Re: [Haskell-community] Civility notes (was "Traversable instances for (, , ) a b")
+1 for a CoC, for the reason that written guidelines are easy to point someone to rather than reiterating the same guidelines in different ways every now and then. However, it should be very succinct. Though these are pretty much common sense guidelines, some of us need to be sensitized towards them. -harendra On 5 April 2017 at 23:38, Jack Hill wrote: > On Wed, 5 Apr 2017, amin...@gmail.com wrote: > > I'm also +1 to a CoC, although have less of an opinion on what shape it >> should take. CoCs are an effective way of making people who may feel like >> outsiders to a community feel >> more welcome. The Haskell community is amazing and inclusive but not the >> most diverse, and projects which are doing better on that front largely all >> have CoCs. >> >> In terms of what shape it takes: there are lots of off-the-shelf ones for >> different needs: I'd suggest picking one of them. >> >> Tom >> > > +1 to a CoC. My sentiments almost exactly mirror Tom's. > > In addition, one thing that I really like about the Python community is > that in addition to a CoC, which I see as a means document (i.e. it is by > adhering to the CoC that we create the community that we want), they also > have a diversity statement, which I see as an ends document (i.e. an > aspirational statement about what the community we want should be). I > encourage us to adopt a similar approach. In fact, I imagine that > eventually we would have multiple means of working towards our ends; in > addition to a CoC, we could have, for example, policies to promote respect > and inclusivity in our Summer of Code projects. > > Best, > Jack > > [0] https://www.python.org/community/diversity/ > > ___ > 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
Re: [Haskell-community] Standard package file format
On 17 September 2016 at 03:43, Herbert Valerio Riedel wrote: > > I'm not sure if this has been pointed out already, but beyond turning a > proper grammar into a stringly-typed one, shoehorning some features of > .cabal files into YAML syntax really appear like a case of the "Genius > Tailor"[1], e.g. consider the `hpack` example > >when: > - condition: flag(fast) >then: > ghc-options: -O2 >else: > ghc-options: -O0 > > I agree. Supporting conditionals with YAML looks hacky! -harendra ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Re: [Haskell-community] [Haskell-cafe] Standard package file format
On 16 September 2016 at 16:51, Paolo Giarrusso wrote: > > I agree "full-fledged build system" is not a possible immediate goal. > But an EDSL for expressing cabal projects (as they are today) would > still be in scope of your proposal—and I thought you liked the idea > (see quote below). Using the earlier options: option 3 is not in scope > of this thread, but option 2 is, with the only danger that the design > space is so big to present a challenge. > Yeah I like the idea of using Haskell for configs but perhaps in a different problem space e.g. in a build spec. See the quote from my earlier quote below, sorry for the confusion :-) Yes, maybe option 2 might work for package specifications but sounds pretty hairy to explore for this use case alone, unless we have other motivations. > Quoting from Harendra Kumar's earlier mail: > > If we have to express not just a package specification but a > sophisticated build configuration, we need a real language. Expressing > conditionals, reuse etc becomes a compromise in a purely declarative > language. > -harendra ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Re: [Haskell-community] [Haskell-cafe] Standard package file format
This seems to have gone into a different direction. The original point was about the package specification format and not expressing a full fledged build system. That is an entirely different ballgame. The main point of the thread was whether it makes sense to use a single specification format for both stack and cabal install (YAML vs .cabal and then TOML came into picture). Haskell does not seem to be a choice for a package specification format unless we have a very different goal in mind. -harendra On 16 September 2016 at 16:08, Paolo Giarrusso wrote: > On 16 September 2016 at 12:13, Patrick Pelletier > wrote: > > On 9/16/16 2:36 AM, Paolo Giarrusso wrote: > >> > >> (Resending from right address) > >> > >> We're talking about *three* options: > >> 1. syntax for pure Haskell values, which I'll call HSON (Haskell > >> jSON). That's just an alternative to YAML/TOML/... That would need > >> extensions to allow omitting optional fields entirely. > >> 2. a pure Haskell embedded domain-specific language (EDSL) that simply > >> generates cabal description records (GenericPackageDescription > >> values). That would allow abstraction over some patterns but not much > >> more. But that alone is already an argument for EDSLs—the one Harendra > >> already presented. > >> 3. a Haskell embedded domain-specific language (EDSL) designed for an > >> extensible build tool, like Clojure's (apparently), SBT for Scala or > >> many others. That would potentially be a rabbit hole leading to a > >> rather *different* tool—with a different package format to boot. That > >> can't work as long as all libraries have to be built using the same > >> tool. But stack and cabal are really about how to manage package > >> databases/GHC/external environments, while extensible build tools are > >> about (a more powerful form) of writing custom setup scripts. I > >> suspect some extensions might be easier if more of the actual building > >> was done by the setup script, but I'm not sure. > > > > > > Options 2 and 3 both require running Haskell code at build time. > > > But if all packages had to use the new EDSL, then cross-compilation > would essentially become impossible. > > "All packages migrate to new format" doesn't seem really a plausible > option, as I already hinted in the text you quote. > There are multiple JVM build tools because they're interoperable (like > cabal-install and Stack): each library picks its own build tool, but > they can still be linked together. > Hpack generates cabal files, stack reuses cabal or hpack files. > > In principle, option 2 just needs a non-cross-compiled program to > produce a package description—say by producing a cabal file. You just > need to runghc it, either via ghci or by compiling and running a > binary. Option 3 can be trickier depending on details, but the as long > as you account for cross-compilation in the design it should be > doable. For Template Haskell the problem is deeper (see > http://blog.ezyang.com/2016/07/what-template-haskell-gets- > wrong-and-racket-gets-right/), > so let's *not* use it here. > -- > Paolo G. Giarrusso - Ph.D. Student, Tübingen University > http://ps.informatik.uni-tuebingen.de/team/giarrusso/ > ___ > 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
Re: [Haskell-community] [Haskell-cafe] Standard package file format
The discussion originated in an earlier thread from a question about the possibility of using the same format across different tools, cabal and stack which currently use different file formats. If they have to use the same format what that format should be. On 16 September 2016 at 13:54, Chris Smith wrote: > I guess the overriding question I have here is: what is the PROBLEM being > solved? I know of basically no beginners who were confused or intimidated > by the syntax of Cabal's file format. It's fairly commonplace for > beginners to be confused by the *semantics*: which fields are needed and > what they mean, how package version bounds work, what flags are and how > they interact with dependencies, the relationship between libraries and > executables defined in the same file, etc. But the syntax? It's just not > an issue. I'm not sure what it means to say that people have to "learn" > it, because in introducing dozens of people to building things in Haskell, > I've never seen that learning process even be noticeable, much less an > impediment. > > With this in mind, a lot of the statements about these various languages > are not entirely convincing. That it's a superset of JSON? It's not clear > why this matters. A psychological impression of complexity? Just not > anything I've seen evidence of. Indeed, aside from the rather painful > many-years-long migration, the *cost* (though certainly not a prohibitive > one) of moving to something like YAML or TOML is that they have a bit > louder syntax, that demands more attention and feels more complex. > > There is one substantial disadvantage I'd point out to the Cabal file > format as it stands, and that's that it's pretty non-obvious how to parse > it, so we will always struggle to interact with it from automated tools, > unless those tools are also written in Haskell and can use the Cabal > library. That's a real concern; pragmatic large-scale build environments > are not tied to specific languages, and include a variety of ad-hoc > third-party tooling that needs to be integrated, and Cabal remains opaque > to them. But that doesn't seem to be what's motivating this conversation. > > On Thu, Sep 15, 2016 at 11:20 PM, Harendra Kumar > wrote: > >> I am starting a new thread for the package file format related discussion. >> >> From a developer's perspective, the major benefit of a standard and >> widely adopted format and is that people can utilize their knowledge >> acquired from elsewhere, they do not have to go through and learn >> differently looking and incomplete documentation of different tools. The >> benefit of a common config specification is that developers can choose >> tools freely without worrying about learning the same concepts presented in >> different ways. >> >> Multiple formats flying around also create a psychological impression of >> complexity in the ecosystem for newcomers. If we have consistency there are >> better chances of attracting more people to the language ecosystem. >> >> I gather the following from the discussion till now: >> >> * We have cabal, YAML and TOML as potential candidates for a common >> package format which can additionally incorporate the concept of >> snapshots/package collections and potentially more extensions useful across >> build tools. >> >> * cabal has the benefit of incumbency and backward compatibility, it has >> shortcomings which are being addressed but it is still a format which is >> very specific to Haskell ecosystem. It is not a standard and not going to >> become one. We have to always deal with it ourselves and everyone coming to >> Haskell will have to learn it. >> >> * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A >> significant chunk of developer community is already familiar with it. It is >> being used by stack and by hpack as an alternative to cabal format. The >> complaint against it is that the specification/implementation is overly >> complex. >> >> * TOML (https://github.com/toml-lang/toml) is promising, simpler than >> YAML and is being used by a few important projects but is still evolving >> and is not completely stable. On a first glance it looks pretty simple and >> a lot of other tools use a similar config format. It is aiming to become a >> standard and aiming for a wider adoption. >> >> As a next step we can perhaps do an hpack like experiment using the TOML >> format. That way we will have some experience with that as well and get to >> know if there are any potential pro
Re: [Haskell-community] [Haskell-cafe] Standard package file format
On 16 September 2016 at 12:35, Imants Cekusins wrote: > Why not adopt (a subset of) .hs AST file format to structure both project > and package files? > Aha, that's my preferred choice. If there is a way to restrict features and we can allow just a subset we can have a nice configuration language which is a real language. In fact, I have been toying around this. If we have to express not just a package specification but a sophisticated build configuration, we need a real language. Expressing conditionals, reuse etc becomes a compromise in a purely declarative language. For example make has so many built-in functions in it that it has become a full fledged language by itself. The google bazel build uses python as the build config language. Haskell will make a much better choice for such use cases. Pure declarative is a pain for such use cases. -harendra ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
[Haskell-community] Standard package file format
I am starting a new thread for the package file format related discussion. >From a developer's perspective, the major benefit of a standard and widely adopted format and is that people can utilize their knowledge acquired from elsewhere, they do not have to go through and learn differently looking and incomplete documentation of different tools. The benefit of a common config specification is that developers can choose tools freely without worrying about learning the same concepts presented in different ways. Multiple formats flying around also create a psychological impression of complexity in the ecosystem for newcomers. If we have consistency there are better chances of attracting more people to the language ecosystem. I gather the following from the discussion till now: * We have cabal, YAML and TOML as potential candidates for a common package format which can additionally incorporate the concept of snapshots/package collections and potentially more extensions useful across build tools. * cabal has the benefit of incumbency and backward compatibility, it has shortcomings which are being addressed but it is still a format which is very specific to Haskell ecosystem. It is not a standard and not going to become one. We have to always deal with it ourselves and everyone coming to Haskell will have to learn it. * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A significant chunk of developer community is already familiar with it. It is being used by stack and by hpack as an alternative to cabal format. The complaint against it is that the specification/implementation is overly complex. * TOML (https://github.com/toml-lang/toml) is promising, simpler than YAML and is being used by a few important projects but is still evolving and is not completely stable. On a first glance it looks pretty simple and a lot of other tools use a similar config format. It is aiming to become a standard and aiming for a wider adoption. As a next step we can perhaps do an hpack like experiment using the TOML format. That way we will have some experience with that as well and get to know if there are any potential problems expressing the existing cabal files. More thoughts, opinions on the topic will help create a better understanding about it. -harendra ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack
On 16 September 2016 at 04:54, Brandon Allbery wrote: > On Thu, Sep 15, 2016 at 7:19 PM, Harendra Kumar > wrote: > >> How about cabal-install using the YAML format as hpack has proven that it >> works very well for expressing the existing .cabal files? YAML is simple, >> flexible and open, used across many tools so the knowledge of format is >> more widely sharable which has its advantages. Are there reasons to keep >> using the cabal format other than the legacy reasons and the pain of asking >> everyone to move to another format? > > > Could you explain what aspect of a format for which all code and > documentation is open source defines it as "closed" to you? > Well, I did not mean closed in that sense. What I meant was it is custom built for a very specific purpose, maybe I chose the wrong word, sorry about that. -harendra ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack
On 15 September 2016 at 19:53, Edward Z. Yang wrote: > > Well, if the "snapshot" config is put in specific file, there's no > reason why Cabal couldn't be taught to also read configuration from that > file. But if cabal-install wants it to be in "pkg description format" > and Stack wants it to be in YAML I'm not sure how you are going to get > the projects to agree on a shared format. Snapshot config is put > in cabal.project.freeze, which has the virtue of having the *same* > format of cabal.project. How about cabal-install using the YAML format as hpack has proven that it works very well for expressing the existing .cabal files? YAML is simple, flexible and open, used across many tools so the knowledge of format is more widely sharable which has its advantages. Are there reasons to keep using the cabal format other than the legacy reasons and the pain of asking everyone to move to another format? In the short run it is tempting to keep using .cabal since we do not have to manage a painful disruptive change. But that may not be so in the long run. Open technologies usually win in the long run as against the closed ones. Keeping aside the legacy knowledge advantage, we can objectively evaluate if .cabal is better than YAML or vice versa. Inputs from original stack authors might also be useful on why they chose YAML over .cabal. I guess it might be similar to the reasons why someone wrote hpack to generate .cabal from YAML. Also they were starting fresh and so did not have to manage a disruptive change. But I fear if they will be willing to go for a closed format against an open format now even if some of the problems of the format are addressed. Maintaining a closed format perennially is also an issue unless it is very well thought out and does not require any changes. -harendra ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack
While I agree that stack.yaml is a frozen config, we do not necessarily need a separate config file or a separate format for that. My main point was a that a new user will have to understand two more languages (YAML/cabal) in addition to Haskell. We can have the config spread in multiple files, but they should look like an extension of the same thing rather than disparate things. The stack snapshot config can be seen as a higher level concept of the pvp-bounds in the cabal file. While pvp-bounds specifies a whole range, the snapshot is a point in that space. It can also be seen as a more general version of the "tested-with" field in the cabal file. We can instead say - tested-with these snapshots (or set of versions). Instead of using stack-7.8.yaml, stack-8.0.yaml manually, the build tool itself can list which snapshot configs that are available and you can choose which one you want to build. The config could be tool agnostic. -harendra On 15 September 2016 at 11:36, Patrick Pelletier wrote: > On 9/14/16 7:46 PM, Harendra Kumar wrote: > >> That's good news. I think the community will benefit from a healthy >> competition among the tools. It is good to have choices in terms of the >> front end but I would rather prefer a unified specification of >> configuration. Currently with a stack workflow one has to deal with two >> config files i.e. stack.yaml and project.cabal. There is no reason why the >> stack and cabal configs cannot be unified. >> > > To me, the stack.yaml and project.cabal file serve different purposes. > The project.cabal specifies how to build a single package. Even if you > want to (try to) build that library in a very different build environment, > everything in the project.cabal is still meaningful: source files, > dependencies, license, how to run tests and benchmarks, etc. > > The stack.yaml is about an entire build environment. It is about things > that have to (of necessity) be the same for all the packages that go into > an executable: compiler version, snapshot, etc. > > In other words, a single build environment can build many packages, and a > single package can be built in many different environments. For example, in > my directory structure for developing normalization-insensitive, I have > three stack.yaml files: > > stack-7.8.yaml > stack-7.10.yaml > stack-8.0.yaml > > and I have three cabal files: > > unicode-transforms/unicode-transforms.cabal > normalization-insensitive/normalization-insensitive.cabal > photos/photos.cabal > > Each stack.yaml builds all three cabal projects. And each cabal project > can be built by any of the three stack.yaml files. So, I see them as > expressing very different concepts. > > Another point that I want to make is that I have found the cabal config >> files hard to deal with. There are a number of annoying problems with it >> and it lacks in reuse. That is the reason for tools like hpack ( >> https://github.com/sol/hpack) to be built to overcome those problems. I >> think the problems that hpack solves should be natively solved by cabal. >> > > Yes, it would be nice if cabal-the-library could learn from hpack and > solve some of the problems like redundancy. I just wouldn't want to see > fragmentation of the Haskell ecosystem. (In other words, I want to be able > to easily use any Haskell library as a dependency, even if the tools I am > using are different than the tools the package author used.) > > I guess these problems are long pending and cabal did not evolve fast >> enough. That could be one of the reasons for wrappers on top of cabal or >> competing tools like stack getting created. >> > > Well, hpack is addressing issues with the file format used by > cabal-the-library, while stack is addressing issues with > cabal-install-the-program. > > Are there any thoughts going towards a better config specification? While >> we are at it it maybe good to have an extensible config which can provide >> optional tool specific extensions. >> > > Yes, that would be very nice. > > --Patrick > > ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack
That's good news. I think the community will benefit from a healthy competition among the tools. It is good to have choices in terms of the front end but I would rather prefer a unified specification of configuration. Currently with a stack workflow one has to deal with two config files i.e. stack.yaml and project.cabal. There is no reason why the stack and cabal configs cannot be unified. The concept of frozen snapshots is generic and useful enough to be incorporated as a common specification used by all tools. If there is a unified config then the same package can be used with stack or cabal, with hackage or stackage without any problems, choose what you prefer. Another point that I want to make is that I have found the cabal config files hard to deal with. There are a number of annoying problems with it and it lacks in reuse. That is the reason for tools like hpack ( https://github.com/sol/hpack) to be built to overcome those problems. I think the problems that hpack solves should be natively solved by cabal. I guess these problems are long pending and cabal did not evolve fast enough. That could be one of the reasons for wrappers on top of cabal or competing tools like stack getting created. Are there any thoughts going towards a better config specification? While we are at it it maybe good to have an extensible config which can provide optional tool specific extensions. -harendra On 15 September 2016 at 06:12, Duncan Coutts via Haskell-Cafe < haskell-c...@haskell.org> wrote: > On Tue, 2016-09-13 at 14:58 -0400, Richard Eisenberg wrote: > > I’ve watched the recent back-and-forth about stack with quite a bit > > of interest (as many of us have). The discussion inspired me to take > > another look at stack. Here are the results of that foray. > > Since this is all being discussed now, it is perhaps worth explaining > what the cabal developers are working on and the direction they're > going. > > The cabal tool is getting a major overhaul. At this point there's a > relatively large group of people who have been "dogfooding" it in their > normal daily work for months (and for a few brave users since the > beginning of the year). > > There is a tech preview of this in the 1.24 release. The latest git > version has a user guide which explains things in more detail, and what > you can expect to work already and what is known to be incomplete > (including several temporary workarounds for missing features). > > https://cabal.readthedocs.io/en/latest/nix-local-build-overview.html > > What is broadly the same is that it still supports the "library solver- > based, work with my current ghc / environment" style that people have > mentioned in this thread. For example by default it picks up the ghc on > your path (and will automagically do the right thing if you change your > path). > > That said, the intention is also to better support a "application > frozen / package collection" style, which is the style that stack > supports well currently. > > What is new is that it does what it does a whole lot better, more > conveniently, more predictably. There's a lot fewer cases where you > have to use multiple commands to do various steps. Much of the time you > can simply ask to build/repl something, and everything else is > automatic (and quick to not do much if not much changed). It's more > predictable in that it's much more deterministic. The choices about > what versions etc are picked depend only on your environment (e.g. ghc > version), hackage snapshot and local explicit project state. In > particular it does not matter what you installed previously. (To > support the application/frozen workflows these aspects of the > environment can all be captured and frozen in a project file.) > > It also avoids the "cabal hell" issues of clashing installed versions. > Or to put it another way, it's a bit like sandboxing but without the > mental overhead or the waiting around for everything to build (because > there's automatic maximal sharing of built packages, a la nix). > > It *is* project based, but a minimal project can actually be implicit, > and most projects don't need to specify anything more than a list (or > glob) of the directories of the packages in the project. > > One of the things you were mentioning was how nice it is to just be > able to run ghc or ghci on a source file, or even without any file, > just to play around. A feature that will be landing soon in cabal- > install head is the ability to simply run ghc/ghci within a cabal > project directory and ghc will start up in the environment of the > project. No extra wrapper scripts, shell sessions or env vars > necessary. > > So the short term goal is to get all this to the stage where it can > replace the default UI in the cabal tool, and thereafter one goal is to > better support the workflow style that stack currently supports well, > ie applications with frozen / carefully change-controlled environment, > and package collections/snapshots chosen b
Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack
There are multiple ways to achieve this: 1) The env command being discussed is actually "stack exec env". Though it includes the full environment rather than stack exclusive. You can use "stack path" to print the stack exclusive environment. You can also use "stack path --" to pick specific items from that env. 2) Using "stack exec bash" is a very convenient way as suggested by Christopher Allen. 3) But I prefer to just use "export PATH=$(stack path --bin-path)" instead which only sets the PATH. The full environment (when using env or bash) also includes GHC_PACKAGE_PATH which cabal does not like. So if you want to use cabal on stack installed ghc just setting PATH works fine. I think stack has a lot of flexibility and features, in fact too many. Usually there is already a way to achieve something that you want. Though there are areas where the user experience can be made better including cosmetic stuff like not throwing confusing or unnecessary warnings. -harendra On 14 September 2016 at 01:32, Christopher Allen wrote: > I almost never (maybe twice in the last year) do this, but when I need > an environment that has Stack provided GHC-stuff in the path, I use > `stack exec my-shell`. > > > > On Tue, Sep 13, 2016 at 2:55 PM, Brandon Allbery > wrote: > > > > On Tue, Sep 13, 2016 at 3:47 PM, Richard Eisenberg > > wrote: > >> > >> Other minor points: > >> `stack env` does not work for me: my version of stack does not know how > to > >> `env` > > > > > > I think they said that was an add-in. IIRC stack is extensible with > external > > commands, in roughly the same way git is. > > > > (I am also not fond of stack, and even less fond of the politics that go > > with it, but will stick to the technical here.) > > > > -- > > brandon s allbery kf8nh sine nomine > associates > > allber...@gmail.com > ballb...@sinenomine.net > > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > > > ___ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > > -- > Chris Allen > Currently working on http://haskellbook.com > ___ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > ___ Haskell-community mailing list Haskell-community@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
Re: [Haskell-community] haskell.org download page
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. 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. 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. 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. 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. 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. -harendra On 1 September 2016 at 12:39, Gershom B wrote: > I think this is a very good point being made. We should disengangle > the installer question from the “getting started” question. Someone > on reddit even proposed having two seperate pages entirely. > > A getting started page that promoted a stack centric workflow for > beginners as a good “default path” would be reasonable in my eyes, and > certainly worth discussing. Certainly if it let us lay the downloads > page to rest with a single option for a minimal installer (with > perhaps slightly different branding as discussed on a ticket I linked > earlier — “Haskell Toolchain” or the like) that provided ghc, stack > and cabal all, then I think that would be a very good way to go. > > That way Nicolas and others who wanted to direct people to the > downloads page, and then wanted to teach them with one sort of > approach would be able to do so, people who wanted to direct people to > the downloads page, and teach them with a stack-based approach would > be able to do so, and people coming to the site directly could > immediately find a “getting started page” with a single approach that > got them up and running quickly, and that approach could well be > stack-oriented if that’s what people think gives the best experience > for that particular use case. > > (Again, I give the caveat I’m speaking j
