--- title: Summers of Code, 2006-2013 description: A retrospective of 8 years of SoC, and lessons learned created: 2009-02-11 modified: 2017-09-22 status: finished previous: /resilient-software next: /haskell/run-length-encoding confidence: highly likely importance: 6 cssExtension: dropcaps-kanzlei ...
> A compilation of Haskell-related student projects 2006-2013, with evaluations of their usefulness to the Haskell community, thoughts on what makes a good project, and predictions for 2011-2013.
As part of Google's [Summer of Code](!W "Google Summer of Code") program, they sponsor 5-10 SoC [projects for Haskell](https://web.archive.org/web/20060517222319/http://hackage.haskell.org/trac/summer-of-code/). The Haskell Summer of Codes have often produced excellent results, but how excellent is excellent? Are there any features or commonalities between successful projects or unsuccessful ones? A retrospective review of projects suggests to me that while many of the Haskell Summer of Code projects have delivered valuable products the Haskell community was in great need of and which have since become widely adopted, a number of them have failed for what likely could have been foreseen reasons: low importance/unclear uses, and over-ambition. # Example retrospective: Debian In 2009, a blogger & Debian developer wrote [a](https://web.archive.org/web/20111109010423/http://www.milliways.fr/2009/01/20/debian-2008-where-now-1/ "Debian Summer of Code '08: Where are they now (part 1/3)") [four](https://web.archive.org/web/20111219163427/http://www.milliways.fr/2009/01/28/debian-2008-where-now-2/ "Debian Summer of Code '08: Where are they now (part 2/3)") [part](https://web.archive.org/web/20111219163434/http://www.milliways.fr/2009/02/01/debian-2008-where-now-2-5/ "Debian Summer of Code '08: Where are they now (part 2.5/3)") [retrospective](https://web.archive.org/web/20111219153333/http://www.milliways.fr/2009/02/02/debian-2008-where-now-3/ "Debian Summer of Code '08: Where are they now (part 3/3)") series on the 2008 Debian Summer of Code projects. The results are interesting: some projects were a failure and the relevant student drifted away and had little to do with Debian again; and some were great successes. I don't discern any particular lessons there, except perhaps one against hubris or filling unclear needs. I decided to compile my own series of retrospectives on the Haskell Summers of Code. # Judging Haskell SoCs [Google describes](https://web.archive.org/web/20110402234750/http://www.google-melange.com/gsoc/homepage/google/gsoc2011 "How Google Summer of Code Works") SoC as > "...a global program that offers students stipends to write code for open source projects. We have worked with the open source community to identify and fund exciting projects for the upcoming summer." [or](https://summerofcode.withgoogle.com/) > "...a global program that offers student developers stipends to write code for various open source software projects. We have worked with several open source, free software, and technology-related groups to identify and fund several projects over a three month period. Since its inception in 2005, the program has brought together over 4500 successful student participants and over 3000 mentors from over 100 countries worldwide, all for the love of code. Through Google Summer of Code, accepted student applicants are paired with a mentor or mentors from the participating projects, thus gaining exposure to real-world software development scenarios and the opportunity for employment in areas related to their academic pursuits. In turn, the participating projects are able to more easily identify and bring in new developers. Best of all, more source code is created and released for the use and benefit of all." It is intended to produce source code for the 'use and benefit of all'; it is not meant to produce academic papers, code curiosities, forgotten blog posts, groundwork for distant projects, but 'exciting' new production code. This is the perspective I take in trying to assess SoC projects: did it ship *anything*? If standalone, are the results in active use by more than a few developers or other codebases? If a modification to an existing codebase, was it merged and now is actively maintained^[The Haskell ecosystem evolves fast, and strong static typing means that a package can quickly cease to be compilable if not maintained.]? And so on. Sterling Clover argues that this is far too demanding and does not consider whether an involved student is energized by his contribution to go on and contribute still more[^sclv]; I disagree about the former, and I have not done the latter because it would be too labor-intensive to track down every student and assess their later contributions, which would involve still more subjective appraisals^[For example, how long must a student 'continue to participate/make contributions to Haskell community'? Spencer Janssen, a successful 2006 SoC student, went on to be one of the 2 main developers on the popular [Xmonad](!W) window manager, but then wound down his Haskell contributions and stopped entirely ~2009 (much to my dismay as an Xmonad developer). Is he a success for SoC?]. (Perhaps in the future I or another Haskeller will do that.) [^sclv]: From the 2011-02-11 Haskell-cafe thread, ["Haskell Summers of Code retrospective (updated for 2010)"](https://mail.haskell.org/pipermail/haskell-cafe/2011-February/089183.html): > There was some discussion of this on [Reddit](https://www.reddit.com/r/haskell/comments/fid5w/haskell_summers_of_code_retrospective_updated_for/). Below is a slightly cleaned-up version of my comments there. > > I really appreciate this roundup. But I think the bar is set somewhat too high for success. A success in this framework seems to be a significant and exciting improvement for the entire Haskell community. And there have certainly been a number of those. But there are also projects that are well done, produce results that live on, but which aren't immediately recognizable as awesome new things. Furthermore, GSoc explicitly lists a goal as inspiring young developers towards ongoing community involvement/open source development, and these notes don't really take that into account. > > For example, I don't know of any direct uptake of the code from the HaskellNet project, but the author did go on to write a small textbook on Haskell in Japanese. As another example, Roman (of Hpysics [sic]) has, as I understand it, been involved in a Russian language functional programming magazine. > > So I think there needs to be a slightly more granular scale that can capture some of these nuances. Perhaps something like the following: > > - \[ \] Student completed (ie. got final payment) > - \[ \] Project found use (ie. as a lib has at least one consumer, or got merged into a broader codebase) > - \[ \] Project had significant impact (ie. wide use/noticeable impact) > - \[ \] Student continued to participate/make contributions to Haskell community > > A few more detailed comments about projects that weren't necessarily slam dunks, but were at the least, in my estimation, modest successes: > > 1. GHC-plugins -- Not only was the work completed and does it stand a chance of being merged, but it explored the design space in an useful way for future GHC development, and was part of Max becoming more familiar with GHC internals. Since then he's contributed a few very nice and useful patches to GHC, including, as I recall, the magnificent TupleSections extension. > 2. GHC refactoring -- It seems unfair to classify work that was taken into the mainline as unsuccessful. The improvement weren't large, but my understanding is that they were things that we wanted to happen for GHC, and that were quite time consuming because they were cross-cutting. So this wasn't exciting work, but it was yeoman's work helpful in taking the GHC API forward. It's still messy, I'm given to understand, and it still breaks between releases, but it has an increasing number of clients lately, as witnessed by discussions on -cafe. > 3. Darcs performance -- by the account of Eric Kow & other core darcs guys, the hashed-storage stuff led to large improvements (and not only in performance)[[2]](http://blog.darcs.net/2010/11/coming-in-darcs-28-read-only-support.html) -- the fact that there's plenty more to be done shouldn't be counted as a mark against it. Further criticisms by [sclv from 2013](https://www.reddit.com/r/haskell/comments/15sjur/summer_of_code_2012_retrospective/c7pfrro/): > I no longer think these summaries are even modestly useful, because the judgement criteria are too harsh and too arbitrary. They reflect a bias towards "success" of a gsoc project as something measurable directly measurable in uptake and users within a relatively short span of time. > > GSoC projects are chosen, on the other hand, with an eye towards long-term payoff in Haskell infrastructure. > > The criteria that would yield us "high success" projects in the sense judged here would also yield us projects that weren't very interesting, useful, or important. ## Haskell retrospective Haskell wasn't part of the first Summer of Code in 2005, but it was accepted for 2006. We start there ### 2006 The 2006 [homepage](https://web.archive.org/web/20070513121920/http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2006) lists the following projects: - ["Fast Mutable Collection Types for Haskell"](https://web.archive.org/web/20060629062454/http://hackage.haskell.org/trac/summer-of-code/ticket/61); Caio Marcelo de Oliveira Filho, mentored by Audrey Tang **Unsuccessful**. This ultimately resulted in the [HsJudy](!Hackage) library ('fast mutable collection' here meaning 'array'). HsJudy was apparently used in Pugs at one time, but no more. - ["Port Haddock to use GHC"](https://web.archive.org/web/20060629062124/http://hackage.haskell.org/trac/summer-of-code/ticket/44); David Waern, mentored by Simon Marlow **Successful**. Haddock has used the GHC API ever since.[^complaints] - ["A model for client-side scripts with HSP"](https://web.archive.org/web/20060629062327/http://hackage.haskell.org/trac/summer-of-code/ticket/54); Joel Björnson, mentored by Niklas Broberg **Successful?** Was initially unsuccessful, but seems to've been picked up again. - "GHCi based debugger for Haskell"; José Iborra López, mentored by David Himmelstrup **Successful**. The [GHCi debugger](https://web.archive.org/web/20150211215353/https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci-debugger.html) was accepted into GHC HEAD, and is in production use. - ["HaskellNet"](https://web.archive.org/web/20060629061857/http://hackage.haskell.org/trac/summer-of-code/ticket/30); Jun Mukai, mentored by Shae Erisson **Unsuccessful**. HaskellNet is dead, was noted to be ["uncompleted"](https://web.archive.org/web/20100130045958/http://hackage.haskell.org/trac/summer-of-code/ticket/1574), and none of it has propagated elsewhere. (I'm not entirely sure what happened with the HaskellNet code - I know of [two](https://web.archive.org/web/20140723072142/http://patch-tag.com/r/wrwills/HaskellNet/home) [repos](https://stuff.mit.edu/afs/sipb/project/suez/src/haskell/haskellnet/), but that's about it.) Shae tells me that this poor uptake is probably due to a lack of advertising, and not any actual defect in the HaskellNet code. - ["Language.C - a C parser written in Haskell"](https://web.archive.org/web/20080324102735/http://hackage.haskell.org/trac/summer-of-code/ticket/1545); Marc van Woerkom, mentored by Manuel Chakravarty **Unsuccessful**. According to [Don Stewart's outline](https://web.archive.org/web/20130128085020/https://www.haskell.org/pipermail/haskell-cafe/2007-February/022509.html "[Haskell-cafe] Summer of Code") of the 2006 SoC, this project was not completed. - ["Implement a better type checker for Yhc"](https://web.archive.org/web/20060629062841/http://hackage.haskell.org/trac/summer-of-code/ticket/81); Leon P Smith, mentored by Malcolm Wallace **Unsuccessful**. See the Language.C SoC - ["Thin out cabal-get and integrate in GHC"](https://web.archive.org/web/20060629061358/http://hackage.haskell.org/trac/summer-of-code/ticket/3); Paolo Martini, mentored by Isaac Jones **Successful**. Code lives on as [cabal-install](!Hawiki "Cabal-install"), which we all know and love. - "Storable a => ByteString a"; Spencer Janssen, mentored by Don Stewart **Successful**? (Again, per Don.) Currently exists as [storablevector](!Hackage), with [20 reverse dependencies](http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/storablevector-0.2.7#indirect). [^complaints]: I can hear the wankers in the peanut gallery - "Yeah, and it's been buggy ever since!" Hush you. ([Waern's reply](https://mail.haskell.org/pipermail/haskell-cafe/2009-February/055500.html).) 4 successful; 2 unsuccessful; and 2 failures. ### 2007 The [2007 homepage](https://web.archive.org/web/20080401152704/http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2007) lists: - ["Darcs conflict handling"](https://web.archive.org/web/20071203063254/https://code.google.com/soc/2007/haskell/appinfo.html?csaid=647C914C97658198); Jason Dagit, mentored by David Roundy **Successful**. The work was successful in almost completely getting rid of the exponential conflict bug, and has been in released Darcs for years - ["Automated building of packages and generation of Haddock documentation"](https://web.archive.org/web/20071201141912/https://code.google.com/soc/2007/haskell/appinfo.html?csaid=D505A03B8B64C3BF); Sascha Böhme, mentored by Ross Paterson **Successful**. The auto build and doc generation are long-standing and very useful parts of Hackage. - ["Rewrite the typechecker for YHC and nhc98"](https://web.archive.org/web/20071203042207/https://code.google.com/soc/2007/haskell/appinfo.html?csaid=AB859DA837B7BDCD); Mathieu Boespflug, mentored by Malcolm Wallace **Successful**? According to the TMR writeup, the type-checker code has made it into YHC. (I add a question mark because YHC is so little used.) - ["Cabal Configurations"](https://web.archive.org/web/20071201115804/https://code.google.com/soc/2007/haskell/appinfo.html?csaid=21BCDEABD117783D); Thomas Schilling, mentored by Michael Isaac Jones **Successful**. Cabal configurations are very useful for enabling/disabling things and are extremely common in the wild. - ["Update the Hat tracer"](https://web.archive.org/web/20071201121817/https://code.google.com/soc/2007/haskell/appinfo.html?csaid=637BFC2B6B13D512); Kenn Knowles, mentored by Malcolm Wallace **Unsuccessful**. The update apparently happened, since the [Hat homepage](https://www.cs.york.ac.uk/fp/ART/) says "Version 2.06 released 2nd Oct 2008", but it is [described](https://www.cs.york.ac.uk/fp/ART/download.html) as unmaintained, and I can't seem to find any examples of people actually using Hat. - ["Generalizing Parsec to ParsecT and arbitrary input (ByteStrings)"](https://web.archive.org/web/20071201123144/https://code.google.com/soc/2007/haskell/appinfo.html?csaid=B97EF4562EF3B244); Paolo Martini, mentored by Philippa Jane Cowderoy **Successful?**. The performance is still so terrible that few people use it. - ["Shared Libraries for GHC"](https://web.archive.org/web/20090504093628/https://code.google.com/soc/2007/haskell/appinfo.html?csaid=D0137F8B637176F1); Clemens Fruhwirth, mentored by Simon Marlow **Successful**. The situation is unclear to me, but I know that for some period dynamic linking worked for some platforms. However, it's 2010 and I still have static linking, although GHC 6.12 apparently gets dynamic linking; so I'm going to chalk this one up as a mixed success. - ["Libcurl"](https://web.archive.org/web/20080204074446/https://code.google.com/soc/2007/haskell/appinfo.html?csaid=D4DEE221DAC4E810); Mieczysław Bąk, mentored by Bryan O'Sullivan **Unknown** (but apparently [**Unsuccessful**](https://twitter.com/mietek/status/1106638603785027586)) The archived homepage [homepage](https://web.archive.org/web/20070706103752/http://varsztat.com/projects/curl/) and [repository](https://web.archive.org/web/20070708071534/varsztat.com/projects/curl/darcs/) indicate that the package name was [curl](!Hackage) and indeed a [curl](!W "cURL") binding of that name exists - but none of the metadata points to Bąk as either author or maintainer; if it is the same package, it is pretty successful with 158 reverse dependencies at writing. - ["Extending GuiHaskell: An IDE for Haskell Hackers"](https://web.archive.org/web/20070813151006/https://code.google.com/soc/2007/haskell/appinfo.html?csaid=152CF82F48143D59); Asumu Takikawa, mentored by Neil David Mitchell **Unsuccessful**. GuiHaskell does not exist in any usable form. (The homepage summarizes the situation thusly: ["**Warning**: This project is fragile, unfinished, and I do not recommend that anyone tries using it."](https://web.archive.org/web/20071109185622/http://www-users.cs.york.ac.uk/~ndm/guihaskell/)) 6 successes; 2 unsuccessful; 1 unknown. #### See Also - [The Monad.Reader's](!Hawiki "The Monad Reader") [issue 9](https://wiki.haskell.org/wikiupload/5/5d/TMR-Issue9.pdf) covers 3 2007 SoC projects - ["Haskell.org and Google's Summer of Code"](http://www.serpentine.com/blog/2007/04/12/haskellorg-and-googles-summer-of-code/) -(Bryan O'Sullivan; 2007-04-12) ### 2008 The [2008 homepage](https://web.archive.org/web/20080331232242/http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2008) isn't kind enough to list all the projects, but it does tell us that only 7 projects were accepted by Google. So we can work from the [code.google.com](https://code.google.com/archive/p/google-summer-of-code-2008-haskell/downloads) page which lists 6: - "C99 Parser/Pretty-Printer"; by Benedikt Huber, mentored by Iavor Diatchki **Successful**. The first try failed, but the second won through, and now people are doing things like [parsing the Linux kernel](https://galois.com/blog/2008/9/17/parsing-the-linux-kernel-with-haskell-experience-with-langua.html) with it. - ["GMap - Fast composable maps"](https://web.archive.org/web/20080408151715/http://hackage.haskell.org/trac/summer-of-code/ticket/1560); by Jamie Brandon. mentored by Adrian Charles Hey **Unsuccessful**. GMap is on [Hackage](https://hackage.haskell.org/packages/), but there are 0 users after 3 years. - "Haskell API Search"; Neil Mitchell, mentored by Niklas Broberg **Successful**. The improved performance and search capability have made it into [Hoogle](!Hackage "hoogle") releases, and Hoogle is one of the more popular Haskell applications (with [1.7m web searches](https://neilmitchell.blogspot.com/2011/01/hoogle-at-17-million-searches.html)). - ["Cabal 'make-like' dependency framework"](https://web.archive.org/web/20080616045128/https://code.google.com/soc/2008/haskell/appinfo.html?csaid=56D60241D77CA94C); Andrea Vezzosi, mentored by Duncan Coutts **Unsuccessful**. ([His code](https://archives.haskell.org/code.haskell.org/~Saizan/cabal/) [wound](https://archives.haskell.org/code.haskell.org/hbuild/) [up](https://web.archive.org/web/20110901054201/http://vezzosi.blogspot.com/2008/09/even-if-this-blog-has-been-silent-since.html "Results from GSoC") becoming [hbuild](https://web.archive.org/web/20111206064418/https://hackage.haskell.org/trac/hackage/wiki/HBuild), which is not on Hackage or apparently used by anyone.) - ["GHC plugins"](https://web.archive.org/web/20080501130545/https://code.google.com/soc/2008/haskell/appinfo.html?csaid=69C2ABD1E013EE0C); Maximilian Conroy Bolingbroke, mentored by Sean Seefried **Unsuccessful**? As of [January 2010](https://mail.haskell.org/pipermail/glasgow-haskell-users/2010-January/018293.html "GHC core plugins"), the patch adding plugins functionality has yet to be accepted & applied; as of February 2011, the [ticket](https://gitlab.haskell.org/ghc/ghc/-/issues/3843) remains open and the code unmerged. The code is apparently not yet bitrotten by the passage of 3 years but how long can its luck last? The code was finally merged in 2011-08-04; [the docs](https://gitlab.haskell.org/ghc/ghc/-/wikis/new-plugins) do not list any users. - "Data parallel physics engine"; Roman Cheplyaka, mentored by Manuel M. T. Chakravarty **Unsuccessful**. It seems to be finished but no use made of the actual engine that I can see mentioned on the [engine's blog](https://physics-dph.blogspot.com/). (I would give reverse dependency statistics, but [Hpysics](!Hawiki) seems to have never been uploaded to Hackage.) - "GHC API"; Thomas Schilling, mentored by Simon Marlow **Unsuccessful**. Schilling's fixes went in, but they were in general minor changes (like adding the GHC monad) or bug-fixes; the GHC API remains a mess. 2 successful, 5 unsuccessful. #### Don Stewart's view [Don Stewart writes](https://mail.haskell.org/pipermail/haskell-cafe/2009-February/055531.html) in reply to the foregoing: > "We explicitly pushed harder in 2008 to clarify and simplify the goals of the projects, ensure adequate *prior Haskell experience* and to focus on libraries and tools that directly benefit the community. > > And our success rate was much higher. > > So: look for things that benefit the largest number of Haskell developers and users, and from students with proven Haskell development experience. You can't learn Haskell from zero on the job, during SoC." #### See Also - The Monad.Reader's [Issue 12](https://wiki.haskell.org/wikiupload/f/f0/TMR-Issue12.pdf) ### 2009 5 projects were [accepted](https://socghop.appspot.com/org/home/google/gsoc2009/haskell) this year; Darcs tried to apply in its own right was rejected. In general, these looked good. Most of them will be widely useful -- especially the Darcs and Haddock SoCs -- or address long-standing complaints (many criticisms of laziness revolve around how unpredictable it makes memory consumption). The only one that bothers me is the EclipseFP project. I'm not sure Eclipse is common enough among Haskellers or potential Haskellers to warrant the effort^[In the [2010 survey](https://blog.johantibell.com/2010/08/results-from-state-of-haskell-2010.html) of Haskellers, 3% reported ever using Eclipse for Haskell programming. In the [2011 survey](https://blog.johantibell.com/2011/08/results-from-state-of-haskell-2011.html), 4% did.], but at least the project is focused on improving an existing plugin than writing one from scratch. The 5 were: - ["Optimising Darcs for medium to large repositories"](https://socghop.appspot.com/gsoc/student_project/show/google/gsoc2009/haskell/t124022467805); by Petr Ročkai; mentored by [Eric Kow](https://erickow.com/) **Unknown**. [hashed-storage](https://hackage.haskell.org/package/hashed-storage) exists and is used in Darcs, but from watching the bugtracker traffic, it's unclear whether Darcs saw a net gain from it. - ["haskell-src-exts -> haskell-src"](https://socghop.appspot.com/gsoc/student_project/show/google/gsoc2009/haskell/t124022467962); by Niklas Broberg; mentored by Neil Mitchell **Successful**. Niklas added a large number of [patches](https://google-summer-of-code-2009-haskell.googlecode.com/files/Niklas_Broberg.tar.gz) but it's unclear to mean what practical benefit it adds besides handling comments now (which was useful for hlint). Speaking practically, haskell-src has 104 reverse dependencies at writing, and haskell-src-exts has 223; so the latter seems to have indeed surpassed its predecessor. - ["Haddock improvements"](https://socghop.appspot.com/gsoc/student_project/show/google/gsoc2009/haskell/t124022468112); by Isaac Dupree; mentored by David Waern **Successful?**. Dupree's [patches](https://google-summer-of-code-2009-haskell.googlecode.com/files/IsaacA_Dupree.tar.gz) have been applied to head and apparently make cross-package links [usually work](https://haddock2009.wordpress.com/category/cross-package-documentation/). - ["Improving space profiling experience"](https://socghop.appspot.com/gsoc/student_project/show/google/gsoc2009/haskell/t124022468245); by Gergely Patai; mentored by Johan Tibell **Successful**. [hp2any](https://wiki.haskell.org/Hp2any) seems quite alive and usable. - ["Extend EclipseFP functionality for Haskell"](https://socghop.appspot.com/gsoc/student_project/show/google/gsoc2009/haskell/t124022468390); by Thomas ten Cate; mentored by Thomas Schilling **Unsuccessful**. See [Cate's summing-up](https://eclipsefp.wordpress.com/2009/08/25/endgame/). 3 successful, 1 unknown, 1 unsuccessful. ### 2010 [7 projects](https://donsbot.com/2010/04/26/the-7-haskell-projects-in-the-google-summer-of-code/) were accepted: - [Improvements to Cabal's test support](https://webcitation.org/6FTUJT4sx); Thomas Tuegel, mentored by Johan Tibell **Successful**? The functionality is now in a released version of `cabal-install` and a number of packages use the provided test syntax.^[As of 2011-03-18, I have local copies of 8 repositories which seem to make use of the new syntax: `angle, cabal, concurrent-extra, hashable, rrt, safeint, spatialIndex, unordered-containers, wai-app-static`.] - [Infrastructure for a more social Hackage 2.0](https://cogracenotes.wordpress.com/hackage-proposal/); Matthew Gruen, mentored by Edward Kmett **Unknown**. [Gruen's blog](https://cogracenotes.wordpress.com/) was last updated October 2010, and Hackage still hasn't switched over and gotten the new features & benefit of the rewrite. But the code exists and there is a running [public demo](https://web.archive.org/web/20091001184532/http://sparky.haskell.org:8080/), so this may yet be a success. - [A high performance HTML generation library](https://webcitation.org/6JQ1LLFnH); Jasper Van der Jeugt, mentored by Simon Meier **Successful** [blaze-html](!Hackage) has been released and is actively developed; version 0.4.0.0 has 50 total reverse dependencies at writing and [blaze-builder](!Hackage) has 97 reverse dependencies though there's much overlap. (This site is built on [hakyll](!Hackage), which uses blaze-html.) - [Improvements to the GHC LLVM backend](https://web.archive.org/web/20100501033720/https://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/haskell/t127230760615); Alp Mestanogullari, mentored by Maximilian Bolingbroke **Unsuccessful**. Dan Peebles in #haskell says that Alp's SoC never got off the ground when his computer died at the beginning of the summer; with nothing written or turned in, this can't be considered a successful SoC, exactly. But could it have been? The LLVM backend is still on track to become the default GHC backend^[A development that surprises me, since I had been under the impression that most GHC work ultimately winds up being scrapped or abandoned like [Liskell](https://web.archive.org/web/20120609122549/http://www.liskell.org/) or [Mobile Haskell](https://wiki.haskell.org/Research_papers/Parallelism_and_concurrency#Mobile_Haskell).], suggesting that it's popular in GHC HQ (and the [DDC](http://www.discus-lang.org/) dialect), and it seems to also be popular among [Haskell bloggers](https://www.reddit.com/r/haskell/search?q=LLVM&restrict_sr=on). The scope is restricted to taking a working backend and optimizing it. In general, it seems like a decent SoC proposal, and better than the next one: - [Implementing the Immix Garbage Collection Algorithm](https://web.archive.org/web/20140511002018/http://www2.dcc.ufmg.br/laboratorios/llp/wiki/doku.php?id=marco_soc); Marco Túlio Gontijo e Silva, mentored by Simon Marlow **Unsuccessful**. The GHC repository history, as of 4 February, contains no patches adding Immix GC. Silva writes in his blog's [SoC summary](https://marcotmarcot.wordpress.com/2010/08/20/immix-on-ghc-summer-of-code-final-report/) that "Although the implementation is not mature enough to be included in the repository, I'm happy with the state it is now. I think it's a good start, and I plan to keep working on it." (His [new blog](https://web.archive.org/web/20140623203436/http://marcot.eti.br/blog/), begun in August 2010, contains no mention of Immix work.) The [GHC wiki](https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/storage/gc/immix) says that "it's functional, doesn't have known bugs and gets better results than the default GC in the nofib suite. On the other hand, it gets worse results than the default GC for the nofib/gc suite." Marco said in a Disqus comment on this page: > Hi. I wondered about continuing my work on the Immix GC collector, but Simon Marlow, my mentor, thought it was not a good idea to invest more effort on Immix. So I dropped it, and started working on other things. Greetings. - ["Improving Darcs Performance"](https://darcs.net/GSoC/2010-Cache); Adolfo Builes, mentored by Eric Kow **Successful**. This replaced a previous proposal to write a Haskell binding to the [GObject](!W) library, which never started. Looking through the Darcs repository history, I see a number of new tests related to the global cache, but no major edits to cache-related modules. The Darcs wiki reports it as a successful and closing some bugs. - [Improving Darcs's network performance](https://web.archive.org/web/20110319011101/https://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/haskell/t127230760775); Alexey Levan, mentored by Petr Rockai **Successful**. Levan divided his SoC into 2 parts, improving Darcs's performance in fetching the many small files that make up a repository's revision history, and writing 'a smart server that can provide clients with only files they need in one request'. The 'smart server' seems to have been abandoned as not being worthwhile, but the fetching idea was implemented and will be in the [2.8 release](http://blog.darcs.net/2010/11/coming-in-darcs-28-new-features.html). The [basic idea](https://darcs.net/Internals/OptimizeHTTP) is to combine all the small files into a single [tarball](!W "tar (file format)") which can be downloaded at full speed, and avoid the latency of many roundtrips. The 2.8 release description claims that when `darcs optimize --http` was used on the Darcs repository, a full download went from 40 minutes to 3 minutes. This feature would not be enabled by default, but the gain for larger repositories would be large enough that I feel comfortable classifying it as a successful SoC. #### Predicting 2010 results Borrowing from our [3 cardinal sins](#lessons-learned) of SoCs, and per my usual practice of testing my understanding by [making predictions](/prediction-market#calibration), what predictions do I make about the 2010 SoCs? Most of the 7 SoCs are laudably focused on an existing application. You don't need to justify a speedup of normal Darcs operations because there's an installed base of Darcs users that will benefit; a new GC for GHC or a LLVM backend will benefit every Haskeller; better Cabal support for testing may go unused by many package authors who either have no tests or don't want to bother - but a fair number will bother, and it will get maintained as part of Cabal, and similarly for the Hackage 2.0 project. The Immix GC strikes me as a very challenging summer project; a GC is one of the most low-level pieces of a functional language and is intertwined with all sorts of code and considerations. It would not surprise me if that project wound up just getting a little closer to a working Immix GC but not producing a production-quality GC scheduled to come to compilers near you. 2 in particular concern me as potentially falling prey to sins #2 & 3: the GObject-binder tool, and the high-performance HTML library: #. Let's assume that the HTML library does wind up as being faster than existing libraries, and as useful - that compromises don't destroy its utility. Who will use it? It will almost surely have an API different enough from existing libraries that a conversion will be painful. There are roughly 42 users of the existing [xhtml](http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/package/xhtml)-generating library; will their authors wish to embrace a cutting-edge infant library? Is HTML generation even much of a bottleneck for them? (Speaking just for Gitit, Pandoc and its HTML generation are not usually a bottleneck.) #. The case against the GObject project makes itself; GTK2Hs isn't as widely used as one would expect, and this seems to be due to the difficulty of installation and its general complexity. So there are few users of existing libraries; would there be more users for those libraries no one has bothered to bind nor yet clamored for? (This project might fall afoul of sin #1, but I do not know how difficult the GObject data is to interpret.) #### 2010 results As of February 2010, I grade the 7 SoC for 2010 as follows: 4 successes, 1 unknown, and 2 unsuccessful. (One unknown, Hackage 2.0, will probably turn out to be a success if it ever goes live as the main Hackage site; as of 2013-01-01, it has not.) As one would hope, the results seem to be better than the results for 2008 or 2009. Of my original predictions, I think I was right about the Immix GC & GObject & Darcs optimizations, semi-right about Hackage 2.0 & Cabal testing support, somewhat wrong about the LLVM work, and completely wrong about the HTML/`blaze` SoC. (I am not sure why I was wrong about the last, and don't judge myself harshly for not predicting the [exogenous](!W) failure of the LLVM SoC.) ### 2011 [Haskell.org](https://webcitation.org/6AMifPmeW) got 7 projects again for 2011. They are: #. ["Improve EclipseFP"](https://webcitation.org/6AMIWPTNl); Alejandro Serrano, mentored by Thomas Schilling > "Eclipse is one of the most popular IDEs in our days. EclipseFP is a project developing a plug-in for it that supports Haskell. Now, it has syntax highlighting, integration of GHCi and supports some properties of Cabal files. My idea is to extend the set of tools available, at least with: > - Autocompletion and better links to documentation, > - A way to run unit tests within Eclipse, > - More support for editing Cabal files visually, including a browser of the available packages." #. ["Simplified OpenGL bindings"](https://web.archive.org/web/20110527145040/http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/pastorn/1); Alexander Göransson, mentored by Jason Dagit > "Modernize and simplify OpenGL bindings for Haskell. Focus on safety, shaders and simplicity." #. ["Interpreter Support for the Cabal-Install Build Tool"](https://web.archive.org/web/20110527144831/http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/anklesaria/1); anklesaria, by Duncan Coutts > "This project aims to provide cabal-install with an '[repl](!W "Read-eval-print loop")' [[`cabal ghci`](https://github.com/haskell/cabal/issues/375 "'cabal ghci' mode")?] command by adding to the Cabal API. This would allow package developers to use GHCi and Hugs from within packages requiring options and preprocessing from Cabal. " #. ["Convert the `text` package to use UTF-8 internally"](https://web.archive.org/web/20110429055121/http://www.google-melange.com/gsoc/project/google/gsoc2011/jaspervdj/15001); Jasper Van der Jeugt, by Edward Kmett ([detailed proposal](https://jaspervdj.be/files/2011-gsoc-text-utf8-proposal.html)) > "For Haskell projects handling Unicode text, the `text` library offers both speed and simplicity-of-use. When it was written, benchmarks indicated that UTF-16 would be a good choice for the internal encoding in the library. However, these (rather artificial) benchmarks were did not take into account the time taken to > 1. decode the 'Real World' data and > 2. encode it to write it back. > > I propose to > 1. benchmark and > 2. convert the library to UTF-8 if it is a faster choice for 'Real World'-applications." #. ["Build multiple Cabal packages in parallel"](https://web.archive.org/web/20110429055151/http://www.google-melange.com/gsoc/project/google/gsoc2011/refold/31001); Mikhail Glushenkov, by Johan Tibell > "Cabal is a system for building and packaging Haskell libraries and programs. This project's aim is to augment Cabal with support for building packages in parallel. Many developers have multi-core machines, but Cabal runs the build process in a single thread, only making use of one core. If the build process could be parallelized, build times could be cut by perhaps a factor of 2-8, depending on the number of cores and opportunity of parallel execution available." #. ["Darcs Bridge"](https://web.archive.org/web/20110527145035/http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/owst/1); Owen Stephens, by Ganesh Sittampalam > "My proposed project is to create a generic bridge that will enable easy interoperability and synchronisation between Darcs and other VCSs. The bridge will be designed to be generic, but the focus of this project will be Darcs2 ↔ Git and Darcs2 ↔ Darcs1. The bridge should allow loss-less, correct conversion to and from Darcs repositories, allowing users to use the tool that suits them and their project best, be that Darcs as it currently exists, or another tool." #. ["Darcs: primitive patches version 3"](https://web.archive.org/web/20110527094958/http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/mornfall/1) ([expanded blog description](https://web.archive.org/web/20121115215114/http://web.mornfall.net/blog/soc_reloaded%3A_darcs_primitive_patches_version_3.html)); Petr Ročkai, by Eric Kow > "Darcs, a revision control system, uses so-called patches to represent changes to individual version-controlled files, where the 'primitive' patches are the lowest level of this representation, capturing notions like 'hunks' (akin to what `diff(1)` produces), token replace and file and directory addition/removal. I propose to implement a different representation of these primitive patches, hoping to improve both performance and flexibility of darcs and to facilitate future development." #### Predicting 2011 results Which seem like good selections for SoC, and which seem less appropriate? #. \#1 is the *second* EclipseFP SoC, after a failed [2009](#section-3) attempt; why should we think this one will do better? #. With #2, the fear is that the result will not be used; there is an OpenGL binding already, after all, and I haven't heard that there are very many people who want to do OpenGL graphics but were deterred by complexity or danger in it. #. `cabal ghci` is a long-requested Cabal feature, and it sounds as if all the groundwork and experimentation has been done. I have no problem with this one. #. Benchmarking sounds quite doable, and `text` is increasingly used; but if I had to criticize it, I would criticize it for *under*ambition, for sounding too modest and not a good use of a slot. #. \#5 is a second crack at the parallel compilation problem (building on a [2008](#section-2) SoC) and is troubling in the same way the EclipseFP SoC is. #. There are multiple existing Darcs->other VCS programs, so the task is quite doable. An escape hatch would be very valuable for users (even if rarely used). #. This one sounds tremendously speculative to me. I respect Ročkai & Kow, but in idling on `#darcs` and reading the occasional Darcs-related emails & Reddit posts, I don't know of any fully worked out design for said patch design, which makes it a challenging theoretical problem (patch theory being general & powerful), a major implementation issue (since the existing primitive patches are naturally assumed all throughout the Darcs codebase), and difficult to verify that it will not backfire on users or legacy repositories. All in all, #7 sounds like the sort of project where the *best* case scenario is a repository branch/fork somewhere that few besides the author understands, which is better on some usecases and worse on others, but not actually in general use. That might be a success by the Darcs's team's lights, but not in the sense I have been using in this history. To summarize my feelings: - \#1 seems a bit doubtful but is more likely to succeed (because presumably most of the heavy lifting was done previously). - I predict #2 & #7 will likely fail - I would be mildly surprised if *both* #3 & #5 succeed - since they're challenging and long-request Cabal features - but I expect at least one of them to succeed. Which, I am not sure. - I expect with confidence that #4 & #6 will succeed. #### 2011 results #. "Improve EclipseFP"; Alejandro Serrano, mentored by Thomas Schilling **Successful**. The [coding](https://serras-haskell-gsoc.blogspot.com/2011/08/end-of-summer.html) was finished, to the author's apparent satisfaction, and the work was included in the [2.1.0](https://jpmoresmau.blogspot.com/2011/09/eclipsefp-210-released.html) release. #. "Simplified OpenGL bindings"; Alexander Göransson, mentored by Jason Dagit **Unsuccessful**. Jason Dagit says Alexander never started for unknown personal reasons and so no work was ever done (no `OpenGLRawNice` library exists, a post-August 2011 Google search for "Alexander Göransson OpenGL" is dry, nothing on Hackage seems to mention OpenGL 4.0 support, etc.). #. "Interpreter Support for the Cabal-Install Build Tool"; anklesaria, by Duncan Coutts **Unsuccessful**? anklesaria's final post, ["Ending GSoC"](https://lambdasandwich.blogspot.com/2011/08/ending-gsoc.html), says the work is done and provide a repository with patches by `amsay@amsay.net` - but no patches by that email appear in the Cabal repository as of 2011-12-10; nor does there appear to be any discussion in the [cabal-dev ML](https://mail.haskell.org/pipermail/cabal-devel/) archives. #. "Convert the `text` package to use UTF-8 internally"; Jasper Van der Jeugt, by Edward Kmett **Successful**. Jasper published 2 posts on benchmarking the converted `text` against the original (["Text/UTF-8: Initial results"](https://jaspervdj.be/posts/2011-07-10-text-utf8-initial-results.html) & ["Text/UTF-8: Studying memory usage"](https://jaspervdj.be/posts/2011-08-09-text-utf8-memory-usage.html)); discussing the results in ["Text/UTF-8: Aftermath"](https://jaspervdj.be/posts/2011-08-19-text-utf8-the-aftermath.html), the upshot is that the conversion has a real but small advantage, potentially would cause interoperability problems, requires considerable testing, and won't be merged in (the fork will be maintained against hopes of future GHC optimizations). Jaspers says the benefits wound up being a bigger & cleaner test/benchmark suite, and some optimizations made for the UTF-8 version can be applied to the original. Since Edward Kmett [seems pleased](https://jaspervdj.be/posts/2011-08-19-text-utf8-the-aftermath.html#comment-291037007), I have marked it a success (although I remain dubious about whether it was a good SoC). #. "Build multiple Cabal packages in parallel"; Mikhail Glushenkov, by Johan Tibell **Successful** Glushenkov reported in ["Parallelising cabal-install: Results"](http://coldwa.st/e/blog/2011-08-22-GSoC-Final.html) that the patches were done and people could play with his repository; the comments report that it works and does offer speedups. However, as before, no patch by him appears in the mainline Cabal, and the last discussion was 2011-11-06 where [he provides a patch bundle](https://github.com/haskell/cabal/issues/440#issuecomment-5892025). No one commented; Mikhail says the patches may be "too invasive" and need reworking before merging.[^Mikhail] The code was ultimately released as part of [cabal-install 1.16](https://web.archive.org/web/20130128085047/https://www.haskell.org/pipermail/haskell-cafe/2012-October/103746.html "[Haskell-cafe] ANN: cabal-install-1.16.0 (and Cabal-1.16.0.1)") and is reportedly working well. #. "Darcs Bridge"; Owen Stephens, by Ganesh Sittampalam **Successful**? Owen's [GSoC blog posts](https://www.owenstephens.co.uk/blog/tags/gsoc.html) conclude with ["GSoC: Darcs Bridge - Results"](https://www.owenstephens.co.uk/blog/2011/09/03/gsoc_darcs_bridge__results.html) summarizing the final features: he succeeded in most of the functionality. Brent Yorgey tells me that he has successfully used the tool to convert repositories to put onto Github, but says there are "some critical bugs" and use is still "clunky" (eg. currently requiring Darcs HEAD; see the usage guide on the [Darcs wiki](https://web.archive.org/web/20170705082122/https://darcs.net/DarcsBridgeUsage)). Whether the bugs will be fixed and the package polished to the point where it will be widely used remains to be seen. #. "Darcs: primitive patches version 3"; Petr Ročkai, by Eric Kow **Unsuccessful**. Ročkai wrote two posts (["soc reloaded: progress 1"](https://web.archive.org/web/20121111075143/http://web.mornfall.net/blog/soc_reloaded%3A_progress_1.html) & ["soc reloaded: Outcomes"](https://web.archive.org/web/20121114134706/http://web.mornfall.net/blog/soc_reloaded%3A_outcomes.html)). This seems to have turned out as I predicted above: > "Since my last report, I have decided to turn somewhat more radical again. The original plan was to stick with the darcs codebase and do most (all) of the work within that, based primarily on writing tests for the testsuite and not exposing anything of the new functionality in an user-visible fashion. I changed my mind about this. The main reason was that the test environment, as it is, makes certain properties hard to express: a typical test-suite works with assertions (HUnit) and invariants (QuickCheck). In this environment, expressing ideas like 'the displayed patches are aesthetically pleasing' or 'the files in the repository have reasonable shape' is impractical at best. An alternative would have been to make myself a playground using the darcs library to expose the new code. But the fact is, our current codebase is entrenched in all kinds of legacy issues, like handling filenames and duplicated code. It makes the experimenter's life harder than necessary, and it also involves rebuilding a whole lot of code that I never use, over and over. All in all, I made a somewhat bold decision to cut everything that lived under `Darcs.Patch` (plus a few dependencies, as few as possible) into a new library, which I named `patchlib`, in the best tradition of `cmdlib`, `pathlib` and `fslib`. At that point, I also removed custom file path handling from that portion of code, removed the use of a custom `Printer` (a pretty-printer implementation) module and a made few other incompatible changes." The remaining work? > "The obvious future work lies in the conflict handling. There are two main options in this regard: either re-engineer a patch-level, commute-based representation of conflicts (in the spirit of mergers and conflictors), as V3 'composite' patches, or alternatively, use a non-patch based mechanism for tracking conflicts and resolutions. It's still somewhat early to decide which is a better choice, and they come with different trade-offs. Nevertheless, the decision, and the implementation, constitute a major step towards darcs 3. The other major piece of work that remains is the repository format: in this area, I have done some research in both the previous and this year's project, but there are no definitive answers, even less an implementation. I think we now have a number of good ideas on how to approach this. We do need to sort out a few issues though, and the decision on the conflict layer also influences the shape of the repository. > > Each of these two open problems is probably about the size of an ambitious SoC project. On top of that, a lot of integration work needs to happen to actually make real use of the advancements. We shall see how much time and resources can be found for advancing this cause, but I am relatively optimistic: the primitive level has turned out fairly well, and to me it seems that shedding the shackles of legacy code sprawl can boost the project as a whole significantly forward." As I wrote before, the Darcs team will disagree with my assessment, but I believe marking it 'Unsuccessful' is most consistent with how all previous SoCs have been judged[^IRC]. [^Mikhail]: 2011-12-11, [Google+](https://plus.google.com/u/0/103530621949492999968/posts/J4HYwwmTuk2): > "Regarding the parallel cabal-install patches - Duncan is concerned that my changes are too invasive. I hope to get them merged in during the next few months after some reworking (we're currently discussing what needs to be done)." [^IRC]: From [my conversation in `#darcs`](https://web.archive.org/web/20120128085134/http://irclog.perlgeek.de/darcs/2011-04-26) with Eric Kow and other Darcs developers: < kowey> mornfall [Petr Ročkai] and I did discuss the proposal beforehand... one thing to clear up first of all is that this is very specifically about the primitive patch level and not a wider patch theory project < kowey> the difference being that it's easier to do in a SoC project < owst> Also, mornfall has the advantage of being very experienced with the Darcs code-base, and its concepts - he's not going to require time to "get used to it" so I'd argue he's certainly not the average SoC student... < kowey> I think mornfall has also put a good show of effort into thinking about (A) building off previous thinking on the matter (see his proposal), (B) fitting into the Darcs agenda -- particularly in aiming for this work to happen in mainline with the help of recent refactors and also to result in some cleanups and (C) making the project telescope < gwern> owst: well, in a sense, that's a negative for the project as well as a positive implementation-wise - SoCs are in part about bringing new people into communities < kowey> by telescope I mean, have a sane ordering of can-do to would-be-awesome < Heffalump> gwern: yeah, though the Haskell mentors didn't see it that way < kowey> (the mental image being that you can collapse a telescope) < gwern> owst: I didn't mention that because I'm trying to not be unrelentingly negative, and because investigating backgrounds of everyone would require hours of work < kowey> (sorry, I misread and see now that gwern did catch that this was primpatch specific) < owst> gwern: in part, but not in full - they are ultimately also about "getting code written" for a project and that's certainly going to happen for mornfall's project! < gwern> owst: that's the same reason I don't also judge SoCs by whether the student continued on in the community - because it'd be too damn much work < owst> gwern: sure, I thought as much. < gwern> owst: even though the student's future work would probably flip a number of projects from failure to success and vice-versa (eg. what has Spencer Janssen been doing lately? how many of the SoC students you see on the page did that and have not been heard from since like Mun of Frag?) < gwern> so, I just judge on whether the code gets used a lot and whether it did something valuable < kowey> it's a project that has long-term value for Darcs < kowey> I think I agree with the last line of your prediction, "That might be a success by the Darcs's team's lights, but not in the sense I have been using in this history." < kowey> although I'm certainly hoping for something better in the middle bit: code that winds up in darcs mainline plus specifications on the wiki So of the 7 2011 SoCs: - 3 were unsuccessful (2 possibly not) - 4 were successful (1 possibly not) My predictions were in general accurate; I remained hopeful that at least one of the Cabal SoCs would be merged in, which would give me a clean sweep and also render the final 2011 SoC record as good as the 2010 SoC record. (The parallel build was eventually merged in during 2012.) It troubles me that the Cabal SoCs took so long to be merged in (if at all), in line with the historical trend for big Cabal SoC improvements to be partially done but never go into production. Duncan Coutts [says](https://www.reddit.com/r/haskell/comments/n82ln/summer_of_code_2011_retrospective/c377srp#siteTable_t3_n82ln) they are in the queue, but if neither gets merged in before the 2012 SoC starts, the lesson seems to be that Cabal is too dangerous and uncertain to waste SoCs on. ### 2012 In [2012](https://web.archive.org/web/20120319051841/http://www.google-melange.com/gsoc/org/google/gsoc2012/haskell), Haskell.org was bumped to 8 slots: #. ["Patch Index Optimization for Darcs"](https://web.archive.org/web/20120607155555/http://www.google-melange.com/gsoc/project/google/gsoc2012/bsrkaditya/28002) ([proposal](https://web.archive.org/web/20120604224104/http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/bsrkaditya/14002)); BSRK Aditya, mentored by Eric Kow > The goal of this project is to speed up the darcs changes and darcs annotate commands using a cache called "[patch index](https://darcs.net/Ideas/PatchIndex)". The slow speed of these commands is one of the major user grievance in darcs. Patch-Index data structures can quickly identify the patches that modified a given file. #. ["Scoutess - a build manager for cabal projects"](https://web.archive.org/web/20120608093533/http://www.google-melange.com/gsoc/project/google/gsoc2012/dmcgill/18001); DMcGill, mentored by Alp Mestanogullari > Scoutess is a tool for package maintainers and automates a lot of the hassle of dealing with dependencies and multiple versions of libraries. It will create a sandboxed environment simulating a fresh Haskell Platform install, attempt to build your project using Cabal and highlight any problems while also tracking changes or updates to dependencies located in remote repositories so these can be tested against as well. #. ["Implement Concurrent Hash-table / Hash map"](https://web.archive.org/web/20120606173033/http://www.google-melange.com/gsoc/project/google/gsoc2012/lorehead/36001) ([proposal](https://web.archive.org/web/20130102200035/https://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/lorehead/1)); Loren Davis, mentored by Ryan Newton > Concurrent data structures for Haskell are currently a work in progress, and are necessary for parallel and high-performance computing. A few data structures, such as wait-free lists, already have Haskell implementations. One that does not yet is a thread-safe hash table. I propose to implement one as a library available under the new BSD license. #. ["Accelerating Haskell Application Development"](https://web.archive.org/web/20120618122604/http://www.google-melange.com/gsoc/project/google/gsoc2012/mdittmer/18001); mdittmer, mentored by Michael Snoyman > A project for improving performance of "lively developer mode" environments that require fast rebuild-and-redeploy routines. #. ["Sandboxed builds and isolated environments for Cabal"](https://web.archive.org/web/20120606152917/http://www.google-melange.com/gsoc/project/google/gsoc2012/refold/64002); Mikhail Glushenkov, mentored by Johan Tibell > The aim of this project is to integrate support for sandboxed builds into Cabal, a system for building Haskell projects. There are several different third-party implementations of this functionality already available, but it would be beneficial (from the points of ease of use and focusing the community efforts) to have an unified and polished solution integrated into Cabal itself. Additionally, this project is a step in the direction of solving the infamous "dependency hell" problem of Cabal. #. ["Enable GHC to use multiple instances of a package for compilation"](https://web.archive.org/web/20120610002543/http://www.google-melange.com/gsoc/project/google/gsoc2012/phischu/19001) ([proposal](https://web.archive.org/web/20120614024717/http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/phischu/1)); Philipp Schuster, mentored by Andres Löh > People are running into dependency hell when installing Haskell packages. I want to help move in the direction of solving it. #. ["multiuser browser-based interactive ghci, hpaste.org meets tryhaskell.org, for improved teaching of those new to Haskell."](https://web.archive.org/web/20120609020356/http://www.google-melange.com/gsoc/project/google/gsoc2012/shapr/18001) ([proposal](https://web.archive.org/web/20120621111700/http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/shapr/1)); Shae Erisson, mentored by Heinrich Apfelmus > Many new users learn Haskell from the `#haskell` IRC channel. `lambdabot`'s `mueval` is good for interactive teaching, but only allows short code snippets. `hpaste` allows large snippets to be shared, but not into an interactive `ghci`. Chris Done's [Try Haskell!](https://www.tryhaskell.org/) allows larger snippets to be loaded, but is not explicitly multi-user. If Try Haskell! allowed multiple users to view the same interpreter state, and allowed users to paste in new code, teaching and debugging would be much easier for people new to Haskell. #. ["Haskell-Type-Exts"](https://web.archive.org/web/20120607103944/http://www.google-melange.com/gsoc/project/google/gsoc2012/shayannajd/18001); Shayan Najd, mentored by Niklas Broberg > Following the proposal by Niklas Broberg [0], I am highly eager to expand the existing typechecker [1] for Haskell-Src-Exts [2] to support most of the features available in Haskell 2010 with the major extensions like GADTs, RankNTypes and Type-Functions. It is done by following the guidelines of "Typing Haskell in Haskell" [3] as the basis; adding support for RankNTypes [5]; and then introducing GADTs and Type-Functions by local assumptions [4]. [0] https://web.archive.org/web/20060517222319/http://hackage.haskell.org/trac/summer-of-code/ticket/1620 [1] https://hackage.haskell.org/package/haskell-src-exts [2] https://hackage.haskell.org/package/haskell-type-exts [3] M. P. Jones. Typing Haskell in Haskell [4] D. Vytiniotis, S. Peyton Jones, T. Schrijvers, M. Sulzmann. OutsideIn(X) - Modular type inference with local assumptions #### 2012 predictions Instead of qualitative predictions this year, I will [record probabilities](/prediction-market "'Prediction Markets', Branwen 2009") on [PredictionBook.com](https://predictionbook.com/); all predictions assume delivery, but some need different judgment criteria. #. [80%](https://predictionbook.com/predictions/6682) According to the proposal, the core patch index code has already been implemented & benchmarked by the student, who has worked on Darcs before ([flying 9 hours into England](http://blog.darcs.net/2012/04/darcs-hacking-sprint-7-report.html) for a hacking meetup). The rest of the work sounds reasonable, and the project is not overreaching at all. I fully expect this to work out (even if `darcs annotate` is not a command I use every month, much less day). The main risk seems to be life events, but SoCs failing due to personal issues are relatively rare and affect <20% of past projects. This SoC will be judged successful if it is in Darcs HEAD, or at least scheduled for application, by my usual deadline: 2013-01-01. #. [40%](https://predictionbook.com/predictions/6683) No proposal was publicly available. I am not familiar with DMcGill, and Googling for Haskell material related to "McGill", I don't see any past work. It sounds relatively ambitious in the short abstract - replicating `cabal-dev` and adding in considerable other functionality? I've previously noticed that Cabal-related SoCs seem to be unusually blighted. Adding that all up, I am left with dubious feelings. Judgment: tools are always hard to judge. This one will be the usual subjective "is it being used by a good fraction of its potential userbase?" criteria. #. [60%](https://predictionbook.com/predictions/6684) The student has completed a SoC before, and is a graduate student in an AI/machine learning program; both of which bode well for him completing another SoC. I'm not actually sure how many Haskell applications need a concurrent hashtable - the existing [hashtables](https://hackage.haskell.org/package/hashtables) package has [3 users](https://web.archive.org/web/20120425000108/http://packdeps.haskellers.com/reverse/hashtables), and `base`'s "Data.HashTable" module is used by perhaps 10-20 code repositories (judging from grepping through my local archive). It is unreasonable to expect it to supersede `base`, which has had something like a decade to gain users, but equaling the obscure `hashtables` package seems reasonable. Judgment will be whether there are >=3 reverse dependencies. #. [40%](https://predictionbook.com/predictions/6685) As stated, I have no idea what this SoC is about. I don't know the student, although Snoyman seems to write a great deal of code and successful code at that, which is a good sign - if he agreed to mentor it, surely the idea can't be *that* bad? Since I don't know what it is, I cannot specify a judgment criteria in advance. #. [75%](https://predictionbook.com/predictions/6686) Both student & mentor are experienced Haskell hackers, and have worked with the Cabal codebase. As the abstract says, sandboxed builds are not a novel feature. `cabal-dev` is popular among developers, so it stands to reason that a polished version inside Cabal itself would be even more popular. I see little reason this could not be successful, aside from the general challenge of working with Cabal. Judgment; sandboxed build functionality in Cabal HEAD or scheduled to be applied soon. #. [65%](https://predictionbook.com/predictions/6687) Judgment similar to above: patches scheduled for GHC HEAD or already applied. #. [80%](https://predictionbook.com/predictions/6688) Shae is an experienced Haskeller & professional developer (to the extent I was very surprised to hear that he had applied). The proposal seems like a very reasonable addition, and I do not think it is too difficult to modify the `mueval` codebase^[I wrote `mueval` but tryhaskell.org uses a fork which takes expressions over a pipe as opposed to being a one-shot CLI tool.]. Judgment: whether multi-user sessions have gone live. #. [55%](https://predictionbook.com/predictions/6689) Here again I regret the absence of a public proposal. I'm not sure how useful this one is, how hard it is, or how much progress the prototype library [on Hackage](https://hackage.haskell.org/package/haskell-type-exts) represents, nor do I know any comparable libraries I could check for a reverse dependency count. I don't know the student, but Broberg is a capable Haskeller. Judgment criteria: punting to checking for >=3 reverse-dependencies/users. #### 2012 results As of 2013-01-01: #. Darcs patch index Merged into Darcs HEAD without apparent issue ([documentation](https://darcs.net/Ideas/PatchIndex)). Project was **successful**. #. scoutess: As of [August 15](https://projectscoutess.blogspot.com/2012/08/mission-report.html), McGillicuddy was reporting that scoutess was complete ([repository](https://hub.darcs.net/alp/scoutess/changes)). In Haskell-cafe, there is one off-hand mention of scoutess by someone using a different continuous integration program; there are a few discussions on Reddit of progress but the most [recent post](https://www.reddit.com/r/haskell/comments/12lyr3/overveiw_of_current_scoutess_architecture_and/) is a theoretical discussion of scoutess's architecture. There are no tools or libraries depending on it in Hackage because scoutess has never been uploaded to Hackage. Indeed, as far as I can tell, no one is actually using it, and stepcut agreed with this assessment when I asked him. I specified in April 2012 that my judgment criterion would be "is scoutess being used by a good fraction of its potential userbase?"; in this light, scoutess was **unsuccessful**. #. concurrent hashtable/hashmap Edward Kmett tells me that Loren ran into personal issues and was removed from SoC by the midpoint with no delivered library. **Unsuccessful**. #. "Accelerating Haskell Application Development" Edward Kmett tells me that the student left for a job around the midpoint and was removed from SoC at the last milestone. **Unsuccessful**. [eegreg](https://www.reddit.com/r/haskell/comments/15sjur/summer_of_code_2012_retrospective/c7pheka/) argues that while incomplete, the first goal of the SoC (a file-watching library) has since been fulfilled and the library been put to use by the [Yesod ecosystem of Web libraries & applications](https://www.yesodweb.com/). #. Sandboxed builds Completed and in Cabal HEAD; per my criteria, this is **successful**. #. Multiple packages support in GHC The latest information I can find is a [GHC documentation page](https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/g-so-c-multiple-instances) which summarizes the material as: "It is possible to install multiple instances of the same package version with my forks of cabal and ghc. Quite a few problems remain." A [set of slides](https://wiki.haskell.org/wikiupload/5/50/Hiw2012-philipp-schuster.pdf "'Making cabal-install non-destructive'; Philipp Schuster, Andres Loh September 12, 2012") says "Quite a few problems remain therefore nothing is merged yet." The code is not in HEAD for either Cabal or GHC, and given the many problems, may never be. **Unsuccessful**. #. Better tryhaskell.org Erisson [finished in August](https://ghclive.wordpress.com/2012/08/20/ghclive-project-escapes/) with a [Hackage upload](https://hackage.haskell.org/package/ghclive) and some [nice slides](https://web.archive.org/web/20140527112440/http://www.scannedinavian.com/~shae/ghclive.pdf "Web based teaching through real-time collaboration with ghcLiVE"). Unfortunately, there is no live server where one can actually *use* ghcLiVE; someone suggested that Erisson might've given up on the sandboxing aspects which would have made it usable on the public Internet (per his original proposal). One wonders how many people will ever use it, given how much Haskell instruction is done remotely, but maybe it would be useful in offline university classes. In any case, my criterion was clear: "whether multi-user sessions have gone live"; and so despite my high hopes, I must mark this **unsuccessful**. ([Edward Kmett](https://www.reddit.com/r/haskell/comments/15sjur/summer_of_code_2012_retrospective/c7pejlq/) disagrees with this assessment; Erisson sort of agrees and disagrees[^ghcLiVE].) #. Haskell type-checker library This one is a little confusing. The Hackage library remains untouched since April 2012, although there is a [largely complete library](https://cleantypecheck.wordpress.com/2012/09/05/hte-v-haskell-2010-at-github/) (main missing feature is records support, which is important but not a huge gap) available on [Github](https://web.archive.org/web/20140723072149/https://github.com/shayan-najd/HTE). Another [blog post implies](https://cleantypecheck.wordpress.com/2012/09/17/hiw-2012-haskell-suite/) that it is but a small part of a grander research scheme entirely, and that my reverse dependencies judgment criteria is simply off-base entirely although it suggests the SoC was unsuccessful. (The alternative, looking at whether it is pushed to the HEAD of `haskell-type-exts`, would also suggest unsuccessful.) I am not sure whether this should be considered successful or unsuccessful. [^ghcLiVE]: On [Google+](https://plus.google.com/u/0/103530621949492999968/posts/V96rYrcm4jp): > Ah, ghcLiVE isn't designed to have a server hosted, it's designed to run outside a sandbox. Not that I would mark this successful myself, but mostly because it uses Yesod and cabal dependency hell means very few people ended up using it...I'd like to port ghclive to scotty, which has far fewer build dependencies, I think people would actually use it then To summarize: #. unclear: 1 #. successful: 2 #. unsuccessful: 5 2 of the 5 unsuccessful projects were due to problems on the student's end (hashtable, "accelerating"); 2 were too ambitious in general (scoutess, multiple-packages); and the last 1 was not too ambitious but in my opinion was left somewhat incomplete (ghcLiVE). How successful were my predictions? Employing a proper [scoring rule](!W) (log scoring; for additional discussion of scoring rules, see [2012 election predictions](/2012-election)) and comparing against a 50-50 random guesser where >0 means I outperformed the random guesser^[Guessing 50% simplifies the calculation, and isn't too far off: Doing a quick sum of all the non-2012 successful/unsuccessful ratings, I get a chance of being successful at `(4+6+2+3+3+4) / ((4+2+5+1+2+4) + (4+6+2+3+3+4)) = 0.55`, which isn't terribly different from a guess of 0.5.]: ~~~{.Haskell} logBinaryScore = sum . map (\(p,result) -> if result then 1 + logBase 2 p else 1 + logBase 2 (1-p)) logBinaryScore [(0.80, True), (0.40, False), (0.60, False), (0.40, False), (0.75, True), (0.65, False), (0.80, False)] → -0.3693261451031018 ~~~ I performed worse than random, in part because 2012 was such a bad year. In particular, I placed great weight on Erisson succeeding (without that prediction, I would score 0.95). In retrospect, I am also disappointed that I assigned the GHC project a high as 65% when I knew GHC projects are as dangerous as Cabal projects and the multiple packages work was a lot of low-level problems with minimal foregoing work. ### 2013 For [2013](https://web.archive.org/web/20130414061138/http://www.google-melange.com/gsoc/org/google/gsoc2013/haskell), Haskell.org/Darcs picked up a full 11 slots: #. ["Enhancing Darcsden"](https://darcs.net/GSoC/2013-Darcsden); BSRK Aditya, mentored by Ganesh Sittampalam > The goal of this project is to increase the functionality of Darcsden. Darcsden is an open source repository hosting platform for darcs, written in Haskell. The main features are authentication from Github/OpenID, Password Recovery, Editing repository files online, and Comparison between a repository and its forks. #. ["Overloaded record fields for GHC"](https://web.archive.org/web/20140109224018/http://www.google-melange.com/gsoc/project/google/gsoc2013/adamgundry/23001); Adam Gundry, mentored by Simon Peyton Jones > Haskell's record system lacks support for overloaded field names. This leads to unnecessarily cluttered code and inhibits code reuse. I propose to implement support for overloaded field names and polymorphic record projection as a GHC extension, with the aim to ultimately add them to the language standard in a future revision. This relatively straightforward change would remove a significant source of frustration for Haskell programmers....By September 23 I will have the final implementation on a GHC branch ready to merge into HEAD...The biggest risk to the project is that it may prove controversial, as has been seen by arguments over previous attempts to solve this problem. However, I am optimistic that sufficient consensus can be reached, as much of the disagreement is about syntax or implementation details rather than the user-visible aspects of the extension #. ["interactive-diagrams and a paste site with the ability for dynamic rendering of diagrams"](https://web.archive.org/web/20140111064749/http://www.google-melange.com/gsoc/project/google/gsoc2013/difrumin/18001); Dan Frumin, mentored by Luite Stegeman > I want to build an active-diagrams library for compiling diagrams code into active HTML + JS widgets. The diagrams are active in the sense that user can interact with them: for example, a result of type `(Bool -> Diagram)` should be compiled to a widget that renders a diagram depending on the state of the checkbox. In addition, a pastebin site should be built, that can be used as an interactive scratchpad, where diagrams code can be automatically compiled and the graphical output shown along. This is useful for sharing graphical experiments, teaching beginners and so on. The rendered diagram, together with its interactive capabilities, should be easily embedded in third-party blogs, websites. #. ["Haddock extension for Pandoc compatibility"](https://web.archive.org/web/20140109071641/http://www.google-melange.com/gsoc/project/google/gsoc2013/fuuzetsu/16001); Fūzetsu [Mateusz Kowalczyk?], mentored by Simon Hengel ([further discussion](https://mail.haskell.org/pipermail/haskell-cafe/2013-April/107389.html)) > Project aiming to extend Haddock to a point where writing reader and writer modules for Pandoc is possible. The general goal is to allow for documentation writing in different formats, including the ever popular Markdown. #. ["Port Charts to use Diagrams"](https://web.archive.org/web/20140110154958/http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/jbracker/1); jbracker, mentored by Tim Docker > Right now the Charts library uses Cairo as backend. Cairo can be difficult to build on platforms other then Linux. Goal of the project would be to port the Charts library to be independent of the used backend. Like that it can support to use Diagrams as backend. Diagrams supports a variety of backends (SVG, Postscript, Cairo (Optional!), Tikz, Gtk), some of which are written platform independent. As Diagrams is easy to install on every platform supported by Haskell, so will the Charts Library built upon Diagrams. This will make it easy for Haskellers to add charting capabilities to their own applications and libraries in a manner portable across all platforms without any pain. #. ["Better `record` command for darcs"](https://darcs.net/GSoC/2013-BetterRecord); José Neder, mentored by Guillaume Hoffmann > The objective of this project is to improve the `darcs record` command implementing several options...Diffing two given files can produce various correct outputs, depending on the algorithm used. The standard diff algorithm (used in darcs and many other places) has been criticized to sometimes produce counterintuitive diffs. We would like to try out the ["patience diff"](https://www.owenstephens.co.uk/programming/2010/12/24/scala-patience-diff.html) algorithm ([Issue 346](https://bugs.darcs.net/issue346)), which seems to produce more interesting chunks when used on source code. One downside of patience diff is that it may be slower than classic diff, so performance will have to be evaluated. > > Moreover, just as the existing flag `--look-for-adds` proposes adding unversioned files to the new patch, we could use a `--look-for-moves` flag, which would be handful when one wants to record a file move after having done the move, ie, without using `darcs move` ([Issue 642](https://bugs.darcs.net/issue642)). Another cool flag would be `--look-for-replaces`, which would detect token renaming when one forgets about using `darcs replace` ([Issue 2209](https://bugs.darcs.net/issue2209)). > > If time allows, a `--provide-primitive-patches` would be useful for darcs to be called by another program that provides the changes to record. For instance, a web interface providing a simple on-line code edit feature a la GitHub. #. ["Communicating with mobile devices"](https://web.archive.org/web/20140116154458/http://www.google-melange.com/gsoc/project/google/gsoc2013/marcospividori/45001); Marcos Pividori, mentored by Michael Snoyman ([further discussion](https://mail.haskell.org/pipermail/haskell-cafe/2013-May/108038.html "[Haskell-cafe] Google Summer of Code Proposal - Communicating with mobile devices")) > The aim of this project is to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on. And, once we have this libraries, investigate the possibility of maintaining a "back and forth" communication between a server and mobile devices and develop a library to handle this. #. ["Improve the feedback of the cabal-install dependency solver"](https://web.archive.org/web/20140113234236/http://www.google-melange.com/gsoc/project/google/gsoc2013/mr_/23001); Martin, mentored by Andres Löh > The dependency solver can be a mysterious piece of the installation process. I want to give the user the possibility to see what is happening and also give them a better chance to understand what happened if something does not just work. Further, I would like to enable them to use that information to fix the installation in some cases. #. ["Parallelise `cabal build`"](https://web.archive.org/web/20140114015514/http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/refold/71002); Mikhail Glushenkov, mentored by Johan Tibell > This project aims to add support for module-level parallel builds to Cabal, a system for building and packaging Haskell libraries and programs. I suggest a novel solution for this problem in the context of GHC/Cabal that, unlike existing approaches, will make a more effective use of multi-core CPUs. #. ["Extending GHC to support building modules in parallel"](https://web.archive.org/web/20140115123717/http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/parcs/1); Patrick Palka, mentored by Thomas Schilling > The aim of this project is to implement native support for building modules in parallel in GHC. This entails making the compilation pipeline thread-safe, and writing a parallel compilation driver next to the existing sequential driver. Focus will be placed on correctness and deterministic output, with speed a latent concern. Nothing in the user's end should change other than there being a new `-j` flag that specifies the number of modules to build in parallel. The cabal-install project should be augmented with the ability to use this new `-j` flag to speed up builds, alongside its existing package-level parallelization. #. ["Haskell Qt Binding Generator"](https://web.archive.org/web/20140115055711/http://www.google-melange.com/gsoc/project/google/gsoc2013/ofan/44001); Zhengliang Feng, mentored by Carter Schonwald & Ian-Woo Kim > This project aims to provide a generation tool that creating Qt bindings automatically for Haskell and make generation as much automation as possible. It parses Qt header files and generates corresponding Qt-style Haskell interfaces (type classes, data types). The mentor [clarified in August 2013](https://mail.haskell.org/pipermail/haskell-cafe/2013-August/109548.html "[Haskell-cafe] [ANNOUNCE] fficxx: haskell-C++ FFI binding generator"): > Speaking as the principle mentor on the relevant GSOC project (Ian is also co-mentoring, so he can correct me if I'm wrong anywhere): The QT binding project is a *subproject* of the *GSoC project* whose principal focus for the summer is making a swig + fficxx based C++ FFI wrapper for haskell. The GSoC core project is moving apace, and will likely be usable by the close of the summer. Realistically, the QT bit is gold plating / a nontrivial demo use case. Currently its unclear if we'll have time to get the QT ball rolling, but a lot of the support tooling for that subproject should be done by the close of the summer! #### 2013 predictions Compiling the 2006-2012 results, I get an overall base-rate of 47% successful, 40% unsuccessful, & 13% unknown projects. With this base rate in mind, I predicted thusly:
#. Darcsden: [65%](https://predictionbook.com/predictions/20625) #. Overloaded records: [40%](https://predictionbook.com/predictions/20626) #. interactive-diagrams: [35%](https://predictionbook.com/predictions/20627) #. Pandoc Haddock: [55%](https://predictionbook.com/predictions/20628) #. Charts on Diagrams: [75%](https://predictionbook.com/predictions/20629) #. `darcs record: [65%](https://predictionbook.com/predictions/20630) #. mobile push: [25%](https://predictionbook.com/predictions/20631) #. dependency-solver error-messages: [40%](https://predictionbook.com/predictions/20632) #. Parallel build: [33%](https://predictionbook.com/predictions/20633) #. Parallel modules: [33%](https://predictionbook.com/predictions/20634) #. Qt binding generator: [40%](https://predictionbook.com/predictions/20635)
#### 2013 results As of 2014-01-08: #. Darcsden: checking the [Darcsden HEAD](https://hub.darcs.net/simon/darcsden) repository, I see patches by BSRK Aditya adding what looks like GitHub support, a repository comparison feature, resetting passwords, and file editing. I haven't actually verified that the additions are usable, but I have no reason to be that suspicious and so I will mark this SoC **successful**. #. Overloaded record fields for GHC: Gundry finished work on the extension apparently successfully, and submitted his patches in September 2013. The `ghc-devs` mailing list discussion petered out, though, and [in November 2013](https://well-typed.com/blog/84/) Gundry explained: > Unfortunately, the extension will not be ready for GHC 7.8, to allow time for the design to settle and the codebase changes to mature. However, it should land in HEAD soon after the 7.8 release is cut, so the adventurous are encouraged to build GHC and try it out. Feedback from users will let us polish the design before it is finally released in 7.10... Keep an eye out for the extension to land in GHC HEAD later this year, and please try it out and give your feedback! However, GHC 7.8 apparently took longer to release than expected and so Gundry's work still has not been merged by 2014. Duncan Coutts and Gundry both seem optimistic that it would get added *eventually*, but nevertheless, 4 months after being finished, it had not been merged into GHC HEAD and fails my original judgment criterion, rendering it **unsuccessful?** This is definitely a SoC to revisit in the future to check out whether it ultimately got merged in or was abandoned to bitrot. #. Interactive diagrams: Frumin's [summation post](https://parenz.wordpress.com/2013/09/25/gsoc-2013-an-afterword/) links to his working pastebin (`paste.hskll.org`, which went down some years afterwards). I am surprised, but it's definitely there. So, marking this one **successful**. #. Haddock extension for Pandoc compatibility: this SoC was turned into a [rather different project](https://gist.github.com/Fuuzetsu/81253ba7d0c51ac88052); it still involved Haddock, but not Pandoc. Unclear what happened - most of the submitted patches do not seem to have been applied to the Github repository for Haddock. Fuuzetsu tells me in an email on 2014-01-08 that the GHC integration had trouble and this delayed incorporation, but that he was actively working on getting the patches in & was optimistic that they would be "very soon" and "at worst before the end of the week". So this is a very similar situation as Gundry's overloaded record field patches: the work has not been merged into GHC HEAD (technically failing my criterion of "merged by 2014"), but the student is confident that it will be soon and apparently it was merged 2014-01-12 (so I will probably revise the judgment in the future). **Unsuccessful?** #. Port Diagrams to use Charts: the latest version recommends using the Charts backend, and Bracker [declared on `diagrams-discuss`](https://groups.google.com/g/diagrams-discuss/c/p1vDRo6ldWw/m/WNZ5GWvTPVwJ "[GSoC 2013] Porting Charts to Diagrams - Final Report") the project "a full success". Marking **successful**. #. "Better `record` command for darcs": a check of the Darcs HEAD & issue 346 indicates that patience diff made it in, and likewise `--look-for-moves`, so per my criteria of 2 out of 3, marking **successful**. #. "Communicating with mobile devices": I specified in my original prediction the usual default criterion of looking for ≥_n_ reverse dependencies, in this case, ≥3. The author's [blog](https://gsoc2013cwithmobiledevices.blogspot.com/) & [Github repository](https://github.com/MarcosPividori/push-notify) indicate he released a trio of packages; checking the reverse dependencies for [`push-notify`](https://web.archive.org/web/20140114005051/http://packdeps.haskellers.com/reverse/push-notify)/[`push-notify-ccs`](https://web.archive.org/web/20140116190028/http://packdeps.haskellers.com/reverse/push-notify-ccs)/, I see 0 reverse dependencies not to each other (and [Hackage indicates 15 total downloads of `push-notify`](https://hackage.haskell.org/package/push-notify) as of 2014-01-13, suggesting that there's not a lot of demand we're missing by looking at reverse dependencies). Marking **unsuccessful**. #. "Improve the feedback of the cabal-install dependency solver": Ruderer's code appears to have not been merged into Cabal HEAD as of 2014-01-13 and there's nothing on his blog or the `cabal-dev` mailing list indicating any work towards getting the code merged in. **Unsuccessful**. #. "Parallelise `cabal build`": judging from the [bug report discussion](https://github.com/haskell/cabal/issues/976), merging has gotten bogged down in discussion over [pull #1572](https://github.com/haskell/cabal/pull/1572)/[bug #1529](https://github.com/haskell/cabal/issues/1529). Hopefully the work will get merged in, but it has not yet, so this is another **unsuccessful?** #. "Extending GHC to support building modules in parallel": [bug #910](https://gitlab.haskell.org/ghc/ghc/-/issues/910) was closed after the patches were merged in. Looks like parallelizing GHC was *finally* done and I can mark this **successful**! #. "Haskell Qt Binding Generator": a little confusing, but Feng's final submission is a tarball providing some source code and a Cabal file naming it to be `fficxx-swig`; which is not on Hackage at all nor does it have any reverse dependencies. I thought perhaps it was intended to be merged into `fficxx` (written by Feng's co-mentor Kim), but a check of the [`fficxx` contributors](https://github.com/wavewave/fficxx/graphs/contributors) shows only Ian-Woo Kim as author. A google of "fficxx-swig" turned up something more useful, a [`hqt` repository](https://web.archive.org/web/20140723072158/https://github.com/ofan/hqt) by [ofan/Ryan Feng](https://github.com/ofan), which is described as "`hqt` is a set of tools that generate bindings from Qt library to Haskell automatically. The goal of this project is to make an usable and stable tool that can generate bindings for general C++ libraries." Perhaps *this* is what I should be looking at? But `hqt` turns out to also not be on Hackage, not have any reverse dependencies, and not even be mentioned in a google of `hqt site:haskell.org`. (A google of `haskell "hqt"` did turn up an interesting result, though: ["hqt - Haskell Quran Toolkit -- A Haskell library for dealing with Quran texts."](https://github.com/oqc/hqt) How about that?) Given the complete absence of evidence that anyone is using `hqt` in any way, I'm going to have to mark this one **unsuccessful**. The quick overview is 5 successful, 6 unsuccessful, so very similar to historical base-rates. Things get a little rosier when I note that 3 of the unsuccessful and 0 of the successful had to be given question marks because the project seemed to succeed but it was still uncertain whether the work would be integrated with HEAD, so if all 3 get merged, then we'd really have 8 successes and 3 failures, which seems like a reasonable rate. How did my predictions do? The simplest scoring is simply to ask how often I assigned >50% to a success or <50% to a failure; ignoring the question-marks, I then got 8/11. More sophisticated is a log scoring rule taking into account my confidence, and comparing it to a random guesser of 47% (the rough base-rate for success in past years) ~~~{.Haskell} let logScore = sum . map (\(result,p) -> if result then log p else log (1-p)) logScore [(True,0.65), (False,0.40), (True,0.35), (False,0.55), (True,0.75), (True,0.65), (False,0.25), (False,0.40), (False,0.33), (True,0.33), (False,0.40)] → -6.326876860221628 let br = 0.47 in logScore [(True,br), (False,br), (True,br), (False,br), (True,br), (True,br), (False,br), (False,br), (False,br), (True,br), (False,br)] → -7.5843825560059805 ~~~ Since smaller is worse under a log score, I managed to beat the base-rate. What happens if I decide to flip all 3 question-marks into successes (the best-case scenario for them)? ~~~{.Haskell} logScore [(True,0.65), (True,0.40), (True,0.35), (True,0.55), (True,0.75), (True,0.65), (False,0.25), (False,0.40), (True,0.33), (True,0.33), (False,0.40)] → -7.239856330792127 ~~~ I still beat the base-rate but by a trivial amount. The problem here is that while I was accurate enough in predicting on the 2 Darcs-related projects and the FFI one, I gave the Cabal/GHC-related project low probabilities, and them flipping into success punishes my score. As is correct: I *am* surprised that those succeeded, and my predictions reflected my expectations. Was I wrong to be pessimistic about them and to be surprised by their success? Should I have expected them to succeed, perhaps under a theory like "third time's the charm"? Thinking back, I don't think so. I didn't have any particular reason to think that this time would be different, or that a special push was going to be made, or that some critical point had been passed. I think that if one just takes enough whacks at a hard nut, it'll crack eventually, and this year was GHC/Cabal parallelism's time to crack. ### Lessons learned So, what lessons can we learn from the past years of SoCs? It seems to me like there are roughly 3 groups of explanations for failure. They are: #. **Hubris** GuiHaskell is probably a good example; it is essentially a bare-bones IDE, from its description. It is expecting a bit much of a single student in a single summer to write *that*! #. **Unclear Use** HsJudy is my example here. There are already so many arrays and array types in Haskell! What does HsJudy bring to the table that justifies a FFI dependency? Who's going to use it? Pugs initially did apparently, but perhaps that's just because it was there - when I looked at Pugs/HsJudy in 2007, certainly Pugs had no need of it. (The data parallel physics engine is probably another good example. Is it just a benchmark for the GHC developers? Is it intended for actual games? If the former, why is it a SoC project, and if the latter, isn't that a little hubristic?) #. **Lack Of Marketing** One of the reasons Don Stewart's bytestring library is so great is his relentless evangelizing, which convinces people to actually take the effort to learn and use Bytestrings; eventually by network effects, the whole Haskell community is affected & improved[^academic]. Some of these SoC projects suffer from a distinct lack of community buy-in - who used HaskellNet? Who used Hat when it was updated? Indifference can be fatal, and can defeat the point of a project. What good is a library that no one uses? These aren't academic research projects which accomplish their task just by existing, after all. They're supposed to be useful to real Haskellers. [^academic]: Many good and worthwhile projects suffer this fate because of their academic origins. There's no reward for someone who creates a great technique or library and gets the wider community to adopt it as standard. As far as the Haskell community is concerned, one Don Stewart is worth more than a dozen of Oleg Kiselyov; [Oleg's work](https://okmij.org/ftp/) is mindblowingly awesome in both quantity and quality, everyone acknowledges, but how often does anyone actually *use* any of it? ([Iteratees](https://okmij.org/ftp/Streams.html) may be the exception; although there are somewhere upwards of [5 implementations](https://john-millikin.com/software/haskell-enumerator#understanding-iteratees "Understanding Iteratees") as of 2010 by Oleg and others leading to a veritable [Tower of Iteratee](https://ro-che.info/ccc/15.html) situation, the original [iteratee](!Hackage) has picked up [4 reverse dependencies](http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/iteratee#direct), its most popular successor 33 at writing, and iteratees in general may one day become as widely used as bytestrings.) ### Future SoC proposals There are 2 major collections of ideas for future SoC projects, aside from the general frustrations expressed in the [annual survey](https://web.archive.org/web/20111012032953/http://nickknowlson.com/blog/2011/09/12/haskell-survey-categorized-weaknesses/): - The [Haskell proposals](https://www.reddit.com/r/haskell_proposals/top/?t=all) [subreddit](https://web.archive.org/web/20110109074405/http://www.urlesque.com/2011/01/06/whats-a-subreddit-how-reddit-works/), with ideas ranked by popularity - the [Haskell Summer of Code](https://web.archive.org/web/20060620090542/http://hackage.haskell.org/trac/summer-of-code/report/1) [trac](!W) - Johann Tibell: - [2011 suggestions](https://blog.johantibell.com/2011/03/summer-of-code-project-suggestions.html); [2011 acceptances](https://blog.johantibell.com/2011/04/this-years-haskellorg-gsoc-projects.html) - [2013](https://blog.johantibell.com/2013/04/haskellorg-gsoc-ideas.html) - [2014](https://blog.johantibell.com/2014/03/google-summer-of-code-projects.html) Let's look at the first 12 and see whether they're good ideas, bad ideas, or indifferent. #. [port GHC to the ARM architecture](https://www.reddit.com/r/haskell_proposals/comments/7ihso/an_arm_port_of_ghc_that_works_so_we_can_program/): It would be a good thing if we could easily compile our Haskell programs for ARM, which is used in many cellphones, but an even better idea would [using the LLVM backend](https://www.reddit.com/r/haskell_proposals/comments/b7ol7/use_the_llvm_backend_to_turn_ghc_into_a/) to [crosscompile](!W). It would be somewhat tricky, but LLVM already has fairly solid [cross-compilation support](https://web.archive.org/web/20100412152035/http://wiki.llvm.org/HowTo:_LLVM-based_cross_compiler), and making GHC capable of using it seems like a reasonable project for a student to tackle. #. ["Implement overlap and exhaustiveness checking for pattern matching"](https://web.archive.org/web/20100123083943/http://hackage.haskell.org/trac/summer-of-code/ticket/1579): this seems both quite challenging and also a specialized use. I use [GADTs](https://wiki.haskell.org/Generalised_algebraic_datatype) rarely, but I suspect that those writing GADT code rarely make overlap or omission errors. #. [Incremental garbage collection](https://www.reddit.com/r/haskell_proposals/comments/d1ksj/incremental_garbage_collection_so_i_can_make_some/): this *may* be a good idea depending on how much of the code was already written. But I fear that this would go the way of the Immix GC SoC and would be a bad idea. #. ["ThreadScope with custom probes"](https://web.archive.org/web/20100416132315/http://hackage.haskell.org/trac/summer-of-code/ticket/1584): I don't understand the description and can't judge it. #. ["A simple, sane, comprehensive Date/Time API"](https://www.reddit.com/r/haskell_proposals/comments/b8rlh/a_simple_sane_comprehensive_datetime_api/): having puzzled over date-time libraries before, I'm all for this one! It's a well-defined problem, within the scope of a summer, and meets a need. Its only problem is that it doesn't sound sexy or cool. #. ["Combine Threadscope with Heap Profiling Tools"](https://web.archive.org/web/20100416105141/http://hackage.haskell.org/trac/summer-of-code/ticket/1585): Uncertain. Going by the Arch download statistics, Threadscope is downloaded more often than one would expect, so perhaps integration would be useful. #. ["Haddock with embedded wiki feature, a la RWH, so we can collaborate on improving the documentation"](https://www.reddit.com/r/haskell_proposals/comments/7qnwq/haddock_with_embedded_wiki_feature_a_la_rwh_so_we/): This is a bad idea mostly because there are so many diverging ideas and possible implementations - it's just not clear what one would do. Is it some sort of Haddock server? A Gitit wiki with clever hooks? Some lightweight in-browser editor combined with Darcs? #. ["HTTP Library Replacement"](https://web.archive.org/web/20080107023717/http://hackage.haskell.org/trac/summer-of-code/ticket/1122): A good idea, assuming the linked attempts and alternate libraries haven't already solved the issue. #. ["Using Type Inference to Highlight Code *Properly*"](https://www.reddit.com/r/haskell_proposals/comments/biaew/using_type_inference_to_highlight_code_properly/): The difficult part is accessing the type information of an identifier inside a GHCi sessions - a problem probably already solved by [scion](!Hackage). Colorizing the display of a snippet is trivial. So this would make a bad SoC. #. ["Transformation and Optimisation Tool"](https://web.archive.org/web/20080324102704/http://hackage.haskell.org/trac/summer-of-code/ticket/1536): This initially sounds attractive, but previous refactoring tools have been ignored. The tools that have gotten uptake are things like GHC's `-Wall` (which warns about possible semantic issues) and [hlint](!Hackage) (which warns about style issues and redundancy with standard library functions) - not like Hera. #. ["Webkit-based browser written in Haskell, similar in [plugin] architecture to Xmonad"](https://www.reddit.com/r/haskell_proposals/comments/98vxo/webkitbased_browser_written_in_haskell_similar_in/): This is probably the worst single idea in the whole bunch. A web browser these days is an entire operating system, but worse, one in which one must supply and maintain the userland as well; it is a thankless task that will not benefit the Haskell community (except incidentally through supporting libraries), nor a task it is uniquely equipped for. It is an infinite time sink - the only thing worse than this SoC failing would be it succeeding! #. ["Add NVIDIA CUDA backend for Data Parallel Haskell"](https://web.archive.org/web/20080324101857/http://hackage.haskell.org/trac/summer-of-code/ticket/1537): [DPH](!Hawiki "GHC/Data Parallel Haskell") is rarely used; a CUDA backend would be even more rarely utilized; [CUDA](!W) has a reputation for being difficult to coax performance out of; and difficulties would likely be exacerbated by the usual Haskell issues with space usage & laziness. (DPH/CUDA use unboxed strict data, but there are interface issues with the rest of the boxed lazy Haskell universe.) All in all, there are better SoCs[^kamatsu]. [^kamatsu]: Liam O'Connor [begs to](https://www.reddit.com/r/haskell/comments/fid5w/haskell_summers_of_code_retrospective_updated_for/c1gutlo/) [differ](https://www.reddit.com/r/haskell/comments/1v80ld/summer_of_code_2013_retrospective/cepod0s) on the value of a DPH or CUDA SoC, arguing they are definitely unnecessary and even a "terrible" idea. # See Also It's difficult to quantify how 'useful' a package is; it's easier to punt and ask instead how 'popular' it is. There are a few different sources we can appeal to: #. Package downloads: i. Don Stewart provided, for [Arch Linux](!W), Arch download numbers (defunct) ii. The [Debian](https://popcon.debian.org/) (and [Ubuntu](https://popcon.ubuntu.com/)) Popularity Contest offers limited popularity data; eg. [xmonad](https://qa.debian.org/popcon.php?package=xmonad) iii. some 2006-2009 [Hackage statistics](https://galois.com/blog/2009/3/23/one-million-haskell-downloads.html) are available by month & ranking (defunct); live Hackage statistics is an open [bug report](https://github.com/haskell/cabal/issues/155) which will be closed by Matthew Gruen's Hackage 2.0 (2010 SoC) #. [Reverse dependencies](https://web.archive.org/web/20100324194403/https://hackage.haskell.org/trac/hackage/ticket/576) can be examined several ways: i. [Hackage Dependency Monitor](https://web.archive.org/web/20110415182316/http://packdeps.haskellers.com/) iii. [cabal-query](!Hackage) iv. [HackageOneFive](https://github.com/sol/HackageOneFive) #. Searching for mentions, blog posts, and unreleased packages elsewhere; key sites to search include: i. [Haskell subreddit](https://www.reddit.com/r/haskell/) ii. [Github](https://github.com/) iii. [Google Code](https://code.google.com/) iv. `haskell.org`, and specifically the [Haskell wiki](https://wiki.haskell.org/index.php?title=&search=&fulltext=Search) & [mailing lists](https://web.archive.org/web/20110721233821/http://dir.gmane.org/index.php?prefix=gmane.comp.lang.haskell) # External Links - [Haskell wiki](https://wiki.haskell.org/Google_summer_of_code) - ["How to recruit open-source contributors"](https://redmonk.com/dberkholz/2012/07/10/how-to-recruit-open-source-contributors/) -(Gentoo developer Donnie Berkholz on increasing GSoC->regular developer yields) - [Writing a good Haskell SoC application](https://mail.haskell.org/pipermail/haskell-cafe/2013-June/108581.html "[Haskell-cafe] [haskell.org Google Summer of Code 2013] Approved Projects") (by mentor Edward Kmett) - Discussion: - [2009](https://mail.haskell.org/pipermail/haskell-cafe/2009-February/subject.html#55500) - [2010](https://www.reddit.com/r/haskell/comments/fid5w/haskell_summers_of_code_retrospective_updated_for/) - [2011](https://www.reddit.com/r/haskell/comments/n82ln/summer_of_code_2011_retrospective/) - [2012](https://www.reddit.com/r/haskell/comments/15sjur/summer_of_code_2012_retrospective/) - [2013](https://www.reddit.com/r/haskell/comments/1v80ld/summer_of_code_2013_retrospective/)