From chak at justtesting.org Tue Nov 10 11:13:21 2015 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 10 Nov 2015 22:13:21 +1100 Subject: [Haskell-community] Downloads page & Haskell for Mac In-Reply-To: References: Message-ID: <83255B78-1715-4AB6-AEAB-EEE57B28D40E@justtesting.org> John Wiegley : > >>>>>> Manuel M T Chakravarty writes: > >> Other than that, isn?t it the purpose of haskell.org to make it as easy as >> possible to get up and running with Haskell? From all the feedback that I >> got from users so far, Haskell for Mac is by far the easiest way to get >> started with Haskell on a Mac. If we are up front about its commercial >> nature, visitors to the site can decide for themselves whether the purchase >> costs and the commercial nature are worth the added convenience to them. > > Hi Manuel, > > We still have the problem that the current downloads page is quite long. Since > I can't see replacing one of those options with Haskell for Mac, that only > leaves adding a fourth option -- which begs the question why other perfectly > viable options are also not there. At some point, we have to draw a somewhat > arbitrary line. To be honest, I didn?t want to restart a discussion about the rest of the downloads page, but maybe that is inevitable. I totally agree that the current downloads page is quite long. In fact, it is much too long. It is so long that I?m not sure who the target audience is supposed to be. Head over to python.org https://www.python.org and hover over ?Downloads?. Without even going to a separate page you get a popup that immediately presents you with two options specific to the OS you are running (choosing between Python 2.x and Python 3.x). Then, to the left of that is a menu with other options if you are enough of an expert to want to explore the available options further. (If you click on ?Downloads?, you go to a page that also has the two download options right at the top and then more details below, which you can happily ignore.) That?s it. That?s how a good download section looks like. Why do we even have three options?[1] To somebody new to Haskell, these options are essentially the same. A newcomer doesn?t have the information to make a meaningful choice at this stage. Hence, you create confusion. I realise that some of you put quite some effort into this page and I am sorry if this sounds harsh, but please try to look at it from the perspective of somebody who is new to Haskell. They have one goal: be able to write some Haskell code with as little upfront effort as possible. They don?t care about differences in package management and what not. (It?s not just that they don?t know about it, they don?t want to learn about it!) There is of course a place for describing the difference between the three types of installations, but that?s somewhere deep down in the section for experienced users who want to fine-tune their environment. Let me give you one more datapoint. I have run lots of university courses teaching Haskell. I have been bombarded by students questions about installation problems semester after semester. Now, would I point my students to the current downloads page? No ? because it would drastically increase the number of problem reports I get. (I typically write my own downloads page specifically for the course, because the community-supplied ones are too confusing.) So, what to do? There can only be *one* installation option and that should query the browser info to preselect the download for the user?s OS. Then, in addition to that one canonical download, there can be a list of options, maybe sorted by OSes or by CLI vs GUI or some other dimension that is meaningful to somebody who is unfamiliar with the Haskell tool chain. > In our "third party downloads" section, we could add a link to a page targeted > specifically at beginners, with Haskell for Mac as a prominent member of the > "Mac" section on that page. Would that suffice? Is there a ?third party downloads? section at the moment? As I wrote above, I think, the main page should have a single option with a menu (or list) of alternative categories. I don?t think ?third party? is a good label, though. Good UI design takes the perspective of the user and presents choices in terms of the information that the user possesses (and is able to use for meaningful choices). Choices that are meaningful in the mind of a newcomer looking for a way to use Haskell are, for example, * is it free or do I have to pay, and * does it have a GUI or do I have to use the CLI. > I realize you want to get the word out to those who need to hear it, and > burying the lead past a link may lose some of the audience you're aiming for. > This has to be balanced against our need to keep the community-backed options > clear and visible, and avoid additional confusion for the sake of a better > option for some. Sure. However, all the community-baked options have one disadvantage for a lot of people: you need to use the command line and get your hands dirty with configurations. This is a deal breaker for many people and it makes Haskell inaccessible to these people. It also strongly contributes to the popular opinion that Haskell is an elite language for experts. I think that this is very unfortunate. Haskell is, for example, great for teaching programming to people who have never programmed before (including children). The CLI-based ecosystem is a serious obstacle for that. Cheers, Manuel [1] This is a rhetorical question. We do have three choices for political reasons. User interface design by committee usually leads to these compromises. From gershomb at gmail.com Tue Nov 10 16:10:30 2015 From: gershomb at gmail.com (Gershom B) Date: Tue, 10 Nov 2015 11:10:30 -0500 Subject: [Haskell-community] Downloads page & Haskell for Mac In-Reply-To: <83255B78-1715-4AB6-AEAB-EEE57B28D40E@justtesting.org> References: <83255B78-1715-4AB6-AEAB-EEE57B28D40E@justtesting.org> Message-ID: On November 10, 2015 at 6:13:27 AM, Manuel M T Chakravarty (chak at justtesting.org) wrote: > > In our "third party downloads" section, we could add a link to a page targeted > > specifically at beginners, with Haskell for Mac as a prominent member of the > > "Mac" section on that page. Would that suffice? > > Is there a ?third party downloads? section at the moment? > Nope, but the proposal is to create one. People have been rather busy but ideally a draft such section should be sent out by the end of this week? Or rather, the proposal is to create a small one, and use it to point to a page on e.g. the haskell wiki that is more organized and comprehensive, but such a page also needs to be created. > As I wrote above, I think, the main page should have a single option with a menu (or list) > of alternative categories. I don?t think ?third party? is a good label, though. Good > UI design takes the perspective of the user and presents choices in terms of the information > that the user possesses (and is able to use for meaningful choices). I agree that ?third party? is not a good label. Do you have a better suggestion? ?Other installers and distributions??? ?Gershom From chak at justtesting.org Thu Nov 12 11:44:24 2015 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Thu, 12 Nov 2015 22:44:24 +1100 Subject: [Haskell-community] Downloads page & Haskell for Mac In-Reply-To: References: <83255B78-1715-4AB6-AEAB-EEE57B28D40E@justtesting.org> Message-ID: > Gershom B : > On November 10, 2015 at 6:13:27 AM, Manuel M T Chakravarty (chak at justtesting.org) wrote: > >>> In our "third party downloads" section, we could add a link to a page targeted >>> specifically at beginners, with Haskell for Mac as a prominent member of the >>> "Mac" section on that page. Would that suffice? >> >> Is there a ?third party downloads? section at the moment? >> > > Nope, but the proposal is to create one. People have been rather busy but ideally a draft such section should be sent out by the end of this week? Or rather, the proposal is to create a small one, and use it to point to a page on e.g. the haskell wiki that is more organized and comprehensive, but such a page also needs to be created. > >> As I wrote above, I think, the main page should have a single option with a menu (or list) >> of alternative categories. I don?t think ?third party? is a good label, though. Good >> UI design takes the perspective of the user and presents choices in terms of the information >> that the user possesses (and is able to use for meaningful choices). > > I agree that ?third party? is not a good label. Do you have a better suggestion? ?Other installers and distributions?? If you do insist on having just one label, then ?Other installers and distributions? is certainly better than ?third party?. However, it would be better to have a few links with meaningful labels at this point ? e.g., ?IDEs?, ?Native package managers?, ?Command line installers? and so forth. Manuel From gershomb at gmail.com Fri Nov 13 05:02:22 2015 From: gershomb at gmail.com (Gershom B) Date: Fri, 13 Nov 2015 00:02:22 -0500 Subject: [Haskell-community] Fwd: Haskell Platform Plans In-Reply-To: References: Message-ID: Dear all, As you know, Mark has passed on the Haskell Platform maintainer hat to me. I wanted to give a heads-up on current plans to keep folks in the loop. This message has three sections, first the 7.10.3 release, next the 8.0 release, and finally some general musings on fiddly details and future plans. 1) 7.10.3 The 7.10.3 release candidates have been out for windows and unix for a bit. As I understand it there is still work underway on the mac build, but that will hopefully be coming shortly. The plan is to release a new platform roughly simultaneously. This platform will work essentially as in the past, for two reasons. First, because it is the last release in the 7.10 series and should be seen like the 7.10.3 compiler as just incorporating some necessary patches rather than any serious changes. Furthermore, the future plans underway rely on a few patches to cabal which have been merged, but are not yet in any existing cabal-install release. A few packages have received minor version bumps, as follows: PACKAGE 7.10.2-a latest ------------------------------------------- case-insensitive 1.2.0.4 1.2.0.5 fgl 5.5.2.0 5.5.2.3 GLUT 2.7.0.1 2.7.0.3 GLURaw 1.5.0.1 1.5.0.2 HUnit 1.2.5.2 1.3.0.0 OpenGL 2.12.0.1 2.13.1.0 OpenGLRaw 2.5.1.0 2.6.0.0 primitive 0.6 0.6.1.0 syb 0.5.1 0.6 scientific 0.3.3.8 0.3.4.2 StateVar 1.1.0.0 1.1.0.1 A few packages were held back due to dependency issues (notably zlib) and additionally, packages shipped with ghc were held back to the versions that will be shipped with 7.10.3. 2) 8.0 We also plan to ship a new platform concurrently with the ghc 8.0 that should be released early next year. That platform will implement some long-discussed and requested changes. First, the platform already ships with msys on windows. However, it does not do so in a way that lets you, as with minGHC, install the network library directly, or for that matter install directly other libraries that use build-type configure. This is because the msys binaries don't get placed into the path, by design. The new platform will ship with a newer cabal, incorporating a patch (pull request #2480) that uses the extra-prog-path setting for build-type: configure. This should allow network and other things reliant on build-type: configure to directly cabal install. The goal for the platform on windows will be that any packages binding to msys libraries _should_ be cabal installable without hassle. If you maintain a library that you think would be a good test-case for this, please drop a line so we can work together towards this goal. Second, the default platform will be _minimal_. That is to say that it will _only_ install into the global package database those packages that are directly shipped with ghc, and not any additional platform packages. "Blessed" platform packages will however still be shipped as a "default user cabal.config" file, so in a setting where users want to work unsandboxed, their versions of platform libs will remain pegged to those chosen by the platform, should they not choose to alter their settings. In a sandboxed setting, or in the presence of a local cabal.config generated by a freeze, those constraints will be disregarded. Furthermore, it is likely but not certain that the "nix-like cabal" or "no-reinstall cabal" will be available for the 8.0 release. If this is the case, users will be able to operate in an unsandboxed environment without conflicts, as multiple instances of the same version of a package, with different dependency choices, will be able to live side-by-side. Third, the platform will ship not only with cabal-install, but also with the stack tool, so that users can choose either workflow, depending on their project or preferences. A number of people have adopted the stack tool, and many beginners have reported success with it as well, so it will be good to provide that functionality out of the box with every platform install. Time and resources permitting we would also like to ship a platform version _with_ the platform libraries prebuilt and included, as that is also a use case that some people continue to like. However, this is a secondary priority, and contingent on us getting our build infrastructure into a good enough shape to make this not too much extra hassle. I'm excited about these changes, and confident we can get their in a timespan that matches the 8.0 release of ghc. 3) Generalities As I mentioned, it would be good to have a more uniform build infrastructure. Generally, I have put out some feelers and am working towards extending the ghc nightly buildbot infrastructure to both cover more platforms and also cover more tools -- not only ghc, but cabal, the platform, perhaps haddock, ghcjs, etc. This way we can get an economy of scale and many of our core tools will be able to all share regular automated builds across many platforms. If you like CI/buildbot systems and would like to help out with this project, please reach out. Also, once we've modernized and fixed up the core platform installer tech, it would be nice to move back to the process of making the platform a good set of blessed libraries -- taking more proposals for additions to it, looking to cull libraries that are no longer widely used, etc. As part of this I intend to move the haskell-platform list off our deprecated community.haskell.org infrastructure and onto mail.haskell.org with our other active lists. Finally, I'm happy to be maintainer of the platform through this period of change and transition, but at some future point, as things get sorted out and the release process becomes more standard and mechanical, I would very much like to pass this responsibility on. I have had some nibbles of offers, but if other people want to begin to get involved, please let me know and we can start to get small contributions from you so that you can become familiar with the various tech and systems involved. The Haskell ecosystem is a team effort, a collective project, and volunteer driven. In my modest experience hacking on the various systems involved (cabal, cabal-install, hackage, the platform build, etc.) some are a bit confusing, but I have always found helpful contributors willing to explain things and review patches, and to help think about and diagnose problems. And none of the code has been as confusing as things I've had to wade through for employment-related purposes :-). So when this stuff doesn't work as well as we'd like, we can investigate together, and then put our heads together and figure out how to improve it together. Furthermore, it can be very satisfying to do so, because the impact of those improvements makes itself widely felt. I look forward to more people joining in! Best, Gershom From ekmett at gmail.com Fri Nov 13 21:18:38 2015 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 13 Nov 2015 16:18:38 -0500 Subject: [Haskell-community] Expanding the Core Libraries Committee Message-ID: At present the core libraries committee consists of 7 members: 6 regular members and one ex-officio appointment for the Haskell Platform maintainer. https://wiki.haskell.org/Core_Libraries_Committee The size of this committee was originally selected to be in line with the size of the extant haskell.org committee. During a meeting of the committee last week, we decided it is a bit too small to fulfill the function of adequately representing the broader community while still providing a sufficient institutional memory. Consequently, we've resolved to replace the current Haskell Platform maintainer appointment with 3 additional seats on the committee. This will grow the committee to 9 members. Pleased be advised, membership on the committee is a commitment to a fairly active role. For more information on some the processes surrounding the core libraries, please see the library submissions page on the Haskell wiki: https://wiki.haskell.org/Library_submissions If you are interested in self-nominating for the core libraries committee, please send an email to core-libraries-committee at haskell.org. Thank you for your time and consideration. -Edward Kmett Core Libraries Committee Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Thu Nov 19 07:53:42 2015 From: gershomb at gmail.com (Gershom B) Date: Thu, 19 Nov 2015 02:53:42 -0500 Subject: [Haskell-community] Downloads page & Haskell for Mac In-Reply-To: References: <83255B78-1715-4AB6-AEAB-EEE57B28D40E@justtesting.org> Message-ID: I've put together a "Distributions" page on the Haskell wiki, with the goal that the Downloads section of haskell.org can point to it: https://wiki.haskell.org/Distributions Anyone with any ideas on things to add, text to improve, or other cleanup should definitely have at editing it :-) Additionally, it would be good to whip the IDE page into much cleaner shape so we can link to it as well, if anyone wants to tackle that: https://wiki.haskell.org/IDEs Relatedly, it occurs to me that we should do something about that "Libraries" Section of the "Downloads" page. Do we want a top level "Libraries" page on haskell.org that also embeds e.g. some search boxes (for say hoogle, hayoo, and hackage) and can be more comprehensive? That would certainly feel cleaner to me... Also, I have a nagging question about how we can feature ghcjs somewhere, since it is very much "another haskell distribution" in some interesting sense. Any proposals for where it fits would be welcome. Cheers, Gershom On Thu, Nov 12, 2015 at 6:44 AM, Manuel M T Chakravarty wrote: >> Gershom B : >> On November 10, 2015 at 6:13:27 AM, Manuel M T Chakravarty (chak at justtesting.org) wrote: >> >>>> In our "third party downloads" section, we could add a link to a page targeted >>>> specifically at beginners, with Haskell for Mac as a prominent member of the >>>> "Mac" section on that page. Would that suffice? >>> >>> Is there a ?third party downloads? section at the moment? >>> >> >> Nope, but the proposal is to create one. People have been rather busy but ideally a draft such section should be sent out by the end of this week? Or rather, the proposal is to create a small one, and use it to point to a page on e.g. the haskell wiki that is more organized and comprehensive, but such a page also needs to be created. >> >>> As I wrote above, I think, the main page should have a single option with a menu (or list) >>> of alternative categories. I don?t think ?third party? is a good label, though. Good >>> UI design takes the perspective of the user and presents choices in terms of the information >>> that the user possesses (and is able to use for meaningful choices). >> >> I agree that ?third party? is not a good label. Do you have a better suggestion? ?Other installers and distributions?? > > If you do insist on having just one label, then ?Other installers and distributions? is certainly better than ?third party?. However, it would be better to have a few links with meaningful labels at this point ? e.g., ?IDEs?, ?Native package managers?, ?Command line installers? and so forth. > > Manuel >