I also thought about it recently. IIRC ghc can already deal with any number of stacked package dbs; we only need to expose this somehow through cabal. On 22/03/15 11:52, Herbert Valerio Riedel wrote:

On 2015-03-21 at 18:54:26 +0100, Mark Lentczner wrote:

[...]

...

The Platform arose in an era before sandboxes and before curated library sets like Stackage and LTS. Last time we set direction was several years ago. These new features and development have clearly changed the landscape for use to reconsider what to do.

[...]

...

Thoughts?

My biggest complaint about the current HP is that it pollutes the global package database with additional packages which leak into `cabal sandbox`es. This causes `cabal sandbox` to provide quite different sandbox environments for HP environments compared to a non-HP environment without those additional packages pre-installed.

Currently GHC/Cabal knows about a global package db and a user package db (the user pkg db is is what gets replaced/shadowed by cabal sandboxes). Maybe we need a 3rd package db sitting between the global and the user package db that interacts better with cabal sandboxes?

Cheers, hvr _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

I have to say that I'm quite surprised this conversation is happening at all. As far as I knew before doing some research in advance of this post, the Haskell Platform is *the* way to install Haskell on a fresh machine. It's certainly what I've relied on in getting Haskell on my machines (both MacOS 10.8). While I personally don't feel the need for the HP to have some curated set of libraries (especially now that there are other curated sets available), I do feel a strong need to have it be nice, shiny, and easy to install. At least for Mac, I don't know of a suitable replacement. I feel like we, as a community, ask a tremendous amount from our users.* By eliminating the HP, we'll be asking more from users before they're even a proper part of community. This seems like a step in the wrong direction, to me. Richard * Here are a few ways in which we ask a ton from users: - Users have to figure out which libraries to use. Many basic tasks (e.g. parsing, regular expressions) have competing packages, and it's hard to know which is appropriate. - Users have to deal with a very intricate type system. Basic libraries (like the new Prelude, `vector`, `lens`) use this complexity to their advantage, but perhaps to newcomers' disadvantage. (I'm well aware I'm, in some degree, to blame here!) - Users have to deal with long, intricate error messages. This comes hand-in-hand with the previous point. We GHC hackers try our best, but I know we fall short of the mark here. - Once a year, when the new GHC comes out, everything breaks. - Cabal hell. In return, the community gives and gives and is ever patient with newcomers. This is wonderful, and I attribute Haskell's growth to the friendliness of the community. But we should be aware of just how steep the curve is. On Mar 22, 2015, at 12:08 PM, Joachim Breitner wrote:

Hi,

Am Sonntag, den 22.03.2015, 10:52 +0100 schrieb Herbert Valerio Riedel:

...

Currently GHC/Cabal knows about a global package db and a user package db (the user pkg db is is what gets replaced/shadowed by cabal sandboxes). Maybe we need a 3rd package db sitting between the global and the user package db that interacts better with cabal sandboxes?

this would also be great for distributions, which also provide packages that should not (necessarily) in sandboxes, but are installed system wide.

Greetings, Joachim

-- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On Mar 22, 2015, at 9:40 PM, Brandon Allbery wrote:

That's interesting, because http://ghcformacosx.github.io is pretty much the only thing anyone recommends to Mac users any more, and in #haskell people seem to actively steer everyone away from the Platform in all its incarnations.

I do indeed think that this is interesting, because this thread is the first time I had ever heard of ghcformacosx. I've used Haskell on a Mac daily for several years now. I subscribe to (and read at least subject lines from) Haskell-cafe and Haskell mailing lists -- including Haskell Weekly News and HCAR -- though I'm only occasionally on reddit and very rarely look at #haskell. Besides, I run MacOS 10.8, and so ghcformacosx doesn't help me, anyway. (I installed 10.9 once upon a time. It slowed down my machine so much I preferred to reformat and roll back to 10.8, even though I was facing down a nasty deadline.) At the least, this end of the debate shows me that the community has some disagreement about what today's status quo is, an important fact to settle on before charting a course for the future. Richard

I'm sure we could do better at publicity, but your email made me wonder, so the first thing I tried was a search on haskell-café that brings up several threads with relevant subjects that mention ghcformacosx, including an HWN. http://search.gmane.org/search.php?group=gmane.comp.lang.haskell.cafe&query=ghcformacosx I believe that you haven't heard of it, but, if somebody asks about GHC on OS X, the advice is pretty consistent. It is pretty well the single-step, OS X-focused installer people ask for. All that's missing is more unified branding across different operating systems. Anthony On Sunday, March 22, 2015, Richard Eisenberg wrote:

On Mar 22, 2015, at 9:40 PM, Brandon Allbery javascript:_e(%7B%7D,'cvml','allbery.b@gmail.com');> wrote:

That's interesting, because http://ghcformacosx.github.io is pretty much the only thing anyone recommends to Mac users any more, and in #haskell people seem to actively steer everyone away from the Platform in all its incarnations.

I do indeed think that this is interesting, because this thread is the first time I had ever heard of ghcformacosx. I've used Haskell on a Mac daily for several years now. I subscribe to (and read at least subject lines from) Haskell-cafe and Haskell mailing lists -- including Haskell Weekly News and HCAR -- though I'm only occasionally on reddit and very rarely look at #haskell. Besides, I run MacOS 10.8, and so ghcformacosx doesn't help me, anyway. (I installed 10.9 once upon a time. It slowed down my machine so much I preferred to reformat and roll back to 10.8, even though I was facing down a nasty deadline.)

At the least, this end of the debate shows me that the community has some disagreement about what today's status quo is, an important fact to settle on before charting a course for the future.

Richard

Richard: The problem isn't the age itself, but rather the compatibility problems that age introduces. It can be quite difficult as a new user to get all of the libraries you want to use to play well with the platform. There's usually a way to make it work if you know what you're doing, but the platform is largely targeted at those who don't. This is particularly bad because library compatibility problems are inherently annoying to solve, or at least they feel that way to me. I think Gershom framed the problem well. From the discussion, it sounds like there are a lot of potential solutions, mostly in the category of "re-conceive the platform". On Mon, Mar 23, 2015 at 9:32 AM, Miëtek Bak wrote:

On 2015-03-22, at 15:59, Michael Snoyman wrote:

...

2. A method for installing GHC and build tools. I personally think that it makes sense to separate out this aspect of the platform from all others. MinGHC is an example of such a project: a minimal set of functionality for bootstrapping a more complete Haskell development environment. 3. Prebuilt binary package databases. As I've mentioned in the past, and others have here, there are problems with the current approach of putting the packages in the global package database. I'd personally rather see this aspect of the platform give way to more robust solutions.

