Summers of Code, 2006-2013

A retrospective of 8 years of SoC, and lessons learned
Haskell, predictions, survey
2009-02-112017-09-22 finished certainty: highly likely importance: 6


A com­pi­la­tion of Haskel­l-re­lated stu­dent projects 2006-2013, with eval­u­a­tions of their use­ful­ness to the Haskell com­mu­ni­ty, thoughts on what makes a good pro­ject, and pre­dic­tions for 2011-2013.

As part of Google’s pro­gram, they spon­sor 5-10 SoC projects for Haskell. The Haskell Sum­mer of Codes have often pro­duced excel­lent results, but how excel­lent is excel­lent? Are there any fea­tures or com­mon­al­i­ties between suc­cess­ful projects or unsuc­cess­ful ones? A ret­ro­spec­tive review of projects sug­gests to me that while many of the Haskell Sum­mer of Code projects have deliv­ered valu­able prod­ucts the Haskell com­mu­nity was in great need of and which have since become widely adopt­ed, a num­ber of them have failed for what likely could have been fore­seen rea­sons: low importance/unclear uses, and over-am­bi­tion.

Example retrospective: Debian

In 2009, a blog­ger & Debian devel­oper wrote a four part ret­ro­spec­tive series on the 2008 Debian Sum­mer of Code pro­jects. The results are inter­est­ing: some projects were a fail­ure and the rel­e­vant stu­dent drifted away and had lit­tle to do with Debian again; and some were great suc­cess­es. I don’t dis­cern any par­tic­u­lar lessons there, except per­haps one against hubris or fill­ing unclear needs. I decided to com­pile my own series of ret­ro­spec­tives on the Haskell Sum­mers of Code.

Judging Haskell SoCs

Google describes SoC as

“…a global pro­gram that offers stu­dents stipends to write code for open source pro­jects. We have worked with the open source com­mu­nity to iden­tify and fund excit­ing projects for the upcom­ing sum­mer.”

or

“…a global pro­gram that offers stu­dent devel­op­ers stipends to write code for var­i­ous open source soft­ware pro­jects. We have worked with sev­eral open source, free soft­ware, and tech­nol­o­gy-re­lated groups to iden­tify and fund sev­eral projects over a three month peri­od. Since its incep­tion in 2005, the pro­gram has brought together over 4500 suc­cess­ful stu­dent par­tic­i­pants and over 3000 men­tors from over 100 coun­tries world­wide, all for the love of code. Through Google Sum­mer of Code, accepted stu­dent appli­cants are paired with a men­tor or men­tors from the par­tic­i­pat­ing pro­jects, thus gain­ing expo­sure to real-world soft­ware devel­op­ment sce­nar­ios and the oppor­tu­nity for employ­ment in areas related to their aca­d­e­mic pur­suits. In turn, the par­tic­i­pat­ing projects are able to more eas­ily iden­tify and bring in new devel­op­ers. Best of all, more source code is cre­ated and released for the use and ben­e­fit of all.”

It is intended to pro­duce source code for the ‘use and ben­e­fit of all’; it is not meant to pro­duce aca­d­e­mic papers, code curiosi­ties, for­got­ten blog posts, ground­work for dis­tant pro­jects, but ‘excit­ing’ new pro­duc­tion code. This is the per­spec­tive I take in try­ing to assess SoC pro­jects: did it ship any­thing? If stand­alone, are the results in active use by more than a few devel­op­ers or other code­bas­es? If a mod­i­fi­ca­tion to an exist­ing code­base, was it merged and now is actively main­tained1? And so on. Ster­ling Clover argues that this is far too demand­ing and does not con­sider whether an involved stu­dent is ener­gized by his con­tri­bu­tion to go on and con­tribute still more2; I dis­agree about the for­mer, and I have not done the lat­ter because it would be too labor-in­ten­sive to track down every stu­dent and assess their later con­tri­bu­tions, which would involve still more sub­jec­tive appraisals3. (Per­haps in the future I or another Haskeller will do that.)

Haskell retrospective

Haskell was­n’t part of the first Sum­mer of Code in 2005, but it was accepted for 2006. We start there

2006

The 2006 home­page lists the fol­low­ing pro­jects:

4 suc­cess­ful; 2 unsuc­cess­ful; and 2 fail­ures.

2007

The 2007 home­page lists:

6 suc­cess­es; 2 unsuc­cess­ful; 1 unknown.

See Also

2008

The 2008 home­page isn’t kind enough to list all the pro­jects, but it does tell us that only 7 projects were accepted by Google.

So we can work from the code.­google.­com page which lists 6:

  • “C99 Parser/Pretty-Printer”; by Benedikt Huber, men­tored by Iavor Diatchki

    Suc­cess­ful. The first try failed, but the sec­ond won through, and now peo­ple are doing things like pars­ing the Linux ker­nel with it.

  • “GMap - Fast com­pos­able maps”; by Jamie Bran­don. men­tored by Adrian Charles Hey

    Unsuc­cess­ful. GMap is on Hack­age, but there are 0 users after 3 years.

  • “Haskell API Search”; Neil Mitchell, men­tored by Niklas Broberg

    Suc­cess­ful. The improved per­for­mance and search capa­bil­ity have made it into Hoogle releas­es, and Hoogle is one of the more pop­u­lar Haskell appli­ca­tions (with 1.7m web searches).

  • “Cabal ‘make-like’ depen­dency frame­work”; Andrea Vez­zosi, men­tored by Dun­can Coutts

    Unsuc­cess­ful. (His code wound up becom­ing hbuild, which is not on Hack­age or appar­ently used by any­one.)

  • GHC plu­g­ins”; Max­i­m­il­ian Con­roy Bol­ing­broke, men­tored by Sean Seefried

    Unsuc­cess­ful? As of Jan­u­ary 2010, the patch adding plu­g­ins func­tion­al­ity has yet to be accepted & applied; as of Feb­ru­ary 2011, the ticket remains open and the code unmerged. The code is appar­ently not yet bitrot­ten by the pas­sage of 3 years but how long can its luck last? The code was finally merged in 2011-08-04; the docs do not list any users.

  • “Data par­al­lel physics engine”; Roman Chep­lyaka, men­tored by Manuel M. T. Chakravarty

    Unsuc­cess­ful. It seems to be fin­ished but no use made of the actual engine that I can see men­tioned on the engine’s blog. (I would give reverse depen­dency sta­tis­tics, but Hpysics seems to have never been uploaded to Hack­age.)

  • GHC API”; Thomas Schilling, men­tored by Simon Mar­low

    Unsuc­cess­ful. Schilling’s fixes went in, but they were in gen­eral minor changes (like adding the GHC mon­ad) or bug-fix­es; the GHC API remains a mess.

2 suc­cess­ful, 5 unsuc­cess­ful.

Don Stewart’s view

Don Stew­art writes in reply to the fore­go­ing:

"We explic­itly pushed harder in 2008 to clar­ify and sim­plify the goals of the pro­jects, ensure ade­quate prior Haskell expe­ri­ence and to focus on libraries and tools that directly ben­e­fit the com­mu­ni­ty.

And our suc­cess rate was much high­er.

So: look for things that ben­e­fit the largest num­ber of Haskell devel­op­ers and users, and from stu­dents with proven Haskell devel­op­ment expe­ri­ence. You can’t learn Haskell from zero on the job, dur­ing SoC."

See Also

2009

5 projects were accepted this year; Darcs tried to apply in its own right was reject­ed.

In gen­er­al, these looked good. Most of them will be widely use­ful – espe­cially the Darcs and Had­dock SoCs – or address long­stand­ing com­plaints (many crit­i­cisms of lazi­ness revolve around how unpre­dictable it makes mem­ory con­sump­tion). The only one that both­ers me is the EclipseFP pro­ject. I’m not sure Eclipse is com­mon enough among Haskellers or poten­tial Haskellers to war­rant the effort5, but at least the project is focused on improv­ing an exist­ing plu­gin than writ­ing one from scratch. The 5 were:

3 suc­cess­ful, 1 unknown, 1 unsuc­cess­ful.

2010

