<p dir="ltr">I absolutely agree that haskell platform is the right choice for class rooms.  </p>
<div class="gmail_quote">On Mar 24, 2015 8:14 PM, "Manuel M T Chakravarty" <<a href="mailto:chak@cse.unsw.edu.au">chak@cse.unsw.edu.au</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Duncan Coutts <<a href="mailto:duncan.coutts@googlemail.com">duncan.coutts@googlemail.com</a>>:<br>
> On Sat, 2015-03-21 at 10:54 -0700, Mark Lentczner wrote:<br>
>> I'm wondering how we are all feeling about the platform these days....<br>
>><br>
>> I notice that in the new Haskell pages, the Platform is definitely not the<br>
>> recommended way to go: The main download pages suggests the compiler and<br>
>> base libraries as the first option - and the text for the Platform (second<br>
>> option) pretty much steers folks away from it. Of the per-OS download<br>
>> pages, only the Windows version even mentions it.<br>
><br>
> There was a big argument about this. I was on the loosing side.  :-)<br>
><br>
>> Does this mean that we don't want to consider continuing with it? It is a<br>
>> lot of community effort to put out a Platform release - we shouldn't do it<br>
>> if we don't really want it.<br>
><br>
> I think it is worth it, and the issues that people are complaining about<br>
> wrt the platform vs minimal installers can be fixed.<br>
><br>
>> That said, I note that the other ways to "officially get" Haskell look, to<br>
>> my eye, very ad hoc. Many of the options involve multiple steps, and<br>
>> exactly what one is getting isn't clear. It hardly looks like there is now<br>
>> an "official, correct" way to setup Haskell.<br>
><br>
> Right, I think there's still a great deal of value in having a simple<br>
> recommendation for new users.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Manuel<br>
<br>
> One of the points of argument was that some people were arguing that the<br>
> minimal installers are better for new users. I disagree, but certainly<br>
> there is one issue that could be fixed that'd go a long way to resolving<br>
> the particular use case with new users that was raised.<br>
><br>
>> The Platform arose in an era before sandboxes and before curated library<br>
>> sets like Stackage and LTS. Last time we set direction was several years<br>
>> ago. These new features and development have clearly changed the landscape<br>
>> for use to reconsider what to do.<br>
><br>
>> I don't think the status quo for the Platform is now viable - mostly as<br>
>> evidenced by waning interest in maintaining it. I offer several ways we<br>
>> could proceed:<br>
><br>
> Well, the people who like it don't really complain. But yes, things need<br>
> improving.<br>
><br>
>> *1) Abandon the Platform.* GHC is release in source and binary form. Other<br>
>> package various installers, with more or less things, for various OSes.<br>
>><br>
>> *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of<br>
>> "essential" libs + tools. Keeps a consistent build layout and installation<br>
>> mechanism for Haskell.<br>
>><br>
>> *3) Re-conceive the Platform.* Take a very minimal install approach,<br>
>> coupled with close integration with a curated library set that makes it<br>
>> easy to have a rich canonical, stable environment. This was the core idea<br>
>> around my "GPS Haskell" thoughts from last September - but there would be<br>
>> much to work out in this direction.<br>
><br>
> I'm not sure that slimming is really needed. But I agree with the GPS<br>
> approach. The current set is too small in the sense that it doesn't<br>
> cover lots of things people need, and the GPS approach should solve<br>
> that. We don't need to promise such high QA for the extended set, we<br>
> just need to make sure they build together.<br>
><br>
> We need to remember that one of the purposes of the platform as<br>
> originally conceived is to get people to sync on the versions of their<br>
> deps that they're using at the moment. This is where the GPS approach<br>
> shines, but it still makes sense to have some core set at the middle of<br>
> that. It's true that advanced users don't need lots of things<br>
> pre-installed, but they sill benefit from other developers synchronising<br>
> on versions of deps, so that they can have more things work together<br>
> more often.<br>
><br>
> On the argument that the platform is too big, the primary issue there is<br>
> that people want to make new sandboxes that are more minimal, and with<br>
> cabal's current behaviour of basing all sandboxes off of the global<br>
> package db, and the platform installing lots of packages globally then<br>
> we get a conflict.<br>
><br>
> But the solution is simple: make cabal sandboxes not be based off of<br>
> everything that is globally installed, make new sandboxes be really<br>
> minimal (though the ghc/platform installers could help with identifying<br>
> what is the minimal subset).<br>
><br>
> Duncan<br>
><br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>