...

I think a smaller task force dedicated to improving the tooling situation is the best next step, and I'd be happy to kick off such an effort with other interested individuals.

I’d be very happy to contribute to this effort. In fact, I’ve already spent some of time addressing these issues.

Halcyon already provides a method for installing GHC, cabal-install, build-tools, and other Haskell programs — on OS X, and many Linux distributions. FreeBSD and Windows are on the roadmap.

Additionally, Halcyon allows you to declare native OS libraries as build-time (or run-time…) dependencies for Haskell programs. They will be installed into a user-controlled directory, by wrapping around the native OS package manager.

Currently, this is supported on Debian-based and RedHat-based Linux distributions, which partially implements a long-standing cabal-install feature request: https://github.com/mietek/halcyon/issues/38 https://github.com/haskell/cabal/issues/571

See the Haskell Language source code for an example: https://halcyon.sh/examples/#haskell-language

See the Halcyon reference for details: https://halcyon.sh/reference/#halcyon_sandbox_extra_os_packages https://halcyon.sh/reference/#halcyon_extra_os_packages

-- Miëtek https://mietek.io

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From the downloads https://www.haskell.org/ghc/download_ghc_7_8_4 page on the GHC homepage:

Version 7.8.4 (released December 23rd 2014) Stop! For most users, we recommend installing the Haskell Platform http://hackage.haskell.org/platform/ instead of GHC. The current Haskell Platform release includes a recent GHC release as well as some other tools (such as cabal), and a larger set of libraries that are known to work together. On Mon, Mar 23, 2015 at 11:01 AM, Simon Peyton Jones wrote:

I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go:

Like Richard, I was astonished by this. I always thought that the Haskell Platform was *the* route of choice to install GHC, together with a respectable set of libraries. It’s certainly what I install on a new machine!

Let’s not forget the large but non-vocal set of ill-informed and/or would-be users, who want a simple answer to “How do I install GHC?”. It may be that the HP formula needs re-visiting, but I think it’s very important that we continue to give a very simple (click here) answer to that question.

Simon

*From:* Libraries [mailto:libraries-bounces@haskell.org] *On Behalf Of *Mark Lentczner *Sent:* 21 March 2015 17:54 *To:* ghc-devs@haskell.org; Haskell Libraries; haskell-platform@projects.haskell.org; haskell-infrastructure@community.galois.com *Subject:* wither the Platform

I'm wondering how we are all feeling about the platform these days....

I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: The main download pages suggests the compiler and base libraries as the first option - and the text for the Platform (second option) pretty much steers folks away from it. Of the per-OS download pages, only the Windows version even mentions it.

Does this mean that we don't want to consider continuing with it? It is a lot of community effort to put out a Platform release - we shouldn't do it if we don't really want it.

That said, I note that the other ways to "officially get" Haskell look, to my eye, very ad hoc. Many of the options involve multiple steps, and exactly what one is getting isn't clear. It hardly looks like there is now an "official, correct" way to setup Haskell.

The Platform arose in an era before sandboxes and before curated library sets like Stackage and LTS. Last time we set direction was several years ago. These new features and development have clearly changed the landscape for use to reconsider what to do.

I don't think the status quo for the Platform is now viable - mostly as evidenced by waning interest in maintaining it. I offer several ways we could proceed:

*1) Abandon the Platform.* GHC is release in source and binary form. Other package various installers, with more or less things, for various OSes.

*2) Slim the Platform.* Pare it back to GHC + base + a smaller set of "essential" libs + tools. Keeps a consistent build layout and installation mechanism for Haskell.

*3) Re-conceive the Platform.* Take a very minimal install approach, coupled with close integration with a curated library set that makes it easy to have a rich canonical, stable environment. This was the core idea around my "GPS Haskell" thoughts from last September - but there would be much to work out in this direction.

Thoughts?

— Mark

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On Mon, Mar 23, 2015 at 3:20 AM, Thomas Miedema wrote:

From the downloads https://www.haskell.org/ghc/download_ghc_7_8_4 page on the GHC homepage:

Alas, that warning has never been effective. But it is moot anyway: Start from the shiny Haskell.org page and see where you land!

+1 An important example of the last point is an introductory programming course using Haskell. The students will mostly have Windows and Mac laptops. Having a very simple (click here) way to get students set up with Haskell is important for such a course. On Mon, Mar 23, 2015 at 7:01 AM, Simon Peyton Jones wrote:

I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go:

Like Richard, I was astonished by this. I always thought that the Haskell Platform was *the* route of choice to install GHC, together with a respectable set of libraries. It’s certainly what I install on a new machine!

Let’s not forget the large but non-vocal set of ill-informed and/or would-be users, who want a simple answer to “How do I install GHC?”. It may be that the HP formula needs re-visiting, but I think it’s very important that we continue to give a very simple (click here) answer to that question.

Simon

*From:* Libraries [mailto:libraries-bounces@haskell.org] *On Behalf Of *Mark Lentczner *Sent:* 21 March 2015 17:54 *To:* ghc-devs@haskell.org; Haskell Libraries; haskell-platform@projects.haskell.org; haskell-infrastructure@community.galois.com *Subject:* wither the Platform

I'm wondering how we are all feeling about the platform these days....

I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: The main download pages suggests the compiler and base libraries as the first option - and the text for the Platform (second option) pretty much steers folks away from it. Of the per-OS download pages, only the Windows version even mentions it.

Does this mean that we don't want to consider continuing with it? It is a lot of community effort to put out a Platform release - we shouldn't do it if we don't really want it.

That said, I note that the other ways to "officially get" Haskell look, to my eye, very ad hoc. Many of the options involve multiple steps, and exactly what one is getting isn't clear. It hardly looks like there is now an "official, correct" way to setup Haskell.

The Platform arose in an era before sandboxes and before curated library sets like Stackage and LTS. Last time we set direction was several years ago. These new features and development have clearly changed the landscape for use to reconsider what to do.

I don't think the status quo for the Platform is now viable - mostly as evidenced by waning interest in maintaining it. I offer several ways we could proceed:

*1) Abandon the Platform.* GHC is release in source and binary form. Other package various installers, with more or less things, for various OSes.

*2) Slim the Platform.* Pare it back to GHC + base + a smaller set of "essential" libs + tools. Keeps a consistent build layout and installation mechanism for Haskell.