7 projects were accept­ed:

  • Improve­ments to Cabal’s test sup­port; Thomas Tuegel, men­tored by Johan Tibell

    Suc­cess­ful? The func­tion­al­ity is now in a released ver­sion of cabal-install and a num­ber of pack­ages use the pro­vided test syn­tax.6

  • Infra­struc­ture for a more social Hack­age 2.0; Matthew Gru­en, men­tored by Edward Kmett

    Unknown. Gru­en’s blog was last updated Octo­ber 2010, and Hack­age still has­n’t switched over and got­ten the new fea­tures & ben­e­fit of the rewrite. But the code exists and there is a run­ning pub­lic demo, so this may yet be a suc­cess.

  • A high per­for­mance HTML gen­er­a­tion library; Jasper Van der Jeugt, men­tored by Simon Meier

    Suc­cess­ful blaze-html has been released and is actively devel­oped; ver­sion 0.4.0.0 has 50 total reverse depen­den­cies and blaze-builder has 97 reverse depen­den­cies though there’s much over­lap. (This site is built on hakyll, which uses blaze-htm­l.)

  • Improve­ments to the GHC LLVM back­end; Alp Mes­tanogullari, men­tored by Max­i­m­il­ian Bol­ing­broke

    Unsuc­cess­ful. Dan Pee­bles in #haskell says that Alp’s SoC never got off the ground when his com­puter died at the begin­ning of the sum­mer; with noth­ing writ­ten or turned in, this can’t be con­sid­ered a suc­cess­ful SoC, exact­ly. But could it have been?

    The LLVM back­end is still on track to become the default GHC back­end7, sug­gest­ing that it’s pop­u­lar in GHC HQ (and the DDC dialec­t), and it seems to also be pop­u­lar among Haskell blog­gers. The scope is restricted to tak­ing a work­ing back­end and opti­miz­ing it. In gen­er­al, it seems like a decent SoC pro­pos­al, and bet­ter than the next one:

  • Imple­ment­ing the Immix Garbage Col­lec­tion Algo­rithm; Marco Túlio Gon­tijo e Sil­va, men­tored by Simon Mar­low

    Unsuc­cess­ful. The GHC repos­i­tory his­to­ry, as of 4 Feb­ru­ary, con­tains no patches adding Immix GC. Silva writes in his blog’s SoC sum­mary that “Although the imple­men­ta­tion is not mature enough to be included in the repos­i­to­ry, I’m happy with the state it is now. I think it’s a good start, and I plan to keep work­ing on it.” (His new blog, begun in August 2010, con­tains no men­tion of Immix work.) The GHC wiki says that “it’s func­tion­al, does­n’t have known bugs and gets bet­ter 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 Dis­qus com­ment on this page:

    Hi. I won­dered about con­tin­u­ing my work on the Immix GC col­lec­tor, but Simon Mar­low, my men­tor, thought it was not a good idea to invest more effort on Immix. So I dropped it, and started work­ing on other things. Greet­ings.

  • “Improv­ing Darcs Per­for­mance”; Adolfo Builes, men­tored by Eric Kow

    Suc­cess­ful. This replaced a pre­vi­ous pro­posal to write a Haskell bind­ing to the library, which never start­ed. Look­ing through the Darcs repos­i­tory his­to­ry, I see a num­ber of new tests related to the global cache, but no major edits to cache-re­lated mod­ules. The Darcs wiki reports it as a suc­cess­ful and clos­ing some bugs.

  • Improv­ing Darc­s’s net­work per­for­mance; Alexey Lev­an, men­tored by Petr Rockai

    Suc­cess­ful. Levan divided his SoC into 2 parts, improv­ing Darc­s’s per­for­mance in fetch­ing the many small files that make up a repos­i­to­ry’s revi­sion his­to­ry, and writ­ing ‘a smart server that can pro­vide clients with only files they need in one request’. The ‘smart server’ seems to have been aban­doned as not being worth­while, but the fetch­ing idea was imple­mented and will be in the 2.8 release.

    The basic idea is to com­bine all the small files into a sin­gle which can be down­loaded at full speed, and avoid the latency of many roundtrips. The 2.8 release descrip­tion claims that when darcs optimize --http was used on the Darcs repos­i­to­ry, a full down­load went from 40 min­utes to 3 min­utes. This fea­ture would not be enabled by default, but the gain for larger repos­i­to­ries would be large enough that I feel com­fort­able clas­si­fy­ing it as a suc­cess­ful SoC.

Predicting 2010 results

Bor­row­ing from our 3 car­di­nal sins of SoCs, and per my usual prac­tice of test­ing my under­stand­ing by mak­ing pre­dic­tions, what pre­dic­tions do I make about the 2010 SoCs?

Most of the 7 SoCs are laud­ably focused on an exist­ing appli­ca­tion. You don’t need to jus­tify a speedup of nor­mal Darcs oper­a­tions because there’s an installed base of Darcs users that will ben­e­fit; a new GC for GHC or a LLVM back­end will ben­e­fit every Haskeller; bet­ter Cabal sup­port for test­ing may go unused by many pack­age authors who either have no tests or don’t want to bother - but a fair num­ber will both­er, and it will get main­tained as part of Cabal, and sim­i­larly for the Hack­age 2.0 pro­ject.

The Immix GC strikes me as a very chal­leng­ing sum­mer pro­ject; a GC is one of the most low-level pieces of a func­tional lan­guage and is inter­twined with all sorts of code and con­sid­er­a­tions. It would not sur­prise me if that project wound up just get­ting a lit­tle closer to a work­ing Immix GC but not pro­duc­ing a pro­duc­tion-qual­ity GC sched­uled to come to com­pil­ers near you.

2 in par­tic­u­lar con­cern me as poten­tially falling prey to sins #2 & 3: the GOb­jec­t-binder tool, and the high­-per­for­mance HTML library:

  1. Let’s assume that the HTML library does wind up as being faster than exist­ing libraries, and as use­ful - that com­pro­mises don’t destroy its util­i­ty. Who will use it? It will almost surely have an API differ­ent enough from exist­ing libraries that a con­ver­sion will be painful. There are roughly 42 users of the exist­ing xhtml-gen­er­at­ing library; will their authors wish to embrace a cut­ting-edge infant library? Is HTML gen­er­a­tion even much of a bot­tle­neck for them? (Speak­ing just for Gitit, Pan­doc and its HTML gen­er­a­tion are not usu­ally a bot­tle­neck.)
  2. The case against the GOb­ject project makes itself; GTK2Hs isn’t as widely used as one would expect, and this seems to be due to the diffi­culty of instal­la­tion and its gen­eral com­plex­i­ty. So there are few users of exist­ing libraries; would there be more users for those libraries no one has both­ered to bind nor yet clam­ored for? (This project might fall afoul of sin #1, but I do not know how diffi­cult the GOb­ject data is to inter­pret.)

2010 results

As of Feb­ru­ary 2010, I grade the 7 SoC for 2010 as fol­lows: 4 suc­cess­es, 1 unknown, and 2 unsuc­cess­ful. (One unknown, Hack­age 2.0, will prob­a­bly turn out to be a suc­cess if it ever goes live as the main Hack­age site; as of 2013-01-01, it has not.) As one would hope, the results seem to be bet­ter than the results for 2008 or 2009.

Of my orig­i­nal pre­dic­tions, I think I was right about the Immix GC & GOb­ject & Darcs opti­miza­tions, semi­-right about Hack­age 2.0 & Cabal test­ing sup­port, some­what wrong about the LLVM work, and com­pletely 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 pre­dict­ing the fail­ure of the LLVM SoC.)

2011

Haskel­l.org got 7 projects again for 2011. They are:

  1. “Improve EclipseFP”; Ale­jan­dro Ser­ra­no, men­tored by Thomas Schilling

    "Eclipse is one of the most pop­u­lar IDEs in our days. EclipseFP is a project devel­op­ing a plug-in for it that sup­ports Haskell. Now, it has syn­tax high­light­ing, inte­gra­tion of GHCi and sup­ports some prop­er­ties of Cabal files. My idea is to extend the set of tools avail­able, at least with:
    • Auto­com­ple­tion and bet­ter links to doc­u­men­ta­tion,
    • A way to run unit tests within Eclipse,
    • More sup­port for edit­ing Cabal files visu­al­ly, includ­ing a browser of the avail­able pack­ages."
  2. “Sim­pli­fied OpenGL bind­ings”; Alexan­der Göransson, men­tored by Jason Dagit

    “Mod­ern­ize and sim­plify OpenGL bind­ings for Haskell. Focus on safe­ty, shaders and sim­plic­i­ty.”

  3. “Inter­preter Sup­port for the Cabal-In­stall Build Tool”; ankle­saria, by Dun­can Coutts

    “This project aims to pro­vide cabal-in­stall with an ‘’ [cabal ghci?] com­mand by adding to the Cabal API. This would allow pack­age devel­op­ers to use GHCi and Hugs from within pack­ages requir­ing options and pre­pro­cess­ing from Cabal.”

  4. “Con­vert the text pack­age to use UTF-8 inter­nally”; Jasper Van der Jeugt, by Edward Kmett (detailed pro­posal)

    "For Haskell projects han­dling Uni­code text, the text library offers both speed and sim­plic­i­ty-of-use. When it was writ­ten, bench­marks indi­cated that UTF-16 would be a good choice for the inter­nal encod­ing in the library. How­ev­er, these (rather arti­fi­cial) bench­marks 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 pro­pose to
    1. bench­mark and
    2. con­vert the library to UTF-8 if it is a faster choice for ‘Real World’-ap­pli­ca­tion­s."
  5. “Build mul­ti­ple Cabal pack­ages in par­al­lel”; Mikhail Glushenkov, by Johan Tibell

    “Cabal is a sys­tem for build­ing and pack­ag­ing Haskell libraries and pro­grams. This pro­jec­t’s aim is to aug­ment Cabal with sup­port for build­ing pack­ages in par­al­lel. Many devel­op­ers have mul­ti­-core machi­nes, but Cabal runs the build process in a sin­gle thread, only mak­ing use of one core. If the build process could be par­al­lelized, build times could be cut by per­haps a fac­tor of 2-8, depend­ing on the num­ber of cores and oppor­tu­nity of par­al­lel exe­cu­tion avail­able.”

  6. “Darcs Bridge”; Owen Stephens, by Ganesh Sit­tam­palam

    “My pro­posed project is to cre­ate a generic bridge that will enable easy inter­op­er­abil­ity and syn­chro­ni­sa­tion between Darcs and other VCSs. The bridge will be designed to be gener­ic, but the focus of this project will be Darcs2 ↔︎ Git and Darcs2 ↔︎ Darc­s1. The bridge should allow loss-less, cor­rect con­ver­sion to and from Darcs repos­i­to­ries, allow­ing users to use the tool that suits them and their project best, be that Darcs as it cur­rently exists, or another tool.”

  7. “Darcs: prim­i­tive patches ver­sion 3” (expanded blog descrip­tion); Petr Ročkai, by Eric Kow

    “Darcs, a revi­sion con­trol sys­tem, uses so-called patches to rep­re­sent changes to indi­vid­ual ver­sion-con­trolled files, where the ‘prim­i­tive’ patches are the low­est level of this rep­re­sen­ta­tion, cap­tur­ing notions like ‘hunks’ (akin to what diff(1) pro­duces), token replace and file and direc­tory addition/removal. I pro­pose to imple­ment a differ­ent rep­re­sen­ta­tion of these prim­i­tive patch­es, hop­ing to improve both per­for­mance and flex­i­bil­ity of darcs and to facil­i­tate future devel­op­ment.”

