> Gershom B <gersh...@gmail.com>: > On March 24, 2015 at 8:14:27 PM, Manuel M T Chakravarty > (c...@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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