*3) Re-conceive the Platform.* Take a very minimal install approach, coupled with close integration with a curated library set that makes it easy to have a rich canonical, stable environment. This was the core idea around my "GPS Haskell" thoughts from last September - but there would be much to work out in this direction.

Thoughts?

— Mark

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On March 23, 2015 at 10:02:11 AM, Mark Lentczner (mark.lentczner@gmail.com) wrote:

I do too...! But follow the new Haskell.org pages like you are a user "just want to install Haskell"... you'll never end up with the Platform.

It looks like the Platform deprecated on the Haskell.org site for Linux and OS X in June , and for Windows in Jan

. *Infrastructure team:* Was there a discussion and decision to do that somewhere?

I thought the current language on the page was rather balanced? That said, the initial people working on the site strongly leaned towards recommending minimal downloads over the platform in general, and as OS X and Windows developed good minimal installers the site was updated to point to them. In the editorial process on the site we, actually worked to make sure the platform _was_ highlighted more than it had been. And every time the site has come under public review (three times thus far, at least) the issue of minimal installers vs. platform was contentious, but with the former voice dominating. Note that there remains an issue under discussion about making the presentation of the two alternatives more balanced yet: https://github.com/haskell-infra/hl/issues/55 (patches and pull requests welcome!). In any case, here is my problem. I would like us to be in a situation where we can always say “use the platform” to new users. I don’t think we are there, because new users will insist on using whatever libraries they read about as the latest and greatest, and those libraries do necessarily take care to ensure platform-compatability. (And if you tell them that straying from the platform is not for the inexperienced, they will snap at you and call you condescending, and insist they know what they are doing… shrug). Since we cannot mass-alter this sort of attitude among new users, then the next best thing would be to mass-alter the attitude among people who write not-platform-compatible libraries. But that is hard to do as well! (A “badge” on hackage for platform-compatible packages would do wonders, I think). So, in the meantime, we need to get the centralized, uniform platform installers into a shape where we _can_ uniformly recommend them. And, as I suggested, it seems to me the way to go about doing that is decoupling the “library curation” element of the platform from the “installing haskell” element. That, or ruthlessly marking packages on hackage that do not work with the current platform with a big red X :-) Cheers, Gershom

On Mar 23, 2015, at 10:27 AM, Gershom B wrote:

...

On March 23, 2015 at 10:02:11 AM, Mark Lentczner (mark.lentczner@gmail.com) wrote: I do too...! But follow the new Haskell.org pages like you are a user "just want to install Haskell"... you'll never end up with the Platform.

It looks like the Platform deprecated on the Haskell.org site for Linux and OS X in June , and for Windows in Jan

. *Infrastructure team:* Was there a discussion and decision to do that somewhere?

I thought the current language on the page was rather balanced?

That said, the initial people working on the site strongly leaned towards recommending minimal downloads over the platform in general, and as OS X and Windows developed good minimal installers the site was updated to point to them. In the editorial process on the site we, actually worked to make sure the platform _was_ highlighted more than it had been. And every time the site has come under public review (three times thus far, at least) the issue of minimal installers vs. platform was contentious, but with the former voice dominating. Note that there remains an issue under discussion about making the presentation of the two alternatives more balanced yet: https://github.com/haskell-infra/hl/issues/55 (patches and pull requests welcome!).

In any case, here is my problem. I would like us to be in a situation where we can always say “use the platform” to new users. I don’t think we are there, because new users will insist on using whatever libraries they read about as the latest and greatest, and those libraries do necessarily take care to ensure platform-compatability. (And if you tell them that straying from the platform is not for the inexperienced, they will snap at you and call you condescending, and insist they know what they are doing… shrug). Since we cannot mass-alter this sort of attitude among new users, then the next best thing would be to mass-alter the attitude among people who write not-platform-compatible libraries. But that is hard to do as well! (A “badge” on hackage for platform-compatible packages would do wonders, I think).

I don't understand this attitude. You say that neither new users nor package authors agree with your stance on the HP, so you want to force their hands. Presumably package authors know what they're doing for themselves, and the majority of evidence we have is that new users who stick with the language do not like the way the HP works https://reddit.com/r/haskell/comments/2zts44/wither_the_platform/. I understand this is not your personal preference, but is there any group whose vote would count here? The community has responded to the reality of the situation by having easy minimal installers for OS X, Windows, and Ubuntu. What is coming down the pike is integration between Stackage LTS and isolated build environments that support building programs that need specific versions of dependencies. We're not there yet, but it's coming. The common pieces needed for all concerned parties are: GHC and isolated build environments. Cabal developers, Mietek (of Halcyon), and myself (tying Nix to Cabal) are all rapidly converging on similar designs (which is very encouraging!). The shake out here will likely be cabal-install gaining some Nix-like tricks while supporting tools focus on deployment to servers. This will give us per-package build caching with the opportunity to serve binaries for everything in Stackage, without any headaches of old versions interfering with builds, and a local binary cache that fills up between LTS releases. If the question then becomes, "What's the holdup?" the answer is lack of developer hours. Finally, just to clarify, the goals of the HP, broadly stated as an installer for essential tools and a good starter set of libraries, are not in dispute. Haskellers rely on a vast number of small, focused libraries, and our compile times are nothing to brag about. The combination of those two present a challenge, so now we are tuning how something like the HP ought to be implemented. Anthony

So, in the meantime, we need to get the centralized, uniform platform installers into a shape where we _can_ uniformly recommend them. And, as I suggested, it seems to me the way to go about doing that is decoupling the “library curation” element of the platform from the “installing haskell” element. That, or ruthlessly marking packages on hackage that do not work with the current platform with a big red X :-)

Cheers, Gershom _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On Mar 23, 2015, at 1:19 PM, Gershom B wrote:

...

On Mon, Mar 23, 2015 at 11:20 AM, Anthony Cowley wrote:

I don't understand this attitude. You say that neither new users nor package authors agree with your stance on the HP, so you want to force their hands. Presumably package authors know what they're doing for themselves, and the majority of evidence we have is that new users who stick with the language do not like the way the HP works https://reddit.com/r/haskell/comments/2zts44/wither_the_platform/.

No, this is not what I said. I was explaining that it rather difficult, even if we wanted to force their hands, to imagine that we could do so. I will say that I do not share your belief that package authors know what they are doing, in general. If they did, I would imagine that nearly all packages would ensure they would work with the current platform. But getting programmers to all agree on something like that is herding cats, and all it takes is a few people saying "feh on the platform" but nonetheless producing otherwise good packages that come into widespread use to _in general_ mean that many packages which directly or indirectly want to use those dependencies must also now split off from support for the platform.

