wither the Platform

[Carter Schonwald]

I absolutely agree that haskell platform is the right choice for class
rooms.
On Mar 24, 2015 8:14 PM, "Manuel M T Chakravarty" <chak at cse.unsw.edu.au>
wrote:

> > Duncan Coutts <duncan.coutts at googlemail.com>:
> > On Sat, 2015-03-21 at 10:54 -0700, Mark Lentczner 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
> 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 at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150324/0fdc98b5/attachment.html>