Notes from "Haskell takes over the world" BoF at ICFP
Here are the notes transcribed from the Future of Haskell BoF held after the Haskell Symposium last week. -- Don = Future of Haskell BoF Notes = A "birds of a feather" meeting was held at ICFP, organized by Bryan and Johan. We had 30 (?) people in a room, for 2 hours, discussing how to ensure Haskell succeeds. These are the transcribed notes. == Libraries == * Need to encourage special interest groups (SIGs) to form around particular domain areas in the libraries. AI, BioInf, Networking, etc. * Document the SIG process: what resources they have, how you get results. * Missing SIGs for certain platforms: Mac, CentOS etc. * More tutorials on use of Haskell in particular domains. * Keen for Hackage 2.0 quality review tools: embedded wikis, voting * Hackage analysis tools: reverse indexing of the code base. * There is no PVP tool. * Library fragmentation occuring due to type duplication (String, Text, ...) * Focus on intitiatives for common, core types. HP polish. * What is the "Son of Containers" going to be? * Build reports would help the community a lot. Integrated with Hackage. Haddock pages on hackage should be editable wikis (per-top-level function, dvcs backed? record history, captchas. roll back spam, by default assume good contributions) * Need to register patches to packages with lost maintainers. * Belgium Hackathon coming up. * Improve libraries process: esp. for small contributions. * Hackage maintainance: + maintainer timeout. + hackage package clobbering. + tweaks. hackage-local .cabal fixes. * Unclear what the rules for contributing are. Document them! * In particular, document how to contribute to: * ghc * cabal * core and HP * hackage * dockathon == IDEs == * A new ghci. + scriptable, scion-server? + repls on top of ghc-api + ruby repl + .ghci + documentation + hpaste/ghci. * IDE + scion. contributions. market places. + documentation. + EclipseFP, scion? + NetBeans. * Special Interest Groups + as the vehicle for domain projects. + formal process for forming a group. + a small amount of structure for groups + document process for forming a strike team. * haskell.org + polishing the wiki. + wikibooks. + call for sig. * haskell visual design group? + consistent color themes across haskell.org sites. + consistent haskell branding. * community server mailing lists in poor state * Move community more online ? Community services. + google groups + digests. + reply at the right point in the threads. + serious lists. + ghc users. libraries. + announces. + stackoverflow for new questions? + keep refering to SO. + reddit for news? == GHC == * ghc status + 50% split in room on moving ghc from darcs to git. + bug reports and interaction load with ghc + well documented workflow for lightweight changes + heavy weight process for major work. + bugs, tickets. + Simon Marlow "contributions are going up, and process is working well" * Release schedule. + RC at ICFP. + GHC release page. + HP/GHC release. + stage releases. + more clearly announced that ghc will be a beta prior to GHC HP. * HP, uses GHC installers as is. GHC zip. == Teaching / tutorials == * Tutorials. Documentation. + Writing a blog post that is wrong is a pretty good way to get feedback. + Find a forum to ask the question, so the answer is findable. + Ask on SO. + Clojure and Scala communities have active blog spheres. + they love descriptions of data structures + e.g. high fanout trees. + Aggregating the ephemera. + Archives: Haskell Reddit has all the interesting blog posts. -- Haskell Wikibook. * Cabal and integration with other languages. + Easier integration with C. + Higher barrier to entry on the Mac. + Playing well with other languages?
A big thank you, by the way, to you, Simon Marlow, Malcom Wallace and
everyone who helped getting the videos online and those that gave
talks at the Haskell Implementors' Workshop 2010. It was exciting to
watch all the videos! There was a lot of interesting and fertile
discussion.
On 6 October 2010 21:10, Don Stewart
* Library fragmentation occuring due to type duplication (String, Text, ...)
This one is a big issue for me personally. On hpaste[1] I spent some time converting between String/Text/ByteString/Lazy-ByteString and did not have fun.
* Belgium Hackathon coming up.
See you there!
* A new ghci. + hpaste/ghci.
What were the ideas regarding hpaste? Creating a REPL for pastes?
* IDE + scion. contributions. market places. + documentation. + EclipseFP, scion? + NetBeans.
I am personally interested in scion. I have the Emacs chops to hack on that. So far I've been making one-off scripts but it seems like ultimately the best approach is to focus on using scion to make Emacs a real quality Haskell environment -- and resulting contributions to Scion can only benefit other IDEs. Phyx- from the IRC has been working on some fairly advanced features for Haskell Visual Studio, for those interested.
* haskell.org + polishing the wiki. + wikibooks. + call for sig.
I am looking forward to having the new Haskell.org wiki[1] rolled out. I and Michael Snoyman have been working on cleaning up the web development area of the wiki[2]. We really want to make it a central and useful place for current information on web. dev in Haskell. [1]: http://new-www.haskell.org/haskellwiki [2]: http://www.haskell.org/haskellwiki/Web
* haskell visual design group? + consistent color themes across haskell.org sites. + consistent haskell branding.
Can we get real web designers on this? Has a colour theme / logo incarnation been decided yet? Should we make a poll with proposals? I might whip up a simple web app for posting proposal text + image attachments and allowing people to vote, if I can't find an existing one. At least if the choices are static Google Docs suffices for this and makes it easy to ask the community something. At the moment I'm still clinging to the old colour theme of purple and green[3][4], I like this theme but I'm open to switching both of these web sites to a new theme if we have a consistent, re-usable stylesheet, palette and SVG logo. I think a consistent theme is very important. Domains are also possibly important, too... Haskell.org, hackage, haddock, Planet Haskell, hpaste, tryhaskell, Hoogle, Hayoo, the soon-to-be Haskellers.com, etc. I think all these sites that are really part of the Haskell web network and should have a consistent theme and quick way to get "home" to Haskell.org. Imho I suppose it might be great to also have domain consistency, e.g. haskell.org, hackage.haskell.org, paste.haskell.org, try.haskell.org, hoogle/hayoo.haskell.org, planet.haskell.org, etc. We already have a few of these in use. Digressing a little, can anyone interested in doing so merge hoogle and Hayoo and make them part of Hackage? I plan on making a complete interface to the #haskell IRC channel with browsing, full text search, stats, common links, "marking" of interesting conversations, top posted links, active hours, etc. basically what pisg provides but... utilizing IRC as a real source of community knowledge and activity and not just a statistical curiousity. What I think would be neat but probably won't happen is irc.haskell.org, but I can always put it on hsirc.org or something. hpaste.org will interface with this site to provide context for pastes, e.g. when I'm viewing a paste, I should see maybe ten lines of conversation and a link to view more, so that I can see what the paste was about. I think both hpaste and the IRC channel are untapped sources of information and I intend on making these two sites utilise that information. I recently imported the last ten years' worth of IRC into a postgresql database[5]. I used the clogparse library[6]. For a bit of fun here's the top-ten Haskell chatters ever: amelie=> select count(*),nick from ircevent where type = 'talk' group by nick order by 1 desc limit 10; count | nick --------+------------- 643917 | lambdabot 265466 | Cale 248069 | dons 224690 | shapr 139449 | quicksilver 88745 | SamB 81229 | ski 75148 | Pseudonym 73043 | dcoutts 72337 | ivanm (10 rows) [3]: http://tryhaskell.org/ [4]: http://hpaste.org/ [5]: If anyone's interested in the dump, I have uploaded it and can email you the link. It's 174MB lzma-compressed and 900MB uncompressed. [6]: http://mainisusuallyafunction.blogspot.com/2010/09/clogparse-parsing-haskell...
+ stackoverflow for new questions? + keep refering to SO.
Does this suggest that I should first direct my Haskell technical questions to SO rather than Haskell-Cafe?
+ Simon Marlow "contributions are going up, and process is working well"
Great to hear! I have a small GHC issue I'd like to fix one weekend. I want to get the t-shirt! "I contributed to GHC and all I got was this lazy... "
* Cabal and integration with other languages. + Higher barrier to entry on the Mac.
Is this the general experience? I installed the Haskell Platform on OS X and compiled all my projects without problem. It was quite surreal, I expected there to be loads of issues but everything just worked. I used mac ports for the C dependencies (e.g. libcurl or fastcgi). I don't think Gtk would work if I tried, but that's an issue on Windows too. What problems are there specific to OS X? Admittedly I do 99% of my Haskell hacking on Linux because I prefer Linux in general with XMonad and GNOME.
Hi
Digressing a little, can anyone interested in doing so merge hoogle and Hayoo and make them part of Hackage?
I am currently working on this in my spare time. I hope to have something to show in the next month. Thanks, Neil
On Wed, Oct 6, 2010 at 12:10 PM, Don Stewart
Here are the notes transcribed from the Future of Haskell BoF held after the Haskell Symposium last week.
Thanks for sending out the notes, Don! It was a very helpful and constructive session for me, to let me see some interesting opportunities for helping out the community over the coming year. I very much appreciate all that people had to say, ugly bits and all :-)
At the risk of starting a darcs vs. git discussion I have some
thoughts about the tension.
On Wed, Oct 6, 2010 at 12:10 PM, Don Stewart
== GHC ==
* ghc status + 50% split in room on moving ghc from darcs to git.
I don't see that tension resolving itself easily. VCS tools are subject to "network effects". If your friends are using VCS Foo and you want to work with them, then you adopt Foo too. It's also a part of the toolchain that people tend to have strong opinions about. One possible way to lessen the tension would be good vcs bridge tools. There have been numerous repo converter projects, some even supporting synchronization. There is already a git-svn tool. Maybe there should be a git-darcs (and a darcs-git)? If a git hacker out there wants to add darcs support to git, I'd certainly be willing to help them get started. Pushing on this a bit more, I'm fairly convinced that darcs and git are dual to each other in terms of underlying models. As such, I have some ideas on how to unify them/convert between models. Unfortunately, actually having something to use is very far off as the ideas themselves are still immature. As far as I can tell, the main reasons to vote for git: * Some people simply love git and want to use it for every project * Git is faster and/or more memory efficient for some operations (most? all?) * Github As far as I can tell, the main reasons to vote for darcs: * GHC already uses it (inertia) * The windows support appears to be more mature (I admit, this is somewhat subjective as neither has a spotless record here) * Key players, such as the Simons, prefer the darcs UI over the git UI (i.e., some people prefer darcs) * Darcs 2.x has consistently improved in robustness and efficiency over the last several years, continues to improve, and incorporates ideas from git. (there is currently an experimental 'rebase' command in the development branch of darcs) * Cherry picking Note: I didn't mention feature branches as a reason to prefer one over the other. Both darcs and git support this. Git uses in-repo branches and with darcs you can simply do a local lazy get. Some people prefer one mechanism over the other, but the point is they both support the workflow. I also didn't mention server side bare repos. I'm trying to focus on the context of what GHC should use and as Simon Marlow points out, the current darcs workflow is scaling well so it seems that the lack of darcs bare repos is not an issue at the moment. I would like to see the tension of darcs vs git for GHC reduced. I think it ultimately amounts to: Contributors need to be able to use the one they prefer, instead of being forced to use the one GHC devs use. Us haskellers could build a tool to solve that problem.
+ bug reports and interaction load with ghc
I'd love to get elaboration on this point.
+ well documented workflow for lightweight changes + heavy weight process for major work. + bugs, tickets. + Simon Marlow "contributions are going up, and process is working well"
That's reassuring. Is their workflow documented for the benefit of other Haskell projects and the greater FOSS community in general? Thanks, Jason
On 07/10/2010 02:45, Jason Dagit wrote:
+ well documented workflow for lightweight changes + heavy weight process for major work. + bugs, tickets. + Simon Marlow "contributions are going up, and process is working well"
That's reassuring. Is their workflow documented for the benefit of other Haskell projects and the greater FOSS community in general?
We have pretty extensive instructions on how to contribute to GHC here: http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions If you find anything missing, or something that could be improved, please let us know! Cheers, Simon
participants (6)
-
Bryan O'Sullivan -
Christopher Done -
Don Stewart -
Jason Dagit -
Neil Mitchell -
Simon Marlow