To be clear, I said that package authors know what they are doing for themselves. I don't think they inherently know what is best for beginners, hence the reddit evidence.

So I agree that people have voted with their feet, and we need to catch up to that.

In fact, it seems to me from this discussion that there are only _two_ things we need to do to make the platform the recommended install path for all platforms again:

1) Incorporate the improvements to windows builds that have been pioneered by the MinGHC project (in particular so that platform-installed windows ghc can build the network package properly, and perhaps even the GL stuff).

2) Address the problem that in a sandbox you will get a different install plan depending on your global package db. I would suggest this be done by setting a default preference of the sandbox to ignore global packages, and allow that to be overridden with an easily configurable flag or setting or the like. That way, new users can pay the longer compile price for a guaranteed-safer experience, and more experienced users can choose to use / build up a broader library of packages they can share across sandboxes.

That's a good start, but not enough. For example, Mark's latest platform build shows OpenGL taking up a lot of space. Plenty of users want to install GHC in a server-like environment where this is a waste. But then OpenGL takes a long time (and apparently many gigabytes of RAM) to build, so we'd rather not require that those who want it rebuild it for each project (I've done this, and it's a drag). Now we face the question of having different platforms for different users, which may be acceptable despite the common claim that there should be a single download so as not to burden new users with a difficult choice. Alternately, if we let our installation tools catch up to our needs, we will have an automatic way to upgrade from a minimal installation to a, say, game development environment. That is, a user says "cabal install OpenGL", and it works, makes future rebuilds of OpenGL unlikely, and doesn't interfere with a program that depends on an older version of OpenGL. We can certainly offer kits of packages for specialized needs, but the main thing is to avoid "blessing" any one set of packages such that I'm stuck with a shared global database based on which platform I downloaded back on day 1 with Haskell. I chose OpenGL as an example, but a similarly unpleasant experience awaits potential users of our various web server packages. They are big things to install, and have dependency chains that are always itching for a rumble. These packages are some of our community's best software, the old tooling should be updated to support them. Anthony

On 2015-03-23, at 18:13, Andrew Farmer wrote:

I personally just download the latest bindist from the GHC site and bootstrap cabal myself. Partly this is because my work requires me to have the latest GHC, so maybe I'm not in the HP's target demographic. That said, I would love if there was a platform that just did that (+ whatever is needed to get that to work). Maybe at the end of the minimal install, give me a choice between stackage and hackage and set the remote-repo in my cabal file appropriately.

I’m happy to say `halcyon install --cabal-remote-repo=…` does just that. See the Halcyon tutorial and reference for details: https://halcyon.sh/tutorial/#install-ghc-and-cabal https://halcyon.sh/reference/#halcyon_cabal_remote_repo -- Miëtek https://mietek.io

On Mar 23, 2015, at 10:58 AM, Christopher Done wrote:

Someone added this text:

...

Many now recommend just using a bare compiler combined with sandboxed dependencies, especially for new users. However, others prefer to start with the curated blessed set of packages in the Haskell Platform, which is available for Windows, OS X, and Linux.

Which adds choice to users ill-equipped to make choice.

Your point here is a good one. I have to confess I'm not even sure, exactly, what "combined with sandboxed dependencies" means. (Use a sandbox for every package I wish to install, bypassing `cabal install`? Use a sandbox for every package I write? Use a sandbox to write "Hello, world!"? And what about GHCi?) And I'm not a newcomer to Haskell! This is not welcoming, in my opinion. If the recommended installation mentions sandboxes, it's the wrong recommendation, and we should aim for better. Richard

Forgive me, all, for asking what many may think a silly question, but I must ask: What's wrong with the platform? One non-answer to this question: - "It's always out-of-date." This statement, while true, isn't a direct indication that something is wrong. How does its age bite? Is the GHC version too old, meaning that users can't install the packages they want? (Are there an older versions of those packages available that *do* work? If so, does cabal find them?) Or, are the packages that ship with the platform out-of-date, causing installation trouble because of high lower-bounds on other packages? My question here hints at the fact that I'm a bit old-fashioned. I generally don't mind when things are out of date, provided that I don't need the new features. Maybe I'm in the minority here, and that the majority of newcomers to Haskell feel the burning need to have the very latest release of everything. But I, personally, would rather have ease of installation and be able to get moving forward without a headache than to have the new, shiny -- especially if I know how to get the new, shiny later if I should need it. Thanks, Richard

On Mon, Mar 23, 2015 at 5:21 PM Brandon Allbery wrote:

On Mon, Mar 23, 2015 at 11:19 AM, Richard Eisenberg wrote:

...

- "It's always out-of-date." This statement, while true, isn't a direct indication that something is wrong.

"Perception is reality". The period when the Platform went without an update for over a year because we were waiting on ghc 6.8.3 did a lot to ruin the Platform's reputation.

I hate to bring this up, but it's not just a historical issue. The version of attoparsec used by the platform today forces an old version of aeson to be used (0.6.2.1). The combination of that aeson and attoparsec version is vulnerable to an incredibly severe DoS attack for specially crafted JSON strings (e.g., {"foo":1e100000000000000000000000}). In fact, just a few weeks ago I sent a private email to someone about a massive vulnerability in a service (obviously not going to point out which one). Michael

I absolutely agree that haskell platform is the right choice for class rooms. On Mar 24, 2015 8:14 PM, "Manuel M T Chakravarty" wrote:

...

...

I'm wondering how we are all feeling about the platform these days....

I notice that in the new Haskell pages, the Platform is definitely not

Duncan Coutts : On Sat, 2015-03-21 at 10:54 -0700, Mark Lentczner wrote: the

...

recommended way to go: The main download pages suggests the compiler and base libraries as the first option - and the text for the Platform (second option) pretty much steers folks away from it. Of the per-OS download pages, only the Windows version even mentions it.

There was a big argument about this. I was on the loosing side. :-)

...

Does this mean that we don't want to consider continuing with it? It is a lot of community effort to put out a Platform release - we shouldn't do it if we don't really want it.

I think it is worth it, and the issues that people are complaining about wrt the platform vs minimal installers can be fixed.

...

That said, I note that the other ways to "officially get" Haskell look, to my eye, very ad hoc. Many of the options involve multiple steps, and exactly what one is getting isn't clear. It hardly looks like there is now an "official, correct" way to setup Haskell.

Right, I think there's still a great deal of value in having a simple recommendation for new users.