Predicting 2011 results

Which seem like good selec­tions for SoC, and which seem less appro­pri­ate?

  1. #1 is the sec­ond EclipseFP SoC, after a failed 2009 attempt; why should we think this one will do bet­ter?

  2. With #2, the fear is that the result will not be used; there is an OpenGL bind­ing already, after all, and I haven’t heard that there are very many peo­ple who want to do OpenGL graph­ics but were deterred by com­plex­ity or dan­ger in it.

  3. cabal ghci is a long-re­quested Cabal fea­ture, and it sounds as if all the ground­work and exper­i­men­ta­tion has been done. I have no prob­lem with this one.

  4. Bench­mark­ing sounds quite doable, and text is increas­ingly used; but if I had to crit­i­cize it, I would crit­i­cize it for underambi­tion, for sound­ing too mod­est and not a good use of a slot.

  5. #5 is a sec­ond crack at the par­al­lel com­pi­la­tion prob­lem (build­ing on a 2008 SoC) and is trou­bling in the same way the EclipseFP SoC is.

  6. There are mul­ti­ple exist­ing Darc­s->other VCS pro­grams, so the task is quite doable. An escape hatch would be very valu­able for users (even if rarely used).

  7. This one sounds tremen­dously spec­u­la­tive to me.

    I respect Ročkai & Kow, but in idling on #darcs and read­ing the occa­sional Darc­s-re­lated emails & Red­dit posts, I don’t know of any fully worked out design for said patch design, which makes it a chal­leng­ing the­o­ret­i­cal prob­lem (patch the­ory being gen­eral & pow­er­ful), a major imple­men­ta­tion issue (since the exist­ing prim­i­tive patches are nat­u­rally assumed all through­out the Darcs code­base), and diffi­cult to ver­ify that it will not back­fire on users or legacy repos­i­to­ries. All in all, #7 sounds like the sort of project where the best case sce­nario is a repos­i­tory branch/fork some­where that few besides the author under­stands, which is bet­ter on some use­cases and worse on oth­ers, but not actu­ally in gen­eral use. That might be a suc­cess by the Darc­s’s team’s lights, but not in the sense I have been using in this his­to­ry.

To sum­ma­rize my feel­ings:

  • #1 seems a bit doubt­ful but is more likely to suc­ceed (be­cause pre­sum­ably most of the heavy lift­ing was done pre­vi­ous­ly).
  • I pre­dict #2 & #7 will likely fail
  • I would be mildly sur­prised if both #3 & #5 suc­ceed - since they’re chal­leng­ing and long-re­quest Cabal fea­tures - but I expect at least one of them to suc­ceed. Which, I am not sure.
  • I expect with con­fi­dence that #4 & #6 will suc­ceed.

2011 results

  1. “Improve EclipseFP”; Ale­jan­dro Ser­ra­no, men­tored by Thomas Schilling

    Suc­cess­ful. The cod­ing was fin­ished, to the author’s appar­ent sat­is­fac­tion, and the work was included in the 2.1.0 release.

  2. “Sim­pli­fied OpenGL bind­ings”; Alexan­der Göransson, men­tored by Jason Dagit

    Unsuc­cess­ful. Jason Dagit says Alexan­der never started for unknown per­sonal rea­sons and so no work was ever done (no OpenGLRawNice library exists, a post-Au­gust 2011 Google search for “Alexan­der Görans­son OpenGL” is dry, noth­ing on Hack­age seems to men­tion OpenGL 4.0 sup­port, etc.).

  3. “Inter­preter Sup­port for the Cabal-In­stall Build Tool”; ankle­saria, by Dun­can Coutts

    Unsuc­cess­ful? ankle­sari­a’s final post, “End­ing GSoC”, says the work is done and pro­vide a repos­i­tory with patches by amsay@amsay.net - but no patches by that email appear in the Cabal repos­i­tory as of 2011-12-10; nor does there appear to be any dis­cus­sion in the cabal-dev ML archives.

  4. “Con­vert the text pack­age to use UTF-8 inter­nally”; Jasper Van der Jeugt, by Edward Kmett

    Suc­cess­ful. Jasper pub­lished 2 posts on bench­mark­ing the con­verted text against the orig­i­nal (“Text/UTF-8: Ini­tial results” & “Text/UTF-8: Study­ing mem­ory usage”); dis­cussing the results in “Text/UTF-8: After­math”, the upshot is that the con­ver­sion has a real but small advan­tage, poten­tially would cause inter­op­er­abil­ity prob­lems, requires con­sid­er­able test­ing, and won’t be merged in (the fork will be main­tained against hopes of future GHC opti­miza­tion­s). Jaspers says the ben­e­fits wound up being a big­ger & cleaner test/benchmark suite, and some opti­miza­tions made for the UTF-8 ver­sion can be applied to the orig­i­nal. Since Edward Kmett seems pleased, I have marked it a suc­cess (although I remain dubi­ous about whether it was a good SoC).

  5. “Build mul­ti­ple Cabal pack­ages in par­al­lel”; Mikhail Glushenkov, by Johan Tibell

    Suc­cess­ful Glushenkov reported in “Par­al­lelis­ing cabal-in­stall: Results” that the patches were done and peo­ple could play with his repos­i­to­ry; the com­ments report that it works and does offer speedups. How­ev­er, as before, no patch by him appears in the main­line Cabal, and the last dis­cus­sion was 2011-11-06 where he pro­vides a patch bun­dle. No one com­ment­ed; Mikhail says the patches may be “too inva­sive” and need rework­ing before merg­ing.8 The code was ulti­mately released as part of cabal-in­stall 1.16 and is report­edly work­ing well.

  6. “Darcs Bridge”; Owen Stephens, by Ganesh Sit­tam­palam

    Suc­cess­ful? Owen’s GSoC blog posts con­clude with “GSoC: Darcs Bridge - Results” sum­ma­riz­ing the final fea­tures: he suc­ceeded in most of the func­tion­al­i­ty. Brent Yorgey tells me that he has suc­cess­fully used the tool to con­vert repos­i­to­ries to put onto Github, but says there are “some crit­i­cal bugs” and use is still “clunky” (eg. cur­rently requir­ing Darcs HEAD; see the usage guide on the Darcs wiki). Whether the bugs will be fixed and the pack­age pol­ished to the point where it will be widely used remains to be seen.

  7. “Darcs: prim­i­tive patches ver­sion 3”; Petr Ročkai, by Eric Kow

    Unsuc­cess­ful. Ročkai wrote two posts (“soc reload­ed: progress 1” & “soc reload­ed: Out­comes”). This seems to have turned out as I pre­dicted above:

    “Since my last report, I have decided to turn some­what more rad­i­cal again. The orig­i­nal plan was to stick with the darcs code­base and do most (all) of the work within that, based pri­mar­ily on writ­ing tests for the test­suite and not expos­ing any­thing of the new func­tion­al­ity in a user-vis­i­ble fash­ion. I changed my mind about this. The main rea­son was that the test envi­ron­ment, as it is, makes cer­tain prop­er­ties hard to express: a typ­i­cal test-suite works with asser­tions (HU­nit) and invari­ants (QuickCheck). In this envi­ron­ment, express­ing ideas like ‘the dis­played patches are aes­thet­i­cally pleas­ing’ or ‘the files in the repos­i­tory have rea­son­able shape’ is imprac­ti­cal at best. An alter­na­tive would have been to make myself a play­ground using the darcs library to expose the new code. But the fact is, our cur­rent code­base is entrenched in all kinds of legacy issues, like han­dling file­names and dupli­cated code. It makes the exper­i­menter’s life harder than nec­es­sary, and it also involves rebuild­ing a whole lot of code that I never use, over and over. All in all, I made a some­what bold deci­sion to cut every­thing that lived under Darcs.Patch (plus a few depen­den­cies, as few as pos­si­ble) into a new library, which I named patchlib, in the best tra­di­tion of cmdlib, pathlib and fslib. At that point, I also removed cus­tom file path han­dling from that por­tion of code, removed the use of a cus­tom Printer (a pret­ty-printer imple­men­ta­tion) mod­ule and a made few other incom­pat­i­ble changes.”

    The remain­ing work?

    "The obvi­ous future work lies in the con­flict han­dling. There are two main options in this regard: either re-engi­neer a patch-level, com­mute-based rep­re­sen­ta­tion of con­flicts (in the spirit of merg­ers and con­flic­tors), as V3 ‘com­pos­ite’ patch­es, or alter­na­tive­ly, use a non-patch based mech­a­nism for track­ing con­flicts and res­o­lu­tions. It’s still some­what early to decide which is a bet­ter choice, and they come with differ­ent trade-offs. Nev­er­the­less, the deci­sion, and the imple­men­ta­tion, con­sti­tute a major step towards darcs 3. The other major piece of work that remains is the repos­i­tory for­mat: in this area, I have done some research in both the pre­vi­ous and this year’s pro­ject, but there are no defin­i­tive answers, even less an imple­men­ta­tion. I think we now have a num­ber of good ideas on how to approach this. We do need to sort out a few issues though, and the deci­sion on the con­flict layer also influ­ences the shape of the repos­i­to­ry.

    Each of these two open prob­lems is prob­a­bly about the size of an ambi­tious SoC pro­ject. On top of that, a lot of inte­gra­tion work needs to hap­pen to actu­ally make real use of the advance­ments. We shall see how much time and resources can be found for advanc­ing this cause, but I am rel­a­tively opti­mistic: the prim­i­tive level has turned out fairly well, and to me it seems that shed­ding the shack­les of legacy code sprawl can boost the project as a whole sig­nifi­cantly for­ward."

    As I wrote before, the Darcs team will dis­agree with my assess­ment, but I believe mark­ing it ‘Unsuc­cess­ful’ is most con­sis­tent with how all pre­vi­ous SoCs have been judged9.

