I absolutely agree that haskell platform is the right choice for class rooms. On Mar 24, 2015 8:14 PM, "Manuel M T Chakravarty" <c...@cse.unsw.edu.au> wrote:
> > Duncan Coutts <duncan.cou...@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 > > librar...@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > ghc-devs mailing list > ghc-d...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