Absolutely! The recurring problem with decisions like the one about the recommended installers on the Haskell front page is that they are made by power users who simply lack the perspective to understand the requirements of new users.

A minimal installer followed by half an hour of cabal install is an extremely bad way to sell Haskell to a newcomer. Sure, it is more flexible, but flexible is *bad* for newcomers.

We are using Haskell in a few courses here at UNSW. We always recommend students to use the Haskell Platform when they want to install Haskell on their own machines. It’s one download and gives them the same packages on all platforms. Anything else just leads to lots of support questions of students trying to get their installations working to do their assignments.

Manuel

...

One of the points of argument was that some people were arguing that the minimal installers are better for new users. I disagree, but certainly there is one issue that could be fixed that'd go a long way to resolving the particular use case with new users that was raised.

...

The Platform arose in an era before sandboxes and before curated library sets like Stackage and LTS. Last time we set direction was several years ago. These new features and development have clearly changed the landscape for use to reconsider what to do.

...

I don't think the status quo for the Platform is now viable - mostly as evidenced by waning interest in maintaining it. I offer several ways we could proceed:

Well, the people who like it don't really complain. But yes, things need improving.

...

*1) Abandon the Platform.* GHC is release in source and binary form. Other package various installers, with more or less things, for various OSes.

*2) Slim the Platform.* Pare it back to GHC + base + a smaller set of "essential" libs + tools. Keeps a consistent build layout and installation mechanism for Haskell.

*3) Re-conceive the Platform.* Take a very minimal install approach, coupled with close integration with a curated library set that makes it easy to have a rich canonical, stable environment. This was the core idea around my "GPS Haskell" thoughts from last September - but there would be much to work out in this direction.

I'm not sure that slimming is really needed. But I agree with the GPS approach. The current set is too small in the sense that it doesn't cover lots of things people need, and the GPS approach should solve that. We don't need to promise such high QA for the extended set, we just need to make sure they build together.

We need to remember that one of the purposes of the platform as originally conceived is to get people to sync on the versions of their deps that they're using at the moment. This is where the GPS approach shines, but it still makes sense to have some core set at the middle of that. It's true that advanced users don't need lots of things pre-installed, but they sill benefit from other developers synchronising on versions of deps, so that they can have more things work together more often.

On the argument that the platform is too big, the primary issue there is that people want to make new sandboxes that are more minimal, and with cabal's current behaviour of basing all sandboxes off of the global package db, and the platform installing lots of packages globally then we get a conflict.

But the solution is simple: make cabal sandboxes not be based off of everything that is globally installed, make new sandboxes be really minimal (though the ghc/platform installers could help with identifying what is the minimal subset).

Duncan

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Gershom B : On March 24, 2015 at 8:14:27 PM, Manuel M T Chakravarty (chak@cse.unsw.edu.au) wrote:

...

...

Right, I think there's still a great deal of value in having a simple recommendation for new users.

Absolutely! The recurring problem with decisions like the one about the recommended installers on the Haskell front page is that they are made by power users who simply lack the perspective to understand the requirements of new users.

To be clear, the current recommendations that highlight minimal installers were not made on behalf of “power users.” In fact, they were motivated by those with the most experience helping _new users_. As the discussed on various reddit threads [1], people coming to Haskell in the context of independent acquisition (i.e. not students at the fine institutions of higher learning with sufficient distinction and taste to teach Haskell) have consistently had trouble with the platform. I am here talking about people that are probably experienced programmers to some degree, but just not experienced with Haskell. If they are to be confused by things, I want them to be confused by clever types, subtle uses of laziness, and mind-blowing idioms relying on higher order functions, not confusing messages when trying to install libraries.

The first things they try to do are not write student exercises, but e.g. install Yesod, or GHCJS, or Yesod and then GHCJS, and then some package with an API binding for some webservice which has not been updated in two years and requires an old version of time, and then maybe a GUI toolkit and of course lens. They do not yet know how to vet packages and carefully manage dependencies. They do not know how to fix trivial breakages or manually change bounds. They know how to type at least three words: “cabal” “install” and “ghci”. And they do not have a professor or instructor to guide them. And, consistently, repeatedly, they destroy their package environment. And when they do so, the answer is invariably the only one that is easy to give remotely and without lots of context — wipe the package environment and start again.

The most important message for these new users is “always use a sandbox”, because that at least keeps them from destroying the full environment when they allow installations of packages that break other packages, etc. And the platform, to the extent that it changes and complicates build plans, does these users no good.

You are talking about a specific kind of new users. These new users want to install a web stack or similar — i.e., they need tons of packages. These people may be new to Haskell, but I reckon they are otherwise power users. I’m talking about somebody picking up Learn you a Haskell and wanting to write Hello World. Why should they care about sandboxes? Who cares if they mess up their installation by installing the wrong package. They can always nuke it and install it again. That’s a much simpler story. Look. I guess, I count as a power user ;) I rarely use sandboxes. They are great for a particular type of use, but you can do many things quite happily without them. (Ask SimonPJ; I reckon he doesn’t use sandboxes either.)

...

A minimal installer followed by half an hour of cabal install is an extremely bad way to sell Haskell to a newcomer. Sure, it is more flexible, but flexible is *bad* for newcomers.

I will grant this. But I will also say that a full platform install followed by a day of trying and failing to install complex combinations of dependencies also isn’t particularly inviting.

Again, I very much _want_ to be able to recommend the platform unilaterally as the “best choice nearly always”. I like the fact that it has a uniform process for releases and installers. I like that it has infrastructure and buy-in, and I remember how bad things were in the days before it. I personally always use it, and I personally (absent the network/windows issue that MinGHC solves) don’t understand why experienced users don’t always go with the platform (except, I suppose, if they are so accustomed to “sandbox everything” that they never see a payoff, or if they are now using nix, which is also an awesome approach but very much for power users still).

The mistake here is to try to make this a one-size-fits all. I honestly don’t care about a platform that is ideal for everybody. I want something that I can point newbies at that makes them happy quickly. That needs to be one download with all the packages that you need to get going included. If somebody gets sufficiently hooked on Haskell to want to start a bigger project, then they will have the patience for a more elaborate story (and wait for cabal install for a few hours to do its job). The point is that one-size-fits-all is inherently unfriendly to novices. A novice needs something simple with as few options as possible, whereas a power user wants flexibility and customisability. A minimal installer with sandboxes gives you the latter, but it comes at the expense of simplicity, which makes is unfriendly to novices.