So of the 7 2011 SoCs:

  • 3 were unsuc­cess­ful (2 pos­si­bly not)
  • 4 were suc­cess­ful (1 pos­si­bly not)

My pre­dic­tions were in gen­eral accu­rate; I remained hope­ful that at least one of the Cabal SoCs would be merged in, which would give me a clean sweep and also ren­der the final 2011 SoC record as good as the 2010 SoC record. (The par­al­lel build was even­tu­ally merged in dur­ing 2012.)

It trou­bles me that the Cabal SoCs took so long to be merged in (if at all), in line with the his­tor­i­cal trend for big Cabal SoC improve­ments to be par­tially done but never go into pro­duc­tion. Dun­can Coutts says they are in the queue, but if nei­ther gets merged in before the 2012 SoC starts, the les­son seems to be that Cabal is too dan­ger­ous and uncer­tain to waste SoCs on.

2012

In 2012, Haskel­l.org was bumped to 8 slots:

  1. “Patch Index Opti­miza­tion for Darcs” (pro­posal); BSRK Aditya, men­tored by Eric Kow

    The goal of this project is to speed up the darcs changes and darcs anno­tate com­mands using a cache called “patch index”. The slow speed of these com­mands is one of the major user griev­ance in darcs. Patch-In­dex data struc­tures can quickly iden­tify the patches that mod­i­fied a given file.

  2. “Scout­ess - a build man­ager for cabal projects”; DMcGill, men­tored by Alp Mes­tanogullari

    Scout­ess is a tool for pack­age main­tain­ers and auto­mates a lot of the has­sle of deal­ing with depen­den­cies and mul­ti­ple ver­sions of libraries. It will cre­ate a sand­boxed envi­ron­ment sim­u­lat­ing a fresh Haskell Plat­form install, attempt to build your project using Cabal and high­light any prob­lems while also track­ing changes or updates to depen­den­cies located in remote repos­i­to­ries so these can be tested against as well.

  3. “Imple­ment Con­cur­rent Hash-table / Hash map” (pro­posal); Loren Davis, men­tored by Ryan New­ton

    Con­cur­rent data struc­tures for Haskell are cur­rently a work in pro­gress, and are nec­es­sary for par­al­lel and high­-per­for­mance com­put­ing. A few data struc­tures, such as wait­-free lists, already have Haskell imple­men­ta­tions. One that does not yet is a thread­-safe hash table. I pro­pose to imple­ment one as a library avail­able under the new BSD license.

  4. “Accel­er­at­ing Haskell Appli­ca­tion Devel­op­ment”; mdittmer, men­tored by Michael Snoy­man

    A project for improv­ing per­for­mance of “lively devel­oper mode” envi­ron­ments that require fast rebuild-and-re­de­ploy rou­tines.

  5. “Sand­boxed builds and iso­lated envi­ron­ments for Cabal”; Mikhail Glushenkov, men­tored by Johan Tibell

    The aim of this project is to inte­grate sup­port for sand­boxed builds into Cabal, a sys­tem for build­ing Haskell pro­jects. There are sev­eral differ­ent third-party imple­men­ta­tions of this func­tion­al­ity already avail­able, but it would be ben­e­fi­cial (from the points of ease of use and focus­ing the com­mu­nity efforts) to have a uni­fied and pol­ished solu­tion inte­grated into Cabal itself. Addi­tion­al­ly, this project is a step in the direc­tion of solv­ing the infa­mous “depen­dency hell” prob­lem of Cabal.

  6. “Enable GHC to use mul­ti­ple instances of a pack­age for com­pi­la­tion” (pro­posal); Philipp Schus­ter, men­tored by Andres Löh

    Peo­ple are run­ning into depen­dency hell when installing Haskell pack­ages. I want to help move in the direc­tion of solv­ing it.

  7. “multi­user browser-based inter­ac­tive ghci, hpaste.org meets try­haskel­l.org, for improved teach­ing of those new to Haskell.” (pro­posal); Shae Eris­son, men­tored by Hein­rich Apfel­mus

    Many new users learn Haskell from the #haskell IRC chan­nel. lambdabot’s mueval is good for inter­ac­tive teach­ing, but only allows short code snip­pets. hpaste allows large snip­pets to be shared, but not into an inter­ac­tive ghci. Chris Done’s Try Haskell! allows larger snip­pets to be load­ed, but is not explic­itly mul­ti­-user. If Try Haskell! allowed mul­ti­ple users to view the same inter­preter state, and allowed users to paste in new code, teach­ing and debug­ging would be much eas­ier for peo­ple new to Haskell.

  8. “Haskel­l-Type­-Exts”; Shayan Najd, men­tored by Niklas Broberg

    Fol­low­ing the pro­posal by Niklas Broberg [0], I am highly eager to expand the exist­ing type­checker [1] for Haskel­l-S­r­c-Exts [2] to sup­port most of the fea­tures avail­able in Haskell 2010 with the major exten­sions like GADTs, RankN­Types and Type­-Func­tions. It is done by fol­low­ing the guide­lines of “Typ­ing Haskell in Haskell” [3] as the basis; adding sup­port for RankN­Types [5]; and then intro­duc­ing GADTs and Type­-Func­tions by local assump­tions [4]. [0] http://hackage.haskell.org/trac/summer-of-code/ticket/1620 [1] http://hackage.haskell.org/package/haskell-src-exts [2] http://hackage.haskell.org/package/haskell-type-exts [3] M. P. Jones. Typ­ing Haskell in Haskell [4] D. Vytin­i­o­tis, S. Pey­ton Jones, T. Schri­jvers, M. Sulz­mann. Out­sideIn(X) - Mod­u­lar type infer­ence with local assump­tions

2012 predictions

Instead of qual­i­ta­tive pre­dic­tions this year, I will on Pre­dic­tion­Book.­com; all pre­dic­tions assume deliv­ery, but some need differ­ent judg­ment cri­te­ria.

  1. 80%

    Accord­ing to the pro­pos­al, the core patch index code has already been imple­mented & bench­marked by the stu­dent, who has worked on Darcs before (fly­ing 9 hours into Eng­land for a hack­ing mee­tup). The rest of the work sounds rea­son­able, and the project is not over­reach­ing at all. I fully expect this to work out (even if darcs annotate is not a com­mand I use every mon­th, much less day). The main risk seems to be life events, but SoCs fail­ing due to per­sonal issues are rel­a­tively rare and affect <20% of past pro­jects.

    This SoC will be judged suc­cess­ful if it is in Darcs HEAD, or at least sched­uled for appli­ca­tion, by my usual dead­line: 2013-01-01.

  2. 40%

    No pro­posal was pub­licly avail­able. I am not famil­iar with DMcGill, and Googling for Haskell mate­r­ial related to “McGill”, I don’t see any past work. It sounds rel­a­tively ambi­tious in the short abstract - repli­cat­ing cabal-dev and adding in con­sid­er­able other func­tion­al­i­ty? I’ve pre­vi­ously noticed that Cabal-re­lated SoCs seem to be unusu­ally blight­ed. Adding that all up, I am left with dubi­ous feel­ings.

    Judg­ment: tools are always hard to judge. This one will be the usual sub­jec­tive “is it being used by a good frac­tion of its poten­tial user­base?” cri­te­ria.

  3. 60%

    The stu­dent has com­pleted a SoC before, and is a grad­u­ate stu­dent in an AI/machine learn­ing pro­gram; both of which bode well for him com­plet­ing another SoC. I’m not actu­ally sure how many Haskell appli­ca­tions need a con­cur­rent hashtable - the exist­ing hashta­bles pack­age has 3 users, and base’s “Data.HashTable” mod­ule is used by per­haps 10-20 code repos­i­to­ries (judg­ing from grep­ping through my local archive).

    It is unrea­son­able to expect it to super­sede base, which has had some­thing like a decade to gain users, but equal­ing the obscure hashtables pack­age seems rea­son­able. Judg­ment will be whether there are >=3 reverse depen­den­cies.

  4. 40%

    As stat­ed, I have no idea what this SoC is about. I don’t know the stu­dent, although Snoy­man seems to write a great deal of code and suc­cess­ful code at that, which is a good sign - if he agreed to men­tor it, surely the idea can’t be that bad?

    Since I don’t know what it is, I can­not spec­ify a judg­ment cri­te­ria in advance.

  5. 75%

    Both stu­dent & men­tor are expe­ri­enced Haskell hack­ers, and have worked with the Cabal code­base. As the abstract says, sand­boxed builds are not a novel fea­ture. cabal-dev is pop­u­lar among devel­op­ers, so it stands to rea­son that a pol­ished ver­sion inside Cabal itself would be even more pop­u­lar. I see lit­tle rea­son this could not be suc­cess­ful, aside from the gen­eral chal­lenge of work­ing with Cabal.

    Judg­ment; sand­boxed build func­tion­al­ity in Cabal HEAD or sched­uled to be applied soon.

  6. 65%

    Judg­ment sim­i­lar to above: patches sched­uled for GHC HEAD or already applied.

  7. 80%

    Shae is an expe­ri­enced Haskeller & pro­fes­sional devel­oper (to the extent I was very sur­prised to hear that he had applied). The pro­posal seems like a very rea­son­able addi­tion, and I do not think it is too diffi­cult to mod­ify the mueval code­base10.

    Judg­ment: whether mul­ti­-user ses­sions have gone live.

  8. 55%

    Here again I regret the absence of a pub­lic pro­pos­al. I’m not sure how use­ful this one is, how hard it is, or how much progress the pro­to­type library on Hack­age rep­re­sents, nor do I know any com­pa­ra­ble libraries I could check for a reverse depen­dency count. I don’t know the stu­dent, but Broberg is a capa­ble Haskeller.

    Judg­ment cri­te­ria: punt­ing to check­ing for >=3 reverse-dependencies/users.

2012 results

As of 2013-01-01:

  1. Darcs patch index

    Merged into Darcs HEAD with­out appar­ent issue (doc­u­men­ta­tion). Project was suc­cess­ful.

  2. scoutess: As of August 15, McGillicuddy was report­ing that scout­ess was com­plete (repos­i­tory). In Haskel­l-cafe, there is one off-hand men­tion of scout­ess by some­one using a differ­ent con­tin­u­ous inte­gra­tion pro­gram; there are a few dis­cus­sions on Red­dit of progress but the most recent post is a the­o­ret­i­cal dis­cus­sion of scoutess’s archi­tec­ture. There are no tools or libraries depend­ing on it in Hack­age because scout­ess has never been uploaded to Hack­age. Indeed, as far as I can tell, no one is actu­ally using it, and step­cut agreed with this assess­ment when I asked him.

    I spec­i­fied in April 2012 that my judg­ment cri­te­rion would be “is scout­ess being used by a good frac­tion of its poten­tial user­base?”; in this light, scout­ess was unsuc­cess­ful.

  3. con­cur­rent hashtable/hashmap

    Edward Kmett tells me that Loren ran into per­sonal issues and was removed from SoC by the mid­point with no deliv­ered library. Unsuc­cess­ful.

  4. “Accel­er­at­ing Haskell Appli­ca­tion Devel­op­ment”

    Edward Kmett tells me that the stu­dent left for a job around the mid­point and was removed from SoC at the last mile­stone. Unsuc­cess­ful. eegreg argues that while incom­plete, the first goal of the SoC (a file-watch­ing library) has since been ful­filled and the library been put to use by the Yesod ecosys­tem of Web libraries & appli­ca­tions.

  5. Sand­boxed builds

    Com­pleted and in Cabal HEAD; per my cri­te­ria, this is suc­cess­ful.

  6. Mul­ti­ple pack­ages sup­port in GHC

    The lat­est infor­ma­tion I can find is a GHC doc­u­men­ta­tion page which sum­ma­rizes the mate­r­ial as: “It is pos­si­ble to install mul­ti­ple instances of the same pack­age ver­sion with my forks of cabal and ghc. Quite a few prob­lems remain.” A set of slides says “Quite a few prob­lems remain there­fore noth­ing is merged yet.” The code is not in HEAD for either Cabal or GHC, and given the many prob­lems, may never be. Unsuc­cess­ful.

  7. Bet­ter try­haskel­l.org

    Eris­son fin­ished in August with a Hack­age upload and some nice slides. Unfor­tu­nate­ly, there is no live server where one can actu­ally use ghcLiVE; some­one sug­gested that Eris­son might’ve given up on the sand­box­ing aspects which would have made it usable on the pub­lic Inter­net (per his orig­i­nal pro­pos­al). One won­ders how many peo­ple will ever use it, given how much Haskell instruc­tion is done remote­ly, but maybe it would be use­ful in offline uni­ver­sity class­es. In any case, my cri­te­rion was clear: “whether mul­ti­-user ses­sions have gone live”; and so despite my high hopes, I must mark this unsuc­cess­ful. (Edward Kmett dis­agrees with this assess­ment; Eris­son sort of agrees and dis­agrees11.)

  8. Haskell type­-checker library

    This one is a lit­tle con­fus­ing. The Hack­age library remains untouched since April 2012, although there is a largely com­plete library (main miss­ing fea­ture is records sup­port, which is impor­tant but not a huge gap) avail­able on Github. Another blog post implies that it is but a small part of a grander research scheme entire­ly, and that my reverse depen­den­cies judg­ment cri­te­ria is sim­ply off-base entirely although it sug­gests the SoC was unsuc­cess­ful. (The alter­na­tive, look­ing at whether it is pushed to the HEAD of haskell-type-exts, would also sug­gest unsuc­cess­ful.) I am not sure whether this should be con­sid­ered suc­cess­ful or unsuc­cess­ful.

To sum­ma­rize:

  1. unclear: 1
  2. suc­cess­ful: 2
  3. unsuc­cess­ful: 5

2 of the 5 unsuc­cess­ful projects were due to prob­lems on the stu­den­t’s end (hashtable, “accel­er­at­ing”); 2 were too ambi­tious in gen­eral (scoutess, mul­ti­ple-pack­ages); and the last 1 was not too ambi­tious but in my opin­ion was left some­what incom­plete (gh­cLiVE).

How suc­cess­ful were my pre­dic­tions? Employ­ing a proper (log scor­ing; for addi­tional dis­cus­sion of scor­ing rules, see ) and com­par­ing against a 50-50 ran­dom guesser where >0 means I out­per­formed the ran­dom guesser12:

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 per­formed worse than ran­dom, in part because 2012 was such a bad year. In par­tic­u­lar, I placed great weight on Eris­son suc­ceed­ing (with­out that pre­dic­tion, I would score 0.95). In ret­ro­spect, I am also dis­ap­pointed that I assigned the GHC project a high as 65% when I knew GHC projects are as dan­ger­ous as Cabal projects and the mul­ti­ple pack­ages work was a lot of low-level prob­lems with min­i­mal fore­go­ing work.

2013

For 2013, Haskell.org/Darcs picked up a full 11 slots:

  1. “Enhanc­ing Darcs­den”; BSRK Aditya, men­tored by Ganesh Sit­tam­palam

    The goal of this project is to increase the func­tion­al­ity of Darcs­den. Darcs­den is an open source repos­i­tory host­ing plat­form for darcs, writ­ten in Haskell. The main fea­tures are authen­ti­ca­tion from Github/OpenID, Pass­word Recov­ery, Edit­ing repos­i­tory files online, and Com­par­i­son between a repos­i­tory and its forks.

  2. “Over­loaded record fields for GHC; Adam Gundry, men­tored by Simon Pey­ton Jones

    Haskel­l’s record sys­tem lacks sup­port for over­loaded field names. This leads to unnec­es­sar­ily clut­tered code and inhibits code reuse. I pro­pose to imple­ment sup­port for over­loaded field names and poly­mor­phic record pro­jec­tion as a GHC exten­sion, with the aim to ulti­mately add them to the lan­guage stan­dard in a future revi­sion. This rel­a­tively straight­for­ward change would remove a sig­nifi­cant source of frus­tra­tion for Haskell pro­gram­mer­s….By Sep­tem­ber 23 I will have the final imple­men­ta­tion on a GHC branch ready to merge into HEAD…The biggest risk to the project is that it may prove con­tro­ver­sial, as has been seen by argu­ments over pre­vi­ous attempts to solve this prob­lem. How­ev­er, I am opti­mistic that suffi­cient con­sen­sus can be reached, as much of the dis­agree­ment is about syn­tax or imple­men­ta­tion details rather than the user-vis­i­ble aspects of the exten­sion

  3. “inter­ac­tive-di­a­grams and a paste site with the abil­ity for dynamic ren­der­ing of dia­grams”; Dan Fru­min, men­tored by Luite Stege­man

    I want to build an active-di­a­grams library for com­pil­ing dia­grams code into active HTML + JS wid­gets. The dia­grams are active in the sense that user can inter­act with them: for exam­ple, a result of type (Bool -> Diagram) should be com­piled to a wid­get that ren­ders a dia­gram depend­ing on the state of the check­box. In addi­tion, a paste­bin site should be built, that can be used as an inter­ac­tive scratch­pad, where dia­grams code can be auto­mat­i­cally com­piled and the graph­i­cal out­put shown along. This is use­ful for shar­ing graph­i­cal exper­i­ments, teach­ing begin­ners and so on. The ren­dered dia­gram, together with its inter­ac­tive capa­bil­i­ties, should be eas­ily embed­ded in third-party blogs, web­sites.

  4. “Had­dock exten­sion for Pan­doc com­pat­i­bil­ity”; Fūzetsu [Ma­teusz Kowal­czyk?], men­tored by Simon Hen­gel (fur­ther dis­cus­sion)

    Project aim­ing to extend Had­dock to a point where writ­ing reader and writer mod­ules for Pan­doc is pos­si­ble. The gen­eral goal is to allow for doc­u­men­ta­tion writ­ing in differ­ent for­mats, includ­ing the ever pop­u­lar Mark­down.

  5. “Port Charts to use Dia­grams”; jbrack­er, men­tored by Tim Docker

    Right now the Charts library uses Cairo as back­end. Cairo can be diffi­cult to build on plat­forms other then Lin­ux. Goal of the project would be to port the Charts library to be inde­pen­dent of the used back­end. Like that it can sup­port to use Dia­grams as back­end. Dia­grams sup­ports a vari­ety of back­ends (SVG, Post­script, Cairo (Op­tion­al!), Tikz, Gtk), some of which are writ­ten plat­form inde­pen­dent. As Dia­grams is easy to install on every plat­form sup­ported by Haskell, so will the Charts Library built upon Dia­grams. This will make it easy for Haskellers to add chart­ing capa­bil­i­ties to their own appli­ca­tions and libraries in a man­ner portable across all plat­forms with­out any pain.

  6. “Bet­ter record com­mand for darcs”; José Ned­er, men­tored by Guil­laume Hoff­mann

    The objec­tive of this project is to improve the darcs record com­mand imple­ment­ing sev­eral option­s…D­iffing two given files can pro­duce var­i­ous cor­rect out­puts, depend­ing on the algo­rithm used. The stan­dard diff algo­rithm (used in darcs and many other places) has been crit­i­cized to some­times pro­duce coun­ter­in­tu­itive diffs. We would like to try out the “patience diff” algo­rithm (Issue 346), which seems to pro­duce more inter­est­ing chunks when used on source code. One down­side of patience diff is that it may be slower than clas­sic diff, so per­for­mance will have to be eval­u­at­ed.

    More­over, just as the exist­ing flag --look-for-adds pro­poses adding unver­sioned files to the new patch, we could use a --look-for-moves flag, which would be hand­ful when one wants to record a file move after hav­ing done the move, ie, with­out using darcs move (Issue 642). Another cool flag would be --look-for-replaces, which would detect token renam­ing when one for­gets about using darcs replace (Issue 2209).

    If time allows, a --provide-primitive-patches would be use­ful for darcs to be called by another pro­gram that pro­vides the changes to record. For instance, a web inter­face pro­vid­ing a sim­ple on-line code edit fea­ture a la GitHub.

  7. “Com­mu­ni­cat­ing with mobile devices”; Mar­cos Pivi­dori, men­tored by Michael Snoy­man (fur­ther dis­cus­sion)

    The aim of this project is to develop a server-side library in Haskell for send­ing push noti­fi­ca­tions to devices run­ning differ­ent OS, such as Android, iOS, Win­dows Phone, Black­Ber­ry, and so on. And, once we have this libraries, inves­ti­gate the pos­si­bil­ity of main­tain­ing a “back and forth” com­mu­ni­ca­tion between a server and mobile devices and develop a library to han­dle this.

  8. “Improve the feed­back of the cabal-in­stall depen­dency solver”; Mar­t­in, men­tored by Andres Löh

    The depen­dency solver can be a mys­te­ri­ous piece of the instal­la­tion process. I want to give the user the pos­si­bil­ity to see what is hap­pen­ing and also give them a bet­ter chance to under­stand what hap­pened if some­thing does not just work. Fur­ther, I would like to enable them to use that infor­ma­tion to fix the instal­la­tion in some cas­es.

  9. “Par­al­lelise cabal build; Mikhail Glushenkov, men­tored by Johan Tibell

    This project aims to add sup­port for mod­ule-level par­al­lel builds to Cabal, a sys­tem for build­ing and pack­ag­ing Haskell libraries and pro­grams. I sug­gest a novel solu­tion for this prob­lem in the con­text of GHC/Cabal that, unlike exist­ing approach­es, will make a more effec­tive use of mul­ti­-core CPUs.

  10. “Extend­ing GHC to sup­port build­ing mod­ules in par­al­lel”; Patrick Palka, men­tored by Thomas Schilling

    The aim of this project is to imple­ment native sup­port for build­ing mod­ules in par­al­lel in GHC. This entails mak­ing the com­pi­la­tion pipeline thread­-safe, and writ­ing a par­al­lel com­pi­la­tion dri­ver next to the exist­ing sequen­tial dri­ver. Focus will be placed on cor­rect­ness and deter­min­is­tic out­put, with speed a latent con­cern. Noth­ing in the user’s end should change other than there being a new -j flag that spec­i­fies the num­ber of mod­ules to build in par­al­lel. The cabal-in­stall project should be aug­mented with the abil­ity to use this new -j flag to speed up builds, along­side its exist­ing pack­age-level par­al­leliza­tion.

  11. “Haskell Qt Bind­ing Gen­er­a­tor”; Zhengliang Feng, men­tored by Carter Schon­wald & Ian-Woo Kim

    This project aims to pro­vide a gen­er­a­tion tool that cre­at­ing Qt bind­ings auto­mat­i­cally for Haskell and make gen­er­a­tion as much automa­tion as pos­si­ble. It parses Qt header files and gen­er­ates cor­re­spond­ing Qt-style Haskell inter­faces (type class­es, data type­s).

    The men­tor clar­i­fied in August 2013:

    Speak­ing as the prin­ci­ple men­tor on the rel­e­vant GSOC project (Ian is also co-men­tor­ing, so he can cor­rect me if I’m wrong any­where): The QT bind­ing project is a sub­pro­ject of the GSoC project whose prin­ci­pal focus for the sum­mer is mak­ing a swig + fficxx based C++ FFI wrap­per for haskell. The GSoC core project is mov­ing apace, and will likely be usable by the close of the sum­mer. Real­is­ti­cal­ly, the QT bit is gold plat­ing / a non­triv­ial demo use case. Cur­rently its unclear if we’ll have time to get the QT ball rolling, but a lot of the sup­port tool­ing for that sub­pro­ject should be done by the close of the sum­mer!

2013 predictions

Com­pil­ing the 2006-2012 results, I get an over­all base-rate of 47% suc­cess­ful, 40% unsuc­cess­ful, & 13% unknown pro­jects. With this base rate in mind, I pre­dicted thus­ly:

  1. Darcs­den: 65%
  2. Over­loaded records: 40%
  3. inter­ac­tive-di­a­grams: 35%
  4. Pan­doc Had­dock: 55%
  5. Charts on Dia­grams: 75%
  6. `darcs record: 65%
  7. mobile push: 25%
  8. depen­den­cy-solver error-mes­sages: 40%
  9. Par­al­lel build: 33%
  10. Par­al­lel mod­ules: 33%
  11. Qt bind­ing gen­er­a­tor: 40%

2013 results

As of 2014-01-08:

  1. Darcs­den: check­ing the Darcs­den HEAD repos­i­to­ry, I see patches by BSRK Aditya adding what looks like GitHub sup­port, a repos­i­tory com­par­i­son fea­ture, reset­ting pass­words, and file edit­ing. I haven’t actu­ally ver­i­fied that the addi­tions are usable, but I have no rea­son to be that sus­pi­cious and so I will mark this SoC suc­cess­ful.

  2. Over­loaded record fields for GHC: Gundry fin­ished work on the exten­sion appar­ently suc­cess­ful­ly, and sub­mit­ted his patches in Sep­tem­ber 2013. The ghc-devs mail­ing list dis­cus­sion petered out, though, and in Novem­ber 2013 Gundry explained:

    Unfor­tu­nate­ly, the exten­sion will not be ready for GHC 7.8, to allow time for the design to set­tle and the code­base changes to mature. How­ev­er, it should land in HEAD soon after the 7.8 release is cut, so the adven­tur­ous are encour­aged to build GHC and try it out. Feed­back from users will let us pol­ish the design before it is finally released in 7.10… Keep an eye out for the exten­sion to land in GHC HEAD later this year, and please try it out and give your feed­back!

    How­ev­er, GHC 7.8 appar­ently took longer to release than expected and so Gundry’s work still has not been merged by 2014. Dun­can Coutts and Gundry both seem opti­mistic that it would get added even­tu­ally, but nev­er­the­less, 4 months after being fin­ished, it had not been merged into GHC HEAD and fails my orig­i­nal judg­ment cri­te­ri­on, ren­der­ing it unsuc­cess­ful? This is defi­nitely a SoC to revisit in the future to check out whether it ulti­mately got merged in or was aban­doned to bitrot.

  3. Inter­ac­tive dia­grams: Fru­min’s sum­ma­tion post links to his work­ing paste­bin. I am sur­prised, but it’s defi­nitely there. So, mark­ing this one suc­cess­ful.

  4. Had­dock exten­sion for Pan­doc com­pat­i­bil­i­ty: this SoC was turned into a rather differ­ent project; it still involved Had­dock, but not Pan­doc. Unclear what hap­pened - most of the sub­mit­ted patches do not seem to have been applied to the Github repos­i­tory for Had­dock. Fuuzetsu tells me in an email on 2014-01-08 that the GHC inte­gra­tion had trou­ble and this delayed incor­po­ra­tion, but that he was actively work­ing on get­ting the patches in & was opti­mistic that they would be “very soon” and “at worst before the end of the week”. So this is a very sim­i­lar sit­u­a­tion as Gundry’s over­loaded record field patch­es: the work has not been merged into GHC HEAD (tech­ni­cally fail­ing my cri­te­rion of “merged by 2014”), but the stu­dent is con­fi­dent that it will be soon and appar­ently it was merged 2014-01-12 (so I will prob­a­bly revise the judg­ment in the future). Unsuc­cess­ful?

  5. Port Dia­grams to use Charts: the lat­est ver­sion rec­om­mends using the Charts back­end, and Bracker declared on diagrams-discuss the project “a full suc­cess”. Mark­ing suc­cess­ful.

  6. “Bet­ter record com­mand for darcs”: a check of the Darcs HEAD & issue 346 indi­cates that patience diff made it in, and like­wise --look-for-moves, so per my cri­te­ria of 2 out of 3, mark­ing suc­cess­ful.

  7. “Com­mu­ni­cat­ing with mobile devices”: I spec­i­fied in my orig­i­nal pre­dic­tion the usual default cri­te­rion of look­ing for ≥n reverse depen­den­cies, in this case, ≥3. The author’s blog & Github repos­i­tory indi­cate he released a trio of pack­ages; check­ing the reverse depen­den­cies for push-notify/push-notify-ccs/, I see 0 reverse depen­den­cies not to each other (and Hack­age indi­cates 15 total down­loads of push-notify as of 2014-01-13, sug­gest­ing that there’s not a lot of demand we’re miss­ing by look­ing at reverse depen­den­cies). Mark­ing unsuc­cess­ful.

  8. “Improve the feed­back of the cabal-in­stall depen­dency solver”: Rud­er­er’s code appears to have not been merged into Cabal HEAD as of 2014-01-13 and there’s noth­ing on his blog or the cabal-dev mail­ing list indi­cat­ing any work towards get­ting the code merged in. Unsuc­cess­ful.

  9. “Par­al­lelise cabal build”: judg­ing from the bug report dis­cus­sion, merg­ing has got­ten bogged down in dis­cus­sion over pull #1572/bug #1529. Hope­fully the work will get merged in, but it has not yet, so this is another unsuc­cess­ful?

  10. “Extend­ing GHC to sup­port build­ing mod­ules in par­al­lel”: bug #910 was closed after the patches were merged in. Looks like par­al­leliz­ing GHC was finally done and I can mark this suc­cess­ful!

  11. “Haskell Qt Bind­ing Gen­er­a­tor”: a lit­tle con­fus­ing, but Feng’s final sub­mis­sion is a tar­ball pro­vid­ing some source code and a Cabal file nam­ing it to be fficxx-swig; which is not on Hack­age at all nor does it have any reverse depen­den­cies. I thought per­haps it was intended to be merged into fficxx (writ­ten by Feng’s co-men­tor Kim), but a check of the fficxx con­trib­u­tors shows only Ian-Woo Kim as author. A google of “fficxx-swig” turned up some­thing more use­ful, a hqt repos­i­tory by ofan/Ryan Feng, which is described as “hqt is a set of tools that gen­er­ate bind­ings from Qt library to Haskell auto­mat­i­cal­ly. The goal of this project is to make a usable and sta­ble tool that can gen­er­ate bind­ings for gen­eral C++ libraries.” Per­haps this is what I should be look­ing at? But hqt turns out to also not be on Hack­age, not have any reverse depen­den­cies, and not even be men­tioned in a google of hqt site:haskell.org. (A google of haskell "hqt" did turn up an inter­est­ing result, though: “hqt - Haskell Quran Toolkit – A Haskell library for deal­ing with Quran texts.” How about that?) Given the com­plete absence of evi­dence that any­one is using hqt in any way, I’m going to have to mark this one unsuc­cess­ful.

The quick overview is 5 suc­cess­ful, 6 unsuc­cess­ful, so very sim­i­lar to his­tor­i­cal base-rates. Things get a lit­tle rosier when I note that 3 of the unsuc­cess­ful and 0 of the suc­cess­ful had to be given ques­tion marks because the project seemed to suc­ceed but it was still uncer­tain whether the work would be inte­grated with HEAD, so if all 3 get merged, then we’d really have 8 suc­cesses and 3 fail­ures, which seems like a rea­son­able rate.

How did my pre­dic­tions do? The sim­plest scor­ing is sim­ply to ask how often I assigned >50% to a suc­cess or <50% to a fail­ure; ignor­ing the ques­tion-marks, I then got 8/11. More sophis­ti­cated is a log scor­ing rule tak­ing into account my con­fi­dence, and com­par­ing it to a ran­dom guesser of 47% (the rough base-rate for suc­cess in past years)

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 man­aged to beat the base-rate. What hap­pens if I decide to flip all 3 ques­tion-marks into suc­cesses (the best-case sce­nario for them)?

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 triv­ial amount. The prob­lem here is that while I was accu­rate enough in pre­dict­ing on the 2 Darc­s-re­lated projects and the FFI one, I gave the Cabal/GHC-related project low prob­a­bil­i­ties, and them flip­ping into suc­cess pun­ishes my score. As is cor­rect: I am sur­prised that those suc­ceed­ed, and my pre­dic­tions reflected my expec­ta­tions. Was I wrong to be pes­simistic about them and to be sur­prised by their suc­cess? Should I have expected them to suc­ceed, per­haps under a the­ory like “third time’s the charm”? Think­ing back, I don’t think so. I did­n’t have any par­tic­u­lar rea­son to think that this time would be differ­ent, or that a spe­cial push was going to be made, or that some crit­i­cal point had been passed. I think that if one just takes enough whacks at a hard nut, it’ll crack even­tu­al­ly, and this year was GHC/Cabal par­al­lelis­m’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 expla­na­tions for fail­ure. They are:

  1. Hubris

    Gui­Haskell is prob­a­bly a good exam­ple; it is essen­tially a bare-bones IDE, from its descrip­tion. It is expect­ing a bit much of a sin­gle stu­dent in a sin­gle sum­mer to write that!

  2. Unclear Use

    HsJudy is my exam­ple here. There are already so many arrays and array types in Haskell! What does HsJudy bring to the table that jus­ti­fies a FFI depen­den­cy? Who’s going to use it? Pugs ini­tially did appar­ent­ly, but per­haps that’s just because it was there - when I looked at Pugs/HsJudy in 2007, cer­tainly Pugs had no need of it. (The data par­al­lel physics engine is prob­a­bly another good exam­ple. Is it just a bench­mark for the GHC devel­op­ers? Is it intended for actual games? If the for­mer, why is it a SoC pro­ject, and if the lat­ter, isn’t that a lit­tle hubris­tic?)

  3. Lack Of Mar­ket­ing

    One of the rea­sons Don Stew­art’s bytestring library is so great is his relent­less evan­ge­liz­ing, which con­vinces peo­ple to actu­ally take the effort to learn and use Bytestrings; even­tu­ally by net­work effects, the whole Haskell com­mu­nity is affected & improved13. Some of these SoC projects suffer from a dis­tinct lack of com­mu­nity buy-in - who used Haskell­Net? Who used Hat when it was updat­ed? Indiffer­ence can be fatal, and can defeat the point of a pro­ject. What good is a library that no one uses? These aren’t aca­d­e­mic research projects which accom­plish their task just by exist­ing, after all. They’re sup­posed to be use­ful to real Haskellers.

Future SoC proposals

There are 2 major col­lec­tions of ideas for future SoC pro­jects, aside from the gen­eral frus­tra­tions expressed in the annual sur­vey:

Let’s look at the first 12 and see whether they’re good ideas, bad ideas, or indiffer­ent.

  1. port GHC to the ARM archi­tec­ture: It would be a good thing if we could eas­ily com­pile our Haskell pro­grams for ARM, which is used in many cell­phones, but an even bet­ter idea would using the LLVM back­end to . It would be some­what tricky, but LLVM already has fairly solid cross-com­pi­la­tion sup­port, and mak­ing GHC capa­ble of using it seems like a rea­son­able project for a stu­dent to tack­le.
  2. “Imple­ment over­lap and exhaus­tive­ness check­ing for pat­tern match­ing”: this seems both quite chal­leng­ing and also a spe­cial­ized use. I use GADTs rarely, but I sus­pect that those writ­ing GADT code rarely make over­lap or omis­sion errors.
  3. Incre­men­tal garbage col­lec­tion: this may be a good idea depend­ing on how much of the code was already writ­ten. But I fear that this would go the way of the Immix GC SoC and would be a bad idea.
  4. “Thread­Scope with cus­tom probes”: I don’t under­stand the descrip­tion and can’t judge it.
  5. “A sim­ple, sane, com­pre­hen­sive Date/Time API: hav­ing puz­zled over date-time libraries before, I’m all for this one! It’s a well-de­fined prob­lem, within the scope of a sum­mer, and meets a need. Its only prob­lem is that it does­n’t sound sexy or cool.
  6. “Com­bine Thread­scope with Heap Pro­fil­ing Tools”: Uncer­tain. Going by the Arch down­load sta­tis­tics, Thread­scope is down­loaded more often than one would expect, so per­haps inte­gra­tion would be use­ful.
  7. “Had­dock with embed­ded wiki fea­ture, a la RWH, so we can col­lab­o­rate on improv­ing the doc­u­men­ta­tion”: This is a bad idea mostly because there are so many diverg­ing ideas and pos­si­ble imple­men­ta­tions - it’s just not clear what one would do. Is it some sort of Had­dock server? A Gitit wiki with clever hooks? Some light­weight in-browser edi­tor com­bined with Darcs?
  8. HTTP Library Replace­ment”: A good idea, assum­ing the linked attempts and alter­nate libraries haven’t already solved the issue.
  9. “Using Type Infer­ence to High­light Code Prop­erly: The diffi­cult part is access­ing the type infor­ma­tion of an iden­ti­fier inside a GHCi ses­sions - a prob­lem prob­a­bly already solved by scion. Col­oriz­ing the dis­play of a snip­pet is triv­ial. So this would make a bad SoC.
  10. “Trans­for­ma­tion and Opti­mi­sa­tion Tool”: This ini­tially sounds attrac­tive, but pre­vi­ous refac­tor­ing tools have been ignored. The tools that have got­ten uptake are things like GHC’s -Wall (which warns about pos­si­ble seman­tic issues) and hlint (which warns about style issues and redun­dancy with stan­dard library func­tions) - not like Hera.
  11. “Webkit-based browser writ­ten in Haskell, sim­i­lar in [plug­in] archi­tec­ture to Xmonad”: This is prob­a­bly the worst sin­gle idea in the whole bunch. A web browser these days is an entire oper­at­ing sys­tem, but worse, one in which one must sup­ply and main­tain the user­land as well; it is a thank­less task that will not ben­e­fit the Haskell com­mu­nity (ex­cept inci­den­tally through sup­port­ing libraries), nor a task it is uniquely equipped for. It is an infi­nite time sink - the only thing worse than this SoC fail­ing would be it suc­ceed­ing!
  12. “Add NVIDIA CUDA back­end for Data Par­al­lel Haskell”: DPH is rarely used; a CUDA back­end would be even more rarely uti­lized; has a rep­u­ta­tion for being diffi­cult to coax per­for­mance out of; and diffi­cul­ties would likely be exac­er­bated by the usual Haskell issues with space usage & lazi­ness. (DPH/CUDA use unboxed strict data, but there are inter­face issues with the rest of the boxed lazy Haskell uni­verse.) All in all, there are bet­ter SoCs14.

See Also

It’s diffi­cult to quan­tify how ‘use­ful’ a pack­age is; it’s eas­ier to punt and ask instead how ‘pop­u­lar’ it is. There are a few differ­ent sources we can appeal to:

  1. Pack­age down­loads:

    1. Don Stew­art pro­vid­ed, for , Arch down­load num­bers (de­funct)
    2. The Debian (and Ubuntu) Pop­u­lar­ity Con­test offers lim­ited pop­u­lar­ity data; eg. xmonad
    3. some 2006-2009 Hack­age sta­tis­tics are avail­able by month & rank­ing (de­func­t); live Hack­age sta­tis­tics is an open bug report which will be closed by Matthew Gru­en’s Hack­age 2.0 (2010 SoC)
  2. Reverse depen­den­cies can be exam­ined sev­eral ways:

    1. Hack­age Depen­dency Mon­i­tor
    2. cabal-query
    3. Hack­a­geOne­Five
  3. Search­ing for men­tions, blog posts, and unre­leased pack­ages else­where; key sites to search include:

    1. Haskell sub­red­dit
    2. Github
    3. Google Code
    4. haskell.org, and specifi­cally the Haskell wiki & mail­ing lists

  1. The Haskell ecosys­tem evolves fast, and strong sta­tic typ­ing means that a pack­age can quickly cease to be com­pi­l­able if not main­tained.↩︎

  2. From the 2011-02-11 Haskel­l-cafe thread, “Haskell Sum­mers of Code ret­ro­spec­tive (up­dated for 2010)”:

    There was some dis­cus­sion of this on Red­dit. Below is a slightly cleaned-up ver­sion of my com­ments there.

    I really appre­ci­ate this roundup. But I think the bar is set some­what too high for suc­cess. A suc­cess in this frame­work seems to be a sig­nifi­cant and excit­ing improve­ment for the entire Haskell com­mu­ni­ty. And there have cer­tainly been a num­ber of those. But there are also projects that are well done, pro­duce results that live on, but which aren’t imme­di­ately rec­og­niz­able as awe­some new things. Fur­ther­more, GSoc explic­itly lists a goal as inspir­ing young devel­op­ers towards ongo­ing com­mu­nity involvement/open source devel­op­ment, and these notes don’t really take that into account.

    For exam­ple, I don’t know of any direct uptake of the code from the Haskell­Net pro­ject, but the author did go on to write a small text­book on Haskell in Japan­ese. As another exam­ple, Roman (of Hpysics [sic]) has, as I under­stand it, been involved in a Russ­ian lan­guage func­tional pro­gram­ming mag­a­zine.

    So I think there needs to be a slightly more gran­u­lar scale that can cap­ture some of these nuances. Per­haps some­thing like the fol­low­ing:

    • Stu­dent com­pleted (i.e. got final pay­ment)
    • Project found use (i.e. as a lib has at least one con­sumer, or got merged into a broader code­base)
    • Project had sig­nifi­cant impact (i.e. wide use/noticeable impact)
    • Stu­dent con­tin­ued to participate/make con­tri­bu­tions to Haskell com­mu­nity

    A few more detailed com­ments about projects that weren’t nec­es­sar­ily slam dunks, but were at the least, in my esti­ma­tion, mod­est suc­cess­es:

    1. GHC-plugins – Not only was the work com­pleted and does it stand a chance of being merged, but it explored the design space in a use­ful way for future GHC devel­op­ment, and was part of Max becom­ing more famil­iar with GHC inter­nals. Since then he’s con­tributed a few very nice and use­ful patches to GHC, includ­ing, as I recall, the mag­nifi­cent Tuple­Sec­tions exten­sion.
    2. GHC refac­tor­ing – It seems unfair to clas­sify work that was taken into the main­line as unsuc­cess­ful. The improve­ment weren’t large, but my under­stand­ing is that they were things that we wanted to hap­pen for GHC, and that were quite time con­sum­ing because they were cross-cut­ting. So this was­n’t excit­ing work, but it was yeo­man’s work help­ful in tak­ing the GHC API for­ward. It’s still messy, I’m given to under­stand, and it still breaks between releas­es, but it has an increas­ing num­ber of clients late­ly, as wit­nessed by dis­cus­sions on -cafe.
    3. Darcs per­for­mance – by the account of Eric Kow & other core darcs guys, the hashed-s­tor­age stuff led to large improve­ments (and not only in per­for­mance)[2] – the fact that there’s plenty more to be done should­n’t be counted as a mark against it.

    Fur­ther crit­i­cisms by sclv from 2013:

    I no longer think these sum­maries are even mod­estly use­ful, because the judge­ment cri­te­ria are too harsh and too arbi­trary. They reflect a bias towards “suc­cess” of a gsoc project as some­thing mea­sur­able directly mea­sur­able in uptake and users within a rel­a­tively short span of time.

    GSoC projects are cho­sen, on the other hand, with an eye towards long-term pay­off in Haskell infra­struc­ture.

    The cri­te­ria that would yield us “high suc­cess” projects in the sense judged here would also yield us projects that weren’t very inter­est­ing, use­ful, or impor­tant.

    ↩︎
  3. For exam­ple, how long must a stu­dent ‘con­tinue to participate/make con­tri­bu­tions to Haskell com­mu­nity’? Spencer Janssen, a suc­cess­ful 2006 SoC stu­dent, went on to be one of the 2 main devel­op­ers on the pop­u­lar win­dow man­ager, but then wound down his Haskell con­tri­bu­tions and stopped entirely ~2009 (much to my dis­may as an Xmonad devel­op­er). Is he a suc­cess for SoC?↩︎

  4. I can hear the wankers in the peanut gallery - “Yeah, and it’s been buggy ever since!” Hush you. (Waern’s reply.)↩︎

  5. In the 2010 sur­vey of Haskellers, 3% reported ever using Eclipse for Haskell pro­gram­ming. In the 2011 sur­vey, 4% did.↩︎

  6. As of 2011-03-18, I have local copies of 8 repos­i­to­ries which seem to make use of the new syn­tax: angle, cabal, concurrent-extra, hashable, rrt, safeint, spatialIndex, unordered-containers, wai-app-static.↩︎

  7. A devel­op­ment that sur­prises me, since I had been under the impres­sion that most GHC work ulti­mately winds up being scrapped or aban­doned like Liskell or Mobile Haskell.↩︎

  8. 2011-12-11, Google+:

    “Regard­ing the par­al­lel cabal-in­stall patches - Dun­can is con­cerned that my changes are too inva­sive. I hope to get them merged in dur­ing the next few months after some rework­ing (we’re cur­rently dis­cussing what needs to be done).”

    ↩︎
  9. From my con­ver­sa­tion in #darcs with Eric Kow and other Darcs devel­op­ers:

    < 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
    ↩︎
  10. I wrote mueval but try­haskel­l.org uses a fork which takes expres­sions over a pipe as opposed to being a one-shot CLI tool.↩︎

  11. On Google+:

    Ah, ghcLiVE isn’t designed to have a server host­ed, it’s designed to run out­side a sand­box. Not that I would mark this suc­cess­ful myself, but mostly because it uses Yesod and cabal depen­dency hell means very few peo­ple ended up using it…I’d like to port ghclive to scot­ty, which has far fewer build depen­den­cies, I think peo­ple would actu­ally use it then

    ↩︎
  12. Guess­ing 50% sim­pli­fies the cal­cu­la­tion, and isn’t too far off: Doing a quick sum of all the non-2012 successful/unsuccessful rat­ings, I get a chance of being suc­cess­ful at (4+6+2+3+3+4) / ((4+2+5+1+2+4) + (4+6+2+3+3+4)) = 0.55, which isn’t ter­ri­bly differ­ent from a guess of 0.5.↩︎

  13. Many good and worth­while projects suffer this fate because of their aca­d­e­mic ori­gins. There’s no reward for some­one who cre­ates a great tech­nique or library and gets the wider com­mu­nity to adopt it as stan­dard. As far as the Haskell com­mu­nity is con­cerned, one Don Stew­art is worth more than a dozen of Oleg Kise­ly­ov; Oleg’s work is mind­blow­ingly awe­some in both quan­tity and qual­i­ty, every­one acknowl­edges, but how often does any­one actu­ally use any of it?

    (Iter­a­tees may be the excep­tion; although there are some­where upwards of 5 imple­men­ta­tions as of 2010 by Oleg and oth­ers lead­ing to a ver­i­ta­ble Tower of Iter­a­tee sit­u­a­tion, the orig­i­nal iter­a­tee has picked up 4 reverse depen­den­cies, its most pop­u­lar suc­ces­sor 33 and iter­a­tees in gen­eral may one day become as widely used as bytestrings.)↩︎

  14. Liam O’Con­nor begs to differ on the value of a DPH or CUDA SoC, argu­ing they are defi­nitely unnec­es­sary and even a “ter­ri­ble” idea.↩︎