wither the Platform

Wed Mar 25 03:20:32 GMT 2015

On March 24, 2015 at 8:14:27 PM, Manuel M T Chakravarty (chak at 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.

> 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).

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.

In the interim, I did point out an outstanding ticket [2] on the homepage to further improve and balance the current layout and wording — pull requests are always welcome! 

Cheers,
Gershom

[1]
a) Most recently, related to this discussion and linked by acowley:
http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/
b) Occasioned by the launch of the new homepage:
http://www.reddit.com/r/haskell/comments/2w3php/venerable_haskell_platform_necessity_or_product/

[2] https://github.com/haskell-infra/hl/issues/55

> 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 at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>  
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>  