I think Duncan’s proposals are very good. That is to say first, change the “new sandbox behavior” issue. Once we do that, the platform will be perfectly fine for the sorts of users I described above, and I would hope that changing the recommendations on the website to say so would be uncontroversial. Then, above and beyond that, and at a future date, finishing the big plans for nix-like operations, allowing the same version of package A to be built against multiple versions of package B, etc, will do away for the need for sandboxes altogether, we hope.

Well, we have got people who want to learn Haskell now and who use Haskell as part of their coursework now. Why make them wait for future work which will probably take longer than planned, needs to be rolled out, etc? I’m sorry if I’m sounding negative here. I appreciate all these efforts. However, I am quite frustrated by the recurrent argument that flexibility implies simplicity. That is true for the expert, but flexibility is a curse to the beginner. Manuel

On Tue, Mar 24, 2015 at 10:09 PM, Gershom B wrote:

There are different types of beginners, and meeting all their needs (as well as the needs of long-timers of various stripes, etc) all at once is a tricky task.

Actually, pretty much all other language systems (C++, Java(*), Python, PHP, Ruby, Scala, etc...) meet *all* users' needs, not just beginners, with one common tool set + core libs. Different users don't install different packagings of Python. There isn't a list of choices of Scala installers. I had a really long post prepared about my reasoning, but I think I'll just spare you all, and cut to the chase: *The problem is how GHC is released:* It is released as a compiler, and minimal base libs, and (strangely) with 1/2 of cabal, haddock, ghc-pkg, no other tools, and no installer. *This is an insufficient set of things for most users.* At minimum it should also have cabal-install, and the libs so many things are built on: async, mtl, text, parsec, vector, etc..., and also common tools (like happy, alex, and hscolour). You can argue plus or minus some of these, the set could be bigger or smaller, ... basically, it should be the Platform. We should consider those additional libs as frozen, and tied to the GHC release, as the base libs - because that will mean those will be the common versions people will build and test against. And they will update as frequently as GHC. (If they aren't as stable as all that, or aren't willing to be part of that release cycle and constraint, then perhaps they shouldn't be in that set!) Yes, I'm arguing that the GHC release and the Platform release should be one and the same. The vast majority of the pain I think stems from the skew between these two, and that GHC is not enough. You need something besides the GHC release. If that something isn't standard, and/or it lags the GHC release, then all the attendant problems creep in. We worked really hard last Summer to make the Platform be very quickly buildable - there is already a 7.10 RC3 Platform out (though I did it by, ahem, not following Haskell Platform procedure - and, er, well, just did it!) - I think we should just pare back the definition of the Platform, and then commit to making it be the way new GHCs are released. - Mark (*) Okay, so Java comes in three variants, but they are mostly distinguished by final deployment environment, not user type.

Yes, I'm arguing that the GHC release and the Platform release should be one and the same. The vast majority of the pain I think stems from the skew between these two, and that GHC is not enough. You need something besides the GHC release. If that something isn't standard, and/or it lags the GHC release, then all the attendant problems creep in. Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: · There are some people working on GHC itself. That is already a big job. Just getting GHC ready to release is hard. Hence the desire that Herbert mentions to strip it down as much as possible. · But a release of GHC is not adequate. No one except power users should install a GHC release. It should be a secret among the cognoscenti that a GHC release has happened. · The first sensible unit of installation (at least for a non-power user) is the Haskell Platform. It includes the tools you need (Happy, Alex, Cabal) as well as a small but useful collection of libraries. That’s why GHC’s download page explicitly says “Stop! Shouldn’t you be installing the Haskell Platform instead?”. · HP releases should therefore, in contrast to GHC releases, be widely publicised. · Moreover, a HP release should very closely follow a GHC release (though the former could occur more often), to reduce the chance that a naïve user bypasses the HP and gets GHC alone. That is what Mark is rightly working on at this very moment for GHC 7.10. We probably should work harder to reduce the lag. In this sense, the plan was always that “the GHC and the Platform release are one and the same”. I think of the HP release as the “real GHC release”. It’s just that, as an implementation mechanism, the GHC team push out the bare GHC bits, so that the HP team have something firm to chew on. So that was the plan. I still think it’s a good plan. But it clearly is not working well, and I’m hazy about why. Possible reasons: · Possible diagnosis 1. Installing HP somehow screws up the world for power users, or for a beginner who grows into a power user. Surely we can fix this! Installing HP should not get in the way. I suppose that, even if installing HP doesn’t get in the way, it might be a waste of internet bandwidth and disk space for some power users. But that is a smaller problem. · Possible diagnosis 2. We have not shared the plan as a community; that is, we have focused lots of attention on GHC releases, and little attention on HP releases. It should be the other way around. So here are the questions in my mind: · Is the original plan still good? · Is it possible to make the HP so that installing it does not get in the way of power users? So that installing it is, at worst, a waste of disk space? Personally I like the plan because it’s simple; because it usefully empowers, and splits responsibility between, two different groups (GHC and HP); and because it makes life easy for our users. Simon From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of Mark Lentczner Sent: 25 March 2015 06:22 To: Gershom B Cc: Manuel M T Chakravarty; haskell-platform@projects.haskell.org; haskell-infrastructure@community.galois.com; Duncan Coutts; ghc-devs@haskell.org; Haskell Libraries Subject: Re: wither the Platform On Tue, Mar 24, 2015 at 10:09 PM, Gershom B mailto:gershomb@gmail.com> wrote: There are different types of beginners, and meeting all their needs (as well as the needs of long-timers of various stripes, etc) all at once is a tricky task. Actually, pretty much all other language systems (C++, Java(*), Python, PHP, Ruby, Scala, etc...) meet all users' needs, not just beginners, with one common tool set + core libs. Different users don't install different packagings of Python. There isn't a list of choices of Scala installers. I had a really long post prepared about my reasoning, but I think I'll just spare you all, and cut to the chase: The problem is how GHC is released: It is released as a compiler, and minimal base libs, and (strangely) with 1/2 of cabal, haddock, ghc-pkg, no other tools, and no installer. This is an insufficient set of things for most users. At minimum it should also have cabal-install, and the libs so many things are built on: async, mtl, text, parsec, vector, etc..., and also common tools (like happy, alex, and hscolour). You can argue plus or minus some of these, the set could be bigger or smaller, ... basically, it should be the Platform. We should consider those additional libs as frozen, and tied to the GHC release, as the base libs - because that will mean those will be the common versions people will build and test against. And they will update as frequently as GHC. (If they aren't as stable as all that, or aren't willing to be part of that release cycle and constraint, then perhaps they shouldn't be in that set!) Yes, I'm arguing that the GHC release and the Platform release should be one and the same. The vast majority of the pain I think stems from the skew between these two, and that GHC is not enough. You need something besides the GHC release. If that something isn't standard, and/or it lags the GHC release, then all the attendant problems creep in. We worked really hard last Summer to make the Platform be very quickly buildable - there is already a 7.10 RC3 Platform out (though I did it by, ahem, not following Haskell Platform procedure - and, er, well, just did it!) - I think we should just pare back the definition of the Platform, and then commit to making it be the way new GHCs are released. - Mark (*) Okay, so Java comes in three variants, but they are mostly distinguished by final deployment environment, not user type.

On Wed, Mar 25, 2015 at 2:09 AM, Simon Peyton Jones wrote:

Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: ...

I still like that plan! Concrete proposal based on that and the other fine input in the responses: *Simultaneous Release:* Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in "RC" until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go "release" in the same announcement. *In fact, let's version HP with the same number as GHC!* *Pare the Platform Back:* Bring down the number of packages in the Platform, focusing on the things that everyone needs, like text and vector, etc. I reckon that about 1/3 of the packages should go. *And, make that stuff be the latest it can be at each release. *The OpenGL stuff is a hard one, since it is large, but a very big painful build if you need it. Perhaps we need server/non-server versions of the platform - but only if we can get them out on the same day. *Make sure the Platform Installers are Complete:* I don't know Windows, but if this means adding MSYS, great.. let's do it. The Mac installer has a version switching script and supports multiple installed versions already, but people didn't seem to know. There needs to be more documentation. *Make Updating the Packages in Cabal 'work':* I'm unclear on the right technical path here, but we need away for Cabal to understand that a) it can't update the stuff tied to GHC, b) it *can* update the other stuff installed from the platform, but as a cohesive set, c) it can easily (and optionally) do (b) in just a sandbox, or in the global(-ish) install. *One Web Site:* Drop the separate Platform website. Incorporate it into the lovely new Haskell one. Put all the documentation there. This certainly has implications for how we choose what is in the platform, and how we position those packages. In particular, packages in the past have been stuck at older versions because of the requirement that the transitive dependencies be added to the platform, with the support guarantee that implies. I think we'd have to change that: There are packages in the platform, like attoparsec, packages that are there because they are dependencies, like scientific, but who knows if they will be there next time! Now, normally I'm the crazy, ranty stability guy. But, I'm thinking this: It is better to have clear release points that package developers can test against, then to have the current slidey scale of different stability guarntees, on different release schedules that we have now. And, to be honest, I realize that the Haskell community "hath spoken" recently on the issue and prefers things to evolve even if the APIs change... I think we can do this if all the great volunteer talent in our community steps up. Shall we? — Mark

In general, I think Mark's proposals are the way to go. However, I know that there are many developers who will chafe under this plan. There is an inherent tension between "latest and greatest" and "batteries included." While I understand the concerns of those who are on the bleeding edge, I believe it is best for the future of Haskell to go in Mark's direction. Issues that will need to be confronted: 1. Slower release cycle: Coordinating the stability of even a streamlined Platform with a new GHC release candidate will take more time. On the other hand, this is likely to produce a more tested final GHC release. 2. Less diversity in new GHC features: The GHC developers have generally aimed new features at a future release, where the existence and stability of new features has driven their incorporation. It was assumed that the Platform would eventually catch up. If the GHC release and the corresponding Platform release are simultaneous, then some GHC features may need to be pushed out to the following release so there is time for the Platform to be adapted. 3. The GHC development process will need to become more phased: Experimentation with new features will still be encouraged, but adoption of the new features will need to be gated to correspond with what the Platform can implement. (This is really another view of issue 2.) So I would like to add to Mark's call for the developer community to "step up": The research community will need to accept a more structured deployment of their innovations. Howard ________________________________ From: Mark Lentczner Sent: Wednesday, March 25, 2015 7:24 AM Subject: Re: wither the Platform On Wed, Mar 25, 2015 at 2:09 AM, Simon Peyton Jones wrote: Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: ... I still like that plan! Concrete proposal based on that and the other fine input in the responses: Simultaneous Release: Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in "RC" until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go "release" in the same announcement. In fact, let's version HP with the same number as GHC!

Pare the Platform Back: Bring down the number of packages in the Platform, focusing on the things that everyone needs, like text and vector, etc. I reckon that about 1/3 of the packages should go. And, make that stuff be the latest it can be at each release. The OpenGL stuff is a hard one, since it is large, but a very big painful build if you need it. Perhaps we need server/non-server versions of the platform - but only if we can get them out on the same day.

Make sure the Platform Installers are Complete: I don't know Windows, but if this means adding MSYS, great.. let's do it. The Mac installer has a version switching script and supports multiple installed versions already, but people didn't seem to know. There needs to be more documentation.

Make Updating the Packages in Cabal 'work': I'm unclear on the right technical path here, but we need away for Cabal to understand that a) it can't update the stuff tied to GHC, b) it *can* update the other stuff installed from the platform, but as a cohesive set, c) it can easily (and optionally) do (b) in just a sandbox, or in the global(-ish) install.

One Web Site: Drop the separate Platform website. Incorporate it into the lovely new Haskell one. Put all the documentation there.

This certainly has implications for how we choose what is in the platform, and how we position those packages. In particular, packages in the past have been stuck at older versions because of the requirement that the transitive dependencies be added to the platform, with the support guarantee that implies. I think we'd have to change that: There are packages in the platform, like attoparsec, packages that are there because they are dependencies, like scientific, but who knows if they will be there next time! Now, normally I'm the crazy, ranty stability guy. But, I'm thinking this: It is better to have clear release points that package developers can test against, then to have the current slidey scale of different stability guarntees, on different release schedules that we have now. And, to be honest, I realize that the Haskell community "hath spoken" recently on the issue and prefers things to evolve even if the APIs change... I think we can do this if all the great volunteer talent in our community steps up. Shall we? — Mark _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On 25-03-2015 15:24, Mark Lentczner wrote:

Concrete proposal based on that and the other fine input in the responses:

*Simultaneous Release:* Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in "RC" until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go "release" in the same announcement. *In fact, let's version HP with the same number as GHC!*

What is the purpose of doing this? It's not clear to me that there's any upside, only the rather large downside of GHC HQ (and thus some of us downstreams) having to wait arbitrarily long for the HP release. The historical record for timeliness of HP releases is not encouraging. Are we just expecting that the HP will somehow magically attract more developers... which will somehow translate into more timely releases? Regards,

On 2015-03-25 at 15:24:30 +0100, Mark Lentczner wrote: [...]

Concrete proposal based on that and the other fine input in the responses:

*Simultaneous Release:* Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in "RC" until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go "release" in the same announcement. *In fact, let's version HP with the same number as GHC!*

[...] I'm a bit worried about the aspect of delaying the GHC release schedule for the sole purpose to provide the HP with more visibility, while penalising those users that have no interest to use the HP anyway. Otoh, there's usually enough time between the last RC and the actual final release, which should give the HP at least one week of time anyway w/o any active delay on GHC's end. Otoh, as soon as the new HP is released, it provides users with the perception of a new stable HP release to jump on right-away. That, however, may lead to a poor experience if the it's the first HP release for a given major GHC version as Hackage usually hasn't fully caught up by the time a GHC x.y.1 is unleashed. So if we had co-released a HP featuring GHC 7.10.1 today, there would still be enough Hackage packages not yet compatible with GHC 7.10.1 to recommend users *not* to install the release right-away. So I'm actually not sure if a simultaneous release of GHC x.y.1 w/ HP would be in the HP's best interest in terms of providing a reliable and complete development environment (which IMO requires access to Hackage, even more so if the HP is to be reduced to contain less packages) -- hvr

On Fri, Mar 27, 2015 at 10:09 AM, Mark Lentczner wrote:

But that is true of GHC as well. We need to stop having the attitude of "Platform is for newcomers / GHC is for heavyweights". It is perfectly fine to announce "GHC 7.10.1 is out - you can install it from Platform 7.10.1 which is a complete installer for your OS with core and standard libraries, and tools; or if you prefer you can get the minimal binary compiler build. As always, not all packages on Hackage will be compatible." Then our recommendations on to users on IRC are about which version is best for their needs, not "don't install platform, you won't be able to get lens to compile..."

The lens package (alongside every other package I maintain that is incurred as a dependency of lens) has very deliberately support all Haskell Platform releases for at least 3 current major GHC releases, often at great expense to the API. No offense, but I don't think lens is the culprit here. -Edward

Gershom B :

On March 25, 2015 at 12:43:22 AM, Manuel M T Chakravarty (chak@cse.unsw.edu.au) wrote:

...

Look. I guess, I count as a power user ;) I rarely use sandboxes. They are great for a particular type of use, but you can do many things quite happily without them. (Ask SimonPJ; I reckon he doesn’t use sandboxes either.)

Ironically, the only time I have had to use a sandbox was in doing work on the new Haskell homepage (it is written in Yesod). In fact, that was insufficient for some reason and I had to install hsenv as well and use that for an even “stronger” sandbox. As I have said, I also install the platform whenever possible. Believe me, you are preaching to the choir!

Then, I don’t understand why the Platform isn’t the recommended on the homepage.

...

The mistake here is to try to make this a one-size-fits all. I honestly don’t care about a platform that is ideal for everybody. I want something that I can point newbies at that makes them happy quickly. That needs to be one download with all the packages that you need to get going included. .. Well, we have got people who want to learn Haskell now and who use Haskell as part of their coursework now. Why make them wait for future work which will probably take longer than planned, needs to be rolled out, etc?

I do not understand this. The platform still exists, is still great, is not going anywhere, and as far as I can tell, is on track to become even better. You can point people at https://www.haskell.org/platform/ or you can point them at downloads.haskell.org which links to there or you can point them at www.haskell.org and tell them “the downloads page gives you options, pick the platform option.” Nobody who wants to use the platform must wait for anything.

Nobody has taken anything from you, or anyone else. Nobody wants to take anything from you, or anyone else.

I know, but look at the subject of this message (and the original post in this thread). Mark’s questions was —as I read it— do we still need the platform. Then, lots of power users jumped up and down criticising the flaws in the platform and why other approaches are better. To which I say, other approaches are better for you (plural)[1], but not to a large class of novices. That is all. Also, to reiterate, I’m arguing with you because you replied to my message. I definitely do appreciate all the effort you (and others) are putting into the homepage and infrastructure. Manuel [1] English is such an awkward language :P

We just want to recognize that this other set of users — those coming from other languages, and wanting to “from the gate” install large sets of dependencies — this set of users has grown and is growing and if we don’t want them to become frustrated and bounce off Haskell, then we need to provide resources for them too, and steer them to things that meet _their_ needs as well. They are not lucky enough to be in your class and be guided by an instructor.

If you want to patch the downloads page so that it more clearly highlights the platform option or makes clear that if you want to be a “power user” and manage lots of dependencies with abandon you may want the minimal installers, and if you want “a good, wide-ranging set of defaults to experiment and learn with” then you want the platform, or some other wording that is perhaps clearer, or anything at all like that, then there is again a ticket on the github homepage to improve the language, and pull requests are welcome. The compromise wording on the page now is just that: a compromise. I don’t even claim it to be a great one, just what was settled on. If you (or anyone) can improve it to present both sorts of installers and the tradeoffs more clearly and more simply, please do!

There are different types of beginners, and meeting all their needs (as well as the needs of long-timers of various stripes, etc) all at once is a tricky task. Again, the main advantage that students have is that they have instructors who can guide them in what they recommend to download, how to get started, etc. So, for the moment, I would argue that students are not the most fundamental target audience for that snippet of text on the downloads page. But, that does not mean the language cannot be better for students too. And I would very much like it to be!

Beyond that I don’t feel we’re discussing anything as metaphysical as flexibility or simplicity. And I don’t feel my own preferences are necessarily better or worse than others — I just want two things, as do we all I think. A) To have the best possible toolsets available for all types of users in all possible development setups, and B) To somehow condense the core of that information into an easily digestible form to help steer visitors to the Haskell homepage to the setup that is right for _them_.

As always, anybody who wants to help with this in any regard with the new homepage is welcome and invited to do so. We have plenty of open tickets and room for improvement all around, a helpful crew on the #haskell-infrastructure irc, and patches, pull requests, and new tickets are always welcomed.

Best, Gershom

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On Tue, Mar 24, 2015 at 8:20 PM, Gershom B wrote:

install Yesod, or GHCJS, or Yesod and then GHCJS, and then some package with an API binding for some webservice which has not been updated in two years and requires an old version of time, and then maybe a GUI toolkit and of course lens.

That sounds like a recipe for Cabal Hell, Platform or not!