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 ex­cel­lent re­sults, but how ex­cel­lent is ex­cel­lent? Are there any fea­tures or com­mon­al­i­ties be­tween suc­cess­ful projects or un­suc­cess­ful ones? A ret­ro­spec­tive re­view of projects sug­gests to me that while many of the Haskell Sum­mer of Code projects have de­liv­ered valu­able prod­ucts the Haskell com­mu­nity was in great need of and which have since be­come widely adopt­ed, a num­ber of them have failed for what likely could have been fore­seen rea­sons: low im­por­tance/un­clear us­es, and over-am­bi­tion.

Example retrospective: Debian

In 2009, a blog­ger & De­bian de­vel­oper wrote a four part ret­ro­spec­tive se­ries on the 2008 De­bian Sum­mer of Code pro­jects. The re­sults are in­ter­est­ing: some projects were a fail­ure and the rel­e­vant stu­dent drifted away and had lit­tle to do with De­bian again; and some were great suc­cess­es. I don’t dis­cern any par­tic­u­lar lessons there, ex­cept per­haps one against hubris or fill­ing un­clear needs. I de­cided to com­pile my own se­ries of ret­ro­spec­tives on the Haskell Sum­mers of Code.

Judging Haskell SoCs

Google de­scribes 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 ex­cit­ing projects for the up­com­ing sum­mer.”

or

“…a global pro­gram that offers stu­dent de­vel­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 pe­ri­od. Since its in­cep­tion in 2005, the pro­gram has brought to­gether 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, ac­cepted stu­dent ap­pli­cants are paired with a men­tor or men­tors from the par­tic­i­pat­ing pro­jects, thus gain­ing ex­po­sure to re­al-world soft­ware de­vel­op­ment sce­nar­ios and the op­por­tu­nity for em­ploy­ment in ar­eas re­lated 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 de­vel­op­ers. Best of all, more source code is cre­ated and re­leased for the use and ben­e­fit of all.”

It is in­tended 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 pa­pers, code cu­riosi­ties, for­got­ten blog posts, ground­work for dis­tant pro­jects, but ‘ex­cit­ing’ new pro­duc­tion code. This is the per­spec­tive I take in try­ing to as­sess SoC pro­jects: did it ship any­thing? If stand­alone, are the re­sults in ac­tive use by more than a few de­vel­op­ers or other code­bas­es? If a mod­i­fi­ca­tion to an ex­ist­ing code­base, was it merged and now is ac­tively main­tained1? And so on. Ster­ling Clover ar­gues that this is far too de­mand­ing and does not con­sider whether an in­volved stu­dent is en­er­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 be­cause it would be too labor-in­ten­sive to track down every stu­dent and as­sess their later con­tri­bu­tions, which would in­volve still more sub­jec­tive ap­praisals3. (Per­haps in the fu­ture I or an­other Haskeller will do that.)

Haskell retrospective

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

2006

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

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

2007

The 2007 home­page lists:

6 suc­cess­es; 2 un­suc­cess­ful; 1 un­known.

See Also

2008

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

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

  • “C99 Parser/Pret­ty-Printer”; by Benedikt Hu­ber, men­tored by Ia­vor Di­atchki

    Suc­cess­ful. The first try failed, but the sec­ond won through, and now peo­ple are do­ing 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

    Un­suc­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 im­proved per­for­mance and search ca­pa­bil­ity have made it into Hoogle re­leas­es, and Hoogle is one of the more pop­u­lar Haskell ap­pli­ca­tions (with 1.7m web searches).

  • “Ca­bal ‘make-like’ de­pen­dency frame­work”; An­drea Vez­zosi, men­tored by Dun­can Coutts

    Un­suc­cess­ful. (His code wound up be­com­ing hbuild, which is not on Hack­age or ap­par­ently used by any­one.)

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

    Un­suc­cess­ful? As of Jan­u­ary 2010, the patch adding plu­g­ins func­tion­al­ity has yet to be ac­cepted & ap­plied; as of Feb­ru­ary 2011, the ticket re­mains open and the code un­merged. The code is ap­par­ently not yet bi­trot­ten by the pas­sage of 3 years but how long can its luck last? The code was fi­nally merged in 2011-08-04; the docs do not list any users.

  • “Data par­al­lel physics en­gine”; Ro­man Chep­lyaka, men­tored by Manuel M. T. Chakravarty

    Un­suc­cess­ful. It seems to be fin­ished but no use made of the ac­tual en­gine that I can see men­tioned on the en­gine’s blog. (I would give re­verse de­pen­dency sta­tis­tics, but Hpysics seems to have never been up­loaded to Hack­age.)

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

    Un­suc­cess­ful. Schilling’s fixes went in, but they were in gen­eral mi­nor changes (like adding the GHC mon­ad) or bug-fix­es; the GHC API re­mains a mess.

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

Don Stewart’s view

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

"We ex­plic­itly pushed harder in 2008 to clar­ify and sim­plify the goals of the pro­jects, en­sure ad­e­quate prior Haskell ex­pe­ri­ence and to fo­cus on li­braries and tools that di­rectly 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 de­vel­op­ers and users, and from stu­dents with proven Haskell de­vel­op­ment ex­pe­ri­ence. You can’t learn Haskell from zero on the job, dur­ing SoC."

See Also

2009

5 projects were ac­cepted this year; Darcs tried to ap­ply in its own right was re­ject­ed.

In gen­er­al, these looked good. Most of them will be widely use­ful – es­pe­cially the Darcs and Had­dock SoCs – or ad­dress long­stand­ing com­plaints (many crit­i­cisms of lazi­ness re­volve around how un­pre­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 po­ten­tial Haskellers to war­rant the effort5, but at least the project is fo­cused on im­prov­ing an ex­ist­ing plu­gin than writ­ing one from scratch. The 5 were:

3 suc­cess­ful, 1 un­known, 1 un­suc­cess­ful.

2010

7 projects were ac­cept­ed:

  • Im­prove­ments to Ca­bal’s test sup­port; Thomas Tuegel, men­tored by Jo­han Tibell

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

  • In­fra­struc­ture for a more so­cial Hack­age 2.0; Matthew Gru­en, men­tored by Ed­ward Kmett

    Un­known. Gru­en’s blog was last up­dated Oc­to­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 ex­ists 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 li­brary; Jasper Van der Jeugt, men­tored by Si­mon Meier

    Suc­cess­ful blaze-html has been re­leased and is ac­tively de­vel­oped; ver­sion 0.4.0.0 has 50 to­tal re­verse de­pen­den­cies and blaze-builder has 97 re­verse de­pen­den­cies though there’s much over­lap. (This site is built on hakyll, which uses blaze-htm­l.)

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

    Un­suc­cess­ful. Dan Pee­bles in #haskell says that Alp’s SoC never got off the ground when his com­puter died at the be­gin­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, ex­act­ly. But could it have been?

    The LLVM back­end is still on track to be­come the de­fault GHC back­end7, sug­gest­ing that it’s pop­u­lar in GHC HQ (and the DDC di­alec­t), and it seems to also be pop­u­lar among Haskell blog­gers. The scope is re­stricted to tak­ing a work­ing back­end and op­ti­miz­ing it. In gen­er­al, it seems like a de­cent SoC pro­pos­al, and bet­ter than the next one:

  • Im­ple­ment­ing the Im­mix Garbage Col­lec­tion Al­go­rithm; Marco Túlio Gon­tijo e Sil­va, men­tored by Si­mon Mar­low

    Un­suc­cess­ful. The GHC repos­i­tory his­to­ry, as of 4 Feb­ru­ary, con­tains no patches adding Im­mix GC. Silva writes in his blog’s SoC sum­mary that “Al­though the im­ple­men­ta­tion is not ma­ture enough to be in­cluded 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, be­gun in Au­gust 2010, con­tains no men­tion of Im­mix work.) The GHC wiki says that “it’s func­tion­al, does­n’t have known bugs and gets bet­ter re­sults than the de­fault GC in the nofib suite. On the other hand, it gets worse re­sults than the de­fault 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 Im­mix GC col­lec­tor, but Si­mon Mar­low, my men­tor, thought it was not a good idea to in­vest more effort on Im­mix. So I dropped it, and started work­ing on other things. Greet­ings.

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

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

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

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

    The ba­sic idea is to com­bine all the small files into a sin­gle which can be down­loaded at full speed, and avoid the la­tency of many roundtrips. The 2.8 re­lease de­scrip­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 en­abled by de­fault, 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 un­der­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 fo­cused on an ex­ist­ing ap­pli­ca­tion. You don’t need to jus­tify a speedup of nor­mal Darcs op­er­a­tions be­cause there’s an in­stalled 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 Ca­bal sup­port for test­ing may go un­used by many pack­age au­thors who ei­ther 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 Ca­bal, and sim­i­larly for the Hack­age 2.0 pro­ject.

The Im­mix 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 in­ter­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 Im­mix 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 po­ten­tially falling prey to sins #2 & 3: the GOb­jec­t-binder tool, and the high­-per­for­mance HTML li­brary:

  1. Let’s as­sume that the HTML li­brary does wind up as be­ing faster than ex­ist­ing li­braries, and as use­ful - that com­pro­mises don’t de­stroy its util­i­ty. Who will use it? It will al­most surely have an API differ­ent enough from ex­ist­ing li­braries that a con­ver­sion will be painful. There are roughly 42 users of the ex­ist­ing xhtml-gen­er­at­ing li­brary; will their au­thors wish to em­brace a cut­ting-edge in­fant li­brary? Is HTML gen­er­a­tion even much of a bot­tle­neck for them? (S­peak­ing just for Gi­tit, 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 it­self; GTK2Hs is­n’t as widely used as one would ex­pect, and this seems to be due to the diffi­culty of in­stal­la­tion and its gen­eral com­plex­i­ty. So there are few users of ex­ist­ing li­braries; would there be more users for those li­braries 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 in­ter­pret.)

2010 results

As of Feb­ru­ary 2010, I grade the 7 SoC for 2010 as fol­lows: 4 suc­cess­es, 1 un­known, and 2 un­suc­cess­ful. (One un­known, 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 re­sults seem to be bet­ter than the re­sults for 2008 or 2009.

Of my orig­i­nal pre­dic­tions, I think I was right about the Im­mix GC & GOb­ject & Darcs op­ti­miza­tions, semi­-right about Hack­age 2.0 & Ca­bal 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 my­self 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. “Im­prove EclipseFP”; Ale­jan­dro Ser­ra­no, men­tored by Thomas Schilling

    "E­clipse is one of the most pop­u­lar IDEs in our days. EclipseFP is a project de­vel­op­ing a plug-in for it that sup­ports Haskell. Now, it has syn­tax high­light­ing, in­te­gra­tion of GHCi and sup­ports some prop­er­ties of Ca­bal files. My idea is to ex­tend the set of tools avail­able, at least with:
    • Au­to­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 Ca­bal files vi­su­al­ly, in­clud­ing a browser of the avail­able pack­ages."
  2. “Sim­pli­fied OpenGL bind­ings”; Alexan­der Göransson, men­tored by Ja­son Dagit

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

  3. “In­ter­preter Sup­port for the Ca­bal-In­stall Build Tool”; an­kle­saria, by Dun­can Coutts

    “This project aims to pro­vide ca­bal-in­stall with an ‘’ [cabal ghci?] com­mand by adding to the Ca­bal API. This would al­low pack­age de­vel­op­ers to use GHCi and Hugs from within pack­ages re­quir­ing op­tions and pre­pro­cess­ing from Ca­bal.”

  4. “Con­vert the text pack­age to use UTF-8 in­ter­nally”; Jasper Van der Jeugt, by Ed­ward Kmett (de­tailed pro­posal)

    "For Haskell projects han­dling Uni­code text, the text li­brary offers both speed and sim­plic­i­ty-of-use. When it was writ­ten, bench­marks in­di­cated that UTF-16 would be a good choice for the in­ter­nal en­cod­ing in the li­brary. How­ev­er, these (rather ar­ti­fi­cial) bench­marks were did not take into ac­count the time taken to
    1. de­code the ‘Real World’ data and
    2. en­code it to write it back.
    I pro­pose to
    1. bench­mark and
    2. con­vert the li­brary to UTF-8 if it is a faster choice for ‘Real World’-ap­pli­ca­tion­s."
  5. “Build mul­ti­ple Ca­bal pack­ages in par­al­lel”; Mikhail Glushenkov, by Jo­han Tibell

    “Ca­bal is a sys­tem for build­ing and pack­ag­ing Haskell li­braries and pro­grams. This pro­jec­t’s aim is to aug­ment Ca­bal with sup­port for build­ing pack­ages in par­al­lel. Many de­vel­op­ers have mul­ti­-core ma­chi­nes, but Ca­bal 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, de­pend­ing on the num­ber of cores and op­por­tu­nity of par­al­lel ex­e­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 en­able easy in­ter­op­er­abil­ity and syn­chro­ni­sa­tion be­tween Darcs and other VCSs. The bridge will be de­signed to be gener­ic, but the fo­cus of this project will be Darcs2 ↔︎ Git and Darcs2 ↔︎ Darc­s1. The bridge should al­low loss-less, cor­rect con­ver­sion to and from Darcs repos­i­to­ries, al­low­ing users to use the tool that suits them and their project best, be that Darcs as it cur­rently ex­ists, or an­other tool.”

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

    “Darcs, a re­vi­sion con­trol sys­tem, uses so-called patches to rep­re­sent changes to in­di­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 no­tions like ‘hunks’ (akin to what diff(1) pro­duces), to­ken re­place and file and di­rec­tory ad­di­tion/re­moval. I pro­pose to im­ple­ment a differ­ent rep­re­sen­ta­tion of these prim­i­tive patch­es, hop­ing to im­prove both per­for­mance and flex­i­bil­ity of darcs and to fa­cil­i­tate fu­ture de­vel­op­ment.”

Predicting 2011 results

Which seem like good se­lec­tions for SoC, and which seem less ap­pro­pri­ate?

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

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

  3. cabal ghci is a long-re­quested Ca­bal fea­ture, and it sounds as if all the ground­work and ex­per­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 in­creas­ingly used; but if I had to crit­i­cize it, I would crit­i­cize it for un­deram­bi­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 ex­ist­ing Darc­s->other VCS pro­grams, so the task is quite doable. An es­cape 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 re­spect Ročkai & Kow, but in idling on #darcs and read­ing the oc­ca­sional Darc­s-re­lated emails & Red­dit posts, I don’t know of any fully worked out de­sign for said patch de­sign, which makes it a chal­leng­ing the­o­ret­i­cal prob­lem (patch the­ory be­ing gen­eral & pow­er­ful), a ma­jor im­ple­men­ta­tion is­sue (s­ince the ex­ist­ing prim­i­tive patches are nat­u­rally as­sumed 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 be­sides the au­thor un­der­stands, which is bet­ter on some use­cases and worse on oth­ers, but not ac­tu­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 us­ing 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 Ca­bal fea­tures - but I ex­pect at least one of them to suc­ceed. Which, I am not sure.
  • I ex­pect with con­fi­dence that #4 & #6 will suc­ceed.

2011 results

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

    Suc­cess­ful. The cod­ing was fin­ished, to the au­thor’s ap­par­ent sat­is­fac­tion, and the work was in­cluded in the 2.1.0 re­lease.

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

    Un­suc­cess­ful. Ja­son Dagit says Alexan­der never started for un­known per­sonal rea­sons and so no work was ever done (no OpenGLRawNice li­brary ex­ists, 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. “In­ter­preter Sup­port for the Ca­bal-In­stall Build Tool”; an­kle­saria, by Dun­can Coutts

    Un­suc­cess­ful? an­kle­sari­a’s fi­nal 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 ap­pear in the Ca­bal repos­i­tory as of 2011-12-10; nor does there ap­pear to be any dis­cus­sion in the ca­bal-dev ML archives.

  4. “Con­vert the text pack­age to use UTF-8 in­ter­nally”; Jasper Van der Jeugt, by Ed­ward 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 re­sults” & “Text/UTF-8: Study­ing mem­ory us­age”); dis­cussing the re­sults in “Text/UTF-8: After­math”, the up­shot is that the con­ver­sion has a real but small ad­van­tage, po­ten­tially would cause in­ter­op­er­abil­ity prob­lems, re­quires con­sid­er­able test­ing, and won’t be merged in (the fork will be main­tained against hopes of fu­ture GHC op­ti­miza­tion­s). Jaspers says the ben­e­fits wound up be­ing a big­ger & cleaner test/bench­mark suite, and some op­ti­miza­tions made for the UTF-8 ver­sion can be ap­plied to the orig­i­nal. Since Ed­ward Kmett seems pleased, I have marked it a suc­cess (although I re­main du­bi­ous about whether it was a good SoC).

  5. “Build mul­ti­ple Ca­bal pack­ages in par­al­lel”; Mikhail Glushenkov, by Jo­han Tibell

    Suc­cess­ful Glushenkov re­ported in “Par­al­lelis­ing ca­bal-in­stall: Re­sults” that the patches were done and peo­ple could play with his repos­i­to­ry; the com­ments re­port that it works and does offer speedups. How­ev­er, as be­fore, no patch by him ap­pears in the main­line Ca­bal, 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 in­va­sive” and need re­work­ing be­fore merg­ing.8 The code was ul­ti­mately re­leased as part of ca­bal-in­stall 1.16 and is re­port­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 - Re­sults” sum­ma­riz­ing the fi­nal 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 re­quir­ing Darcs HEAD; see the us­age 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 re­mains to be seen.

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

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

    “Since my last re­port, I have de­cided 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 ex­pos­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 en­vi­ron­ment, as it is, makes cer­tain prop­er­ties hard to ex­press: a typ­i­cal test-suite works with as­ser­tions (HU­nit) and in­vari­ants (QuickCheck). In this en­vi­ron­ment, ex­press­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 im­prac­ti­cal at best. An al­ter­na­tive would have been to make my­self a play­ground us­ing the darcs li­brary to ex­pose the new code. But the fact is, our cur­rent code­base is en­trenched in all kinds of legacy is­sues, like han­dling file­names and du­pli­cated code. It makes the ex­per­i­menter’s life harder than nec­es­sary, and it also in­volves re­build­ing a whole lot of code that I never use, over and over. All in all, I made a some­what bold de­ci­sion to cut every­thing that lived un­der Darcs.Patch (plus a few de­pen­den­cies, as few as pos­si­ble) into a new li­brary, which I named patchlib, in the best tra­di­tion of cmdlib, pathlib and fslib. At that point, I also re­moved cus­tom file path han­dling from that por­tion of code, re­moved the use of a cus­tom Printer (a pret­ty-printer im­ple­men­ta­tion) mod­ule and a made few other in­com­pat­i­ble changes.”

    The re­main­ing work?

    "The ob­vi­ous fu­ture work lies in the con­flict han­dling. There are two main op­tions in this re­gard: ei­ther 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 al­ter­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 de­cide which is a bet­ter choice, and they come with differ­ent trade-offs. Nev­er­the­less, the de­ci­sion, and the im­ple­men­ta­tion, con­sti­tute a ma­jor step to­wards darcs 3. The other ma­jor piece of work that re­mains is the repos­i­tory for­mat: in this area, I have done some re­search in both the pre­vi­ous and this year’s pro­ject, but there are no de­fin­i­tive an­swers, even less an im­ple­men­ta­tion. I think we now have a num­ber of good ideas on how to ap­proach this. We do need to sort out a few is­sues though, and the de­ci­sion on the con­flict layer also in­flu­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 am­bi­tious SoC pro­ject. On top of that, a lot of in­te­gra­tion work needs to hap­pen to ac­tu­ally make real use of the ad­vance­ments. We shall see how much time and re­sources can be found for ad­vanc­ing this cause, but I am rel­a­tively op­ti­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 be­fore, the Darcs team will dis­agree with my as­sess­ment, but I be­lieve mark­ing it ‘Un­suc­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 un­suc­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 ac­cu­rate; I re­mained hope­ful that at least one of the Ca­bal SoCs would be merged in, which would give me a clean sweep and also ren­der the fi­nal 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 Ca­bal SoCs took so long to be merged in (if at al­l), in line with the his­tor­i­cal trend for big Ca­bal SoC im­prove­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 be­fore the 2012 SoC starts, the les­son seems to be that Ca­bal is too dan­ger­ous and un­cer­tain to waste SoCs on.

2012

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

  1. “Patch In­dex Op­ti­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 an­no­tate com­mands us­ing a cache called “patch in­dex”. The slow speed of these com­mands is one of the ma­jor 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 ca­bal projects”; DM­cGill, men­tored by Alp Mes­tanogullari

    Scout­ess is a tool for pack­age main­tain­ers and au­to­mates a lot of the has­sle of deal­ing with de­pen­den­cies and mul­ti­ple ver­sions of li­braries. It will cre­ate a sand­boxed en­vi­ron­ment sim­u­lat­ing a fresh Haskell Plat­form in­stall, at­tempt to build your project us­ing Ca­bal and high­light any prob­lems while also track­ing changes or up­dates to de­pen­den­cies lo­cated in re­mote repos­i­to­ries so these can be tested against as well.

  3. “Im­ple­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, al­ready have Haskell im­ple­men­ta­tions. One that does not yet is a thread­-safe hash table. I pro­pose to im­ple­ment one as a li­brary avail­able un­der the new BSD li­cense.

  4. “Ac­cel­er­at­ing Haskell Ap­pli­ca­tion De­vel­op­ment”; mdittmer, men­tored by Michael Snoy­man

    A project for im­prov­ing per­for­mance of “lively de­vel­oper mode” en­vi­ron­ments that re­quire fast re­build-and-re­de­ploy rou­tines.

  5. “Sand­boxed builds and iso­lated en­vi­ron­ments for Ca­bal”; Mikhail Glushenkov, men­tored by Jo­han Tibell

    The aim of this project is to in­te­grate sup­port for sand­boxed builds into Ca­bal, a sys­tem for build­ing Haskell pro­jects. There are sev­eral differ­ent third-party im­ple­men­ta­tions of this func­tion­al­ity al­ready avail­able, but it would be ben­e­fi­cial (from the points of ease of use and fo­cus­ing the com­mu­nity efforts) to have a uni­fied and pol­ished so­lu­tion in­te­grated into Ca­bal it­self. Ad­di­tion­al­ly, this project is a step in the di­rec­tion of solv­ing the in­fa­mous “de­pen­dency hell” prob­lem of Ca­bal.

  6. “En­able GHC to use mul­ti­ple in­stances of a pack­age for com­pi­la­tion” (pro­posal); Philipp Schus­ter, men­tored by An­dres Löh

    Peo­ple are run­ning into de­pen­dency hell when in­stalling Haskell pack­ages. I want to help move in the di­rec­tion of solv­ing it.

  7. “multi­user browser-based in­ter­ac­tive gh­ci, hpaste.org meets try­haskel­l.org, for im­proved 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 in­ter­ac­tive teach­ing, but only al­lows short code snip­pets. hpaste al­lows large snip­pets to be shared, but not into an in­ter­ac­tive ghci. Chris Done’s Try Haskell! al­lows larger snip­pets to be load­ed, but is not ex­plic­itly mul­ti­-user. If Try Haskell! al­lowed mul­ti­ple users to view the same in­ter­preter state, and al­lowed users to paste in new code, teach­ing and de­bug­ging would be much eas­ier for peo­ple new to Haskell.

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

    Fol­low­ing the pro­posal by Niklas Broberg [0], I am highly ea­ger to ex­pand the ex­ist­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 ma­jor ex­ten­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 ba­sis; adding sup­port for RankN­Types [5]; and then in­tro­duc­ing GADTs and Type­-Func­tions by lo­cal as­sump­tions [4]. [0] http://hack­age.haskel­l.org/­trac/­sum­mer-of-code/tick­et/1620 [1] http://hack­age.haskel­l.org/­pack­age/haskel­l-s­r­c-exts [2] http://hack­age.haskel­l.org/­pack­age/haskel­l-type­-exts [3] M. P. Jones. Typ­ing Haskell in Haskell [4] D. Vy­tin­i­o­tis, S. Pey­ton Jones, T. Schri­jvers, M. Sulz­mann. Out­sideIn(X) - Mod­u­lar type in­fer­ence with lo­cal as­sump­tions

2012 predictions

In­stead of qual­i­ta­tive pre­dic­tions this year, I will on Pre­dic­tion­Book.­com; all pre­dic­tions as­sume de­liv­ery, but some need differ­ent judg­ment cri­te­ria.

  1. 80%

    Ac­cord­ing to the pro­pos­al, the core patch in­dex code has al­ready been im­ple­mented & bench­marked by the stu­dent, who has worked on Darcs be­fore (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 ex­pect 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 is­sues 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 ap­pli­ca­tion, by my usual dead­line: 2013-01-01.

  2. 40%

    No pro­posal was pub­licly avail­able. I am not fa­mil­iar with DM­cGill, and Googling for Haskell ma­te­r­ial re­lated to “McGill”, I don’t see any past work. It sounds rel­a­tively am­bi­tious in the short ab­stract - repli­cat­ing cabal-dev and adding in con­sid­er­able other func­tion­al­i­ty? I’ve pre­vi­ously no­ticed that Ca­bal-re­lated SoCs seem to be un­usu­ally blight­ed. Adding that all up, I am left with du­bi­ous feel­ings.

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

  3. 60%

    The stu­dent has com­pleted a SoC be­fore, and is a grad­u­ate stu­dent in an AI/­ma­chine learn­ing pro­gram; both of which bode well for him com­plet­ing an­other SoC. I’m not ac­tu­ally sure how many Haskell ap­pli­ca­tions need a con­cur­rent hashtable - the ex­ist­ing hashta­bles pack­age has 3 users, and base’s “Da­ta.HashTable” mod­ule is used by per­haps 10-20 code repos­i­to­ries (judg­ing from grep­ping through my lo­cal archive).

    It is un­rea­son­able to ex­pect it to su­per­sede base, which has had some­thing like a decade to gain users, but equal­ing the ob­scure hashtables pack­age seems rea­son­able. Judg­ment will be whether there are >=3 re­verse de­pen­den­cies.

  4. 40%

    As stat­ed, I have no idea what this SoC is about. I don’t know the stu­dent, al­though 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 ad­vance.

  5. 75%

    Both stu­dent & men­tor are ex­pe­ri­enced Haskell hack­ers, and have worked with the Ca­bal code­base. As the ab­stract says, sand­boxed builds are not a novel fea­ture. cabal-dev is pop­u­lar among de­vel­op­ers, so it stands to rea­son that a pol­ished ver­sion in­side Ca­bal it­self 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 Ca­bal.

    Judg­ment; sand­boxed build func­tion­al­ity in Ca­bal HEAD or sched­uled to be ap­plied soon.

  6. 65%

    Judg­ment sim­i­lar to above: patches sched­uled for GHC HEAD or al­ready ap­plied.

  7. 80%

    Shae is an ex­pe­ri­enced Haskeller & pro­fes­sional de­vel­oper (to the ex­tent I was very sur­prised to hear that he had ap­plied). The pro­posal seems like a very rea­son­able ad­di­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 re­gret the ab­sence 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 li­brary on Hack­age rep­re­sents, nor do I know any com­pa­ra­ble li­braries I could check for a re­verse de­pen­dency count. I don’t know the stu­dent, but Broberg is a ca­pa­ble Haskeller.

    Judg­ment cri­te­ria: punt­ing to check­ing for >=3 re­verse-de­pen­den­cies/users.

2012 results

As of 2013-01-01:

  1. Darcs patch in­dex

    Merged into Darcs HEAD with­out ap­par­ent is­sue (doc­u­men­ta­tion). Project was suc­cess­ful.

  2. scoutess: As of Au­gust 15, McGillicuddy was re­port­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 us­ing a differ­ent con­tin­u­ous in­te­gra­tion pro­gram; there are a few dis­cus­sions on Red­dit of progress but the most re­cent post is a the­o­ret­i­cal dis­cus­sion of scoutess’s ar­chi­tec­ture. There are no tools or li­braries de­pend­ing on it in Hack­age be­cause scout­ess has never been up­loaded to Hack­age. In­deed, as far as I can tell, no one is ac­tu­ally us­ing it, and step­cut agreed with this as­sess­ment when I asked him.

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

  3. con­cur­rent hashtable/hashmap

    Ed­ward Kmett tells me that Loren ran into per­sonal is­sues and was re­moved from SoC by the mid­point with no de­liv­ered li­brary. Un­suc­cess­ful.

  4. “Ac­cel­er­at­ing Haskell Ap­pli­ca­tion De­vel­op­ment”

    Ed­ward Kmett tells me that the stu­dent left for a job around the mid­point and was re­moved from SoC at the last mile­stone. Un­suc­cess­ful. ee­greg ar­gues that while in­com­plete, the first goal of the SoC (a file-watch­ing li­brary) has since been ful­filled and the li­brary been put to use by the Yesod ecosys­tem of Web li­braries & ap­pli­ca­tions.

  5. Sand­boxed builds

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

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

    The lat­est in­for­ma­tion I can find is a GHC doc­u­men­ta­tion page which sum­ma­rizes the ma­te­r­ial as: “It is pos­si­ble to in­stall mul­ti­ple in­stances of the same pack­age ver­sion with my forks of ca­bal and ghc. Quite a few prob­lems re­main.” A set of slides says “Quite a few prob­lems re­main there­fore noth­ing is merged yet.” The code is not in HEAD for ei­ther Ca­bal or GHC, and given the many prob­lems, may never be. Un­suc­cess­ful.

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

    Eris­son fin­ished in Au­gust with a Hack­age up­load and some nice slides. Un­for­tu­nate­ly, there is no live server where one can ac­tu­ally use gh­cLiVE; some­one sug­gested that Eris­son might’ve given up on the sand­box­ing as­pects which would have made it us­able on the pub­lic In­ter­net (per his orig­i­nal pro­pos­al). One won­ders how many peo­ple will ever use it, given how much Haskell in­struc­tion is done re­mote­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 de­spite my high hopes, I must mark this un­suc­cess­ful. (Ed­ward Kmett dis­agrees with this as­sess­ment; Eris­son sort of agrees and dis­agrees11.)

  8. Haskell type­-checker li­brary

    This one is a lit­tle con­fus­ing. The Hack­age li­brary re­mains un­touched since April 2012, al­though there is a largely com­plete li­brary (main miss­ing fea­ture is records sup­port, which is im­por­tant but not a huge gap) avail­able on Github. An­other blog post im­plies that it is but a small part of a grander re­search scheme en­tire­ly, and that my re­verse de­pen­den­cies judg­ment cri­te­ria is sim­ply off-base en­tirely al­though it sug­gests the SoC was un­suc­cess­ful. (The al­ter­na­tive, look­ing at whether it is pushed to the HEAD of haskell-type-exts, would also sug­gest un­suc­cess­ful.) I am not sure whether this should be con­sid­ered suc­cess­ful or un­suc­cess­ful.

To sum­ma­rize:

  1. un­clear: 1
  2. suc­cess­ful: 2
  3. un­suc­cess­ful: 5

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

How suc­cess­ful were my pre­dic­tions? Em­ploy­ing a proper (log scor­ing; for ad­di­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 be­cause 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 as­signed the GHC project a high as 65% when I knew GHC projects are as dan­ger­ous as Ca­bal 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, Haskel­l.org/­Darcs picked up a full 11 slots:

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

    The goal of this project is to in­crease 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 au­then­ti­ca­tion from Github/OpenID, Pass­word Re­cov­ery, Edit­ing repos­i­tory files on­line, and Com­par­i­son be­tween a repos­i­tory and its forks.

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

    Haskel­l’s record sys­tem lacks sup­port for over­loaded field names. This leads to un­nec­es­sar­ily clut­tered code and in­hibits code reuse. I pro­pose to im­ple­ment sup­port for over­loaded field names and poly­mor­phic record pro­jec­tion as a GHC ex­ten­sion, with the aim to ul­ti­mately add them to the lan­guage stan­dard in a fu­ture re­vi­sion. This rel­a­tively straight­for­ward change would re­move a sig­nifi­cant source of frus­tra­tion for Haskell pro­gram­mer­s….By Sep­tem­ber 23 I will have the fi­nal im­ple­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 ar­gu­ments over pre­vi­ous at­tempts to solve this prob­lem. How­ev­er, I am op­ti­mistic that suffi­cient con­sen­sus can be reached, as much of the dis­agree­ment is about syn­tax or im­ple­men­ta­tion de­tails rather than the user-vis­i­ble as­pects of the ex­ten­sion

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

    I want to build an ac­tive-di­a­grams li­brary for com­pil­ing di­a­grams code into ac­tive HTML + JS wid­gets. The di­a­grams are ac­tive in the sense that user can in­ter­act with them: for ex­am­ple, a re­sult of type (Bool -> Diagram) should be com­piled to a wid­get that ren­ders a di­a­gram de­pend­ing on the state of the check­box. In ad­di­tion, a paste­bin site should be built, that can be used as an in­ter­ac­tive scratch­pad, where di­a­grams code can be au­to­mat­i­cally com­piled and the graph­i­cal out­put shown along. This is use­ful for shar­ing graph­i­cal ex­per­i­ments, teach­ing be­gin­ners and so on. The ren­dered di­a­gram, to­gether with its in­ter­ac­tive ca­pa­bil­i­ties, should be eas­ily em­bed­ded in third-party blogs, web­sites.

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

    Project aim­ing to ex­tend 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 al­low for doc­u­men­ta­tion writ­ing in differ­ent for­mats, in­clud­ing the ever pop­u­lar Mark­down.

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

    Right now the Charts li­brary 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 li­brary to be in­de­pen­dent of the used back­end. Like that it can sup­port to use Di­a­grams as back­end. Di­a­grams sup­ports a va­ri­ety of back­ends (SVG, Post­script, Cairo (Op­tion­al!), Tikz, Gtk), some of which are writ­ten plat­form in­de­pen­dent. As Di­a­grams is easy to in­stall on every plat­form sup­ported by Haskell, so will the Charts Li­brary built upon Di­a­grams. This will make it easy for Haskellers to add chart­ing ca­pa­bil­i­ties to their own ap­pli­ca­tions and li­braries 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 ob­jec­tive of this project is to im­prove the darcs record com­mand im­ple­ment­ing sev­eral op­tion­s…D­iffing two given files can pro­duce var­i­ous cor­rect out­puts, de­pend­ing on the al­go­rithm used. The stan­dard diff al­go­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 “pa­tience diff” al­go­rithm (Is­sue 346), which seems to pro­duce more in­ter­est­ing chunks when used on source code. One down­side of pa­tience 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 ex­ist­ing flag --look-for-adds pro­poses adding un­ver­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 us­ing darcs move (Is­sue 642). An­other cool flag would be --look-for-replaces, which would de­tect to­ken re­nam­ing when one for­gets about us­ing darcs replace (Is­sue 2209).

    If time al­lows, a --provide-primitive-patches would be use­ful for darcs to be called by an­other pro­gram that pro­vides the changes to record. For in­stance, a web in­ter­face pro­vid­ing a sim­ple on-line code edit fea­ture a la GitHub.

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

    The aim of this project is to de­velop a server-side li­brary in Haskell for send­ing push no­ti­fi­ca­tions to de­vices run­ning differ­ent OS, such as An­droid, iOS, Win­dows Phone, Black­Ber­ry, and so on. And, once we have this li­braries, in­ves­ti­gate the pos­si­bil­ity of main­tain­ing a “back and forth” com­mu­ni­ca­tion be­tween a server and mo­bile de­vices and de­velop a li­brary to han­dle this.

  8. “Im­prove the feed­back of the ca­bal-in­stall de­pen­dency solver”; Mar­t­in, men­tored by An­dres Löh

    The de­pen­dency solver can be a mys­te­ri­ous piece of the in­stal­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 un­der­stand what hap­pened if some­thing does not just work. Fur­ther, I would like to en­able them to use that in­for­ma­tion to fix the in­stal­la­tion in some cas­es.

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

    This project aims to add sup­port for mod­ule-level par­al­lel builds to Ca­bal, a sys­tem for build­ing and pack­ag­ing Haskell li­braries and pro­grams. I sug­gest a novel so­lu­tion for this prob­lem in the con­text of GHC/Cabal that, un­like ex­ist­ing ap­proach­es, will make a more effec­tive use of mul­ti­-core CPUs.

  10. “Ex­tend­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 im­ple­ment na­tive sup­port for build­ing mod­ules in par­al­lel in GHC. This en­tails 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 ex­ist­ing se­quen­tial dri­ver. Fo­cus will be placed on cor­rect­ness and de­ter­min­is­tic out­put, with speed a la­tent con­cern. Noth­ing in the user’s end should change other than there be­ing a new -j flag that spec­i­fies the num­ber of mod­ules to build in par­al­lel. The ca­bal-in­stall project should be aug­mented with the abil­ity to use this new -j flag to speed up builds, along­side its ex­ist­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 au­to­mat­i­cally for Haskell and make gen­er­a­tion as much au­toma­tion as pos­si­ble. It parses Qt header files and gen­er­ates cor­re­spond­ing Qt-style Haskell in­ter­faces (type class­es, data type­s).

    The men­tor clar­i­fied in Au­gust 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 fo­cus 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 us­able by the close of the sum­mer. Re­al­is­ti­cal­ly, the QT bit is gold plat­ing / a non­triv­ial demo use case. Cur­rently its un­clear 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 re­sults, I get an over­all base-rate of 47% suc­cess­ful, 40% un­suc­cess­ful, & 13% un­known pro­jects. With this base rate in mind, I pre­dicted thus­ly:

  1. Darcs­den: 65%
  2. Over­loaded records: 40%
  3. in­ter­ac­tive-di­a­grams: 35%
  4. Pan­doc Had­dock: 55%
  5. Charts on Di­a­grams: 75%
  6. `darcs record: 65%
  7. mo­bile push: 25%
  8. de­pen­den­cy-solver er­ror-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, re­set­ting pass­words, and file edit­ing. I haven’t ac­tu­ally ver­i­fied that the ad­di­tions are us­able, 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 ex­ten­sion ap­par­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 pe­tered out, though, and in No­vem­ber 2013 Gundry ex­plained:

    Un­for­tu­nate­ly, the ex­ten­sion will not be ready for GHC 7.8, to al­low time for the de­sign to set­tle and the code­base changes to ma­ture. How­ev­er, it should land in HEAD soon after the 7.8 re­lease is cut, so the ad­ven­tur­ous are en­cour­aged to build GHC and try it out. Feed­back from users will let us pol­ish the de­sign be­fore it is fi­nally re­leased in 7.10… Keep an eye out for the ex­ten­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 ap­par­ently took longer to re­lease than ex­pected and so Gundry’s work still has not been merged by 2014. Dun­can Coutts and Gundry both seem op­ti­mistic that it would get added even­tu­ally, but nev­er­the­less, 4 months after be­ing 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 un­suc­cess­ful? This is defi­nitely a SoC to re­visit in the fu­ture to check out whether it ul­ti­mately got merged in or was aban­doned to bi­trot.

  3. In­ter­ac­tive di­a­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 ex­ten­sion for Pan­doc com­pat­i­bil­i­ty: this SoC was turned into a rather differ­ent project; it still in­volved Had­dock, but not Pan­doc. Un­clear what hap­pened - most of the sub­mit­ted patches do not seem to have been ap­plied to the Github repos­i­tory for Had­dock. Fu­uzetsu tells me in an email on 2014-01-08 that the GHC in­te­gra­tion had trou­ble and this de­layed in­cor­po­ra­tion, but that he was ac­tively work­ing on get­ting the patches in & was op­ti­mistic that they would be “very soon” and “at worst be­fore 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 ap­par­ently it was merged 2014-01-12 (so I will prob­a­bly re­vise the judg­ment in the fu­ture). Un­suc­cess­ful?

  5. Port Di­a­grams to use Charts: the lat­est ver­sion rec­om­mends us­ing the Charts back­end, and Bracker de­clared 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 & is­sue 346 in­di­cates that pa­tience 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 mo­bile de­vices”: I spec­i­fied in my orig­i­nal pre­dic­tion the usual de­fault cri­te­rion of look­ing for ≥n re­verse de­pen­den­cies, in this case, ≥3. The au­thor’s blog & Github repos­i­tory in­di­cate he re­leased a trio of pack­ages; check­ing the re­verse de­pen­den­cies for push-notify/push-notify-ccs/, I see 0 re­verse de­pen­den­cies not to each other (and Hack­age in­di­cates 15 to­tal down­loads of push-notify as of 2014-01-13, sug­gest­ing that there’s not a lot of de­mand we’re miss­ing by look­ing at re­verse de­pen­den­cies). Mark­ing un­suc­cess­ful.

  8. “Im­prove the feed­back of the ca­bal-in­stall de­pen­dency solver”: Rud­er­er’s code ap­pears to have not been merged into Ca­bal HEAD as of 2014-01-13 and there’s noth­ing on his blog or the cabal-dev mail­ing list in­di­cat­ing any work to­wards get­ting the code merged in. Un­suc­cess­ful.

  9. “Par­al­lelise cabal build”: judg­ing from the bug re­port 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 an­other un­suc­cess­ful?

  10. “Ex­tend­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 fi­nally 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 fi­nal sub­mis­sion is a tar­ball pro­vid­ing some source code and a Ca­bal file nam­ing it to be fficxx-swig; which is not on Hack­age at all nor does it have any re­verse de­pen­den­cies. I thought per­haps it was in­tended 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 au­thor. A google of “fficxx-swig” turned up some­thing more use­ful, a hqt repos­i­tory by ofan/Ryan Feng, which is de­scribed as “hqt is a set of tools that gen­er­ate bind­ings from Qt li­brary to Haskell au­to­mat­i­cal­ly. The goal of this project is to make a us­able and sta­ble tool that can gen­er­ate bind­ings for gen­eral C++ li­braries.” 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 re­verse de­pen­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 in­ter­est­ing re­sult, though: “hqt - Haskell Quran Toolkit – A Haskell li­brary for deal­ing with Quran texts.” How about that?) Given the com­plete ab­sence of ev­i­dence that any­one is us­ing hqt in any way, I’m go­ing to have to mark this one un­suc­cess­ful.

The quick overview is 5 suc­cess­ful, 6 un­suc­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 un­suc­cess­ful and 0 of the suc­cess­ful had to be given ques­tion marks be­cause the project seemed to suc­ceed but it was still un­cer­tain whether the work would be in­te­grated with HEAD, so if all 3 get merged, then we’d re­ally 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 as­signed >50% to a suc­cess or <50% to a fail­ure; ig­nor­ing the ques­tion-marks, I then got 8/11. More so­phis­ti­cated is a log scor­ing rule tak­ing into ac­count 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 un­der a log score, I man­aged to beat the base-rate. What hap­pens if I de­cide 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 ac­cu­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 re­flected my ex­pec­ta­tions. Was I wrong to be pes­simistic about them and to be sur­prised by their suc­cess? Should I have ex­pected them to suc­ceed, per­haps un­der 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 go­ing 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 ex­pla­na­tions for fail­ure. They are:

  1. Hubris

    Gui­Haskell is prob­a­bly a good ex­am­ple; it is es­sen­tially a bare-bones IDE, from its de­scrip­tion. It is ex­pect­ing a bit much of a sin­gle stu­dent in a sin­gle sum­mer to write that!

  2. Un­clear Use

    HsJudy is my ex­am­ple here. There are al­ready so many ar­rays and ar­ray types in Haskell! What does HsJudy bring to the ta­ble that jus­ti­fies a FFI de­pen­den­cy? Who’s go­ing to use it? Pugs ini­tially did ap­par­ent­ly, but per­haps that’s just be­cause it was there - when I looked at Pugs/H­sJudy in 2007, cer­tainly Pugs had no need of it. (The data par­al­lel physics en­gine is prob­a­bly an­other good ex­am­ple. Is it just a bench­mark for the GHC de­vel­op­ers? Is it in­tended for ac­tual games? If the for­mer, why is it a SoC pro­ject, and if the lat­ter, is­n’t that a lit­tle hubris­tic?)

  3. Lack Of Mar­ket­ing

    One of the rea­sons Don Stew­art’s bytestring li­brary is so great is his re­lent­less evan­ge­liz­ing, which con­vinces peo­ple to ac­tu­ally take the effort to learn and use Bytestrings; even­tu­ally by net­work effects, the whole Haskell com­mu­nity is affected & im­proved13. 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 up­dat­ed? In­differ­ence can be fa­tal, and can de­feat the point of a pro­ject. What good is a li­brary that no one us­es? These aren’t aca­d­e­mic re­search projects which ac­com­plish their task just by ex­ist­ing, after all. They’re sup­posed to be use­ful to real Haskellers.

Future SoC proposals

There are 2 ma­jor col­lec­tions of ideas for fu­ture SoC pro­jects, aside from the gen­eral frus­tra­tions ex­pressed in the an­nual sur­vey:

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

  1. port GHC to the ARM ar­chi­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 us­ing the LLVM back­end to . It would be some­what tricky, but LLVM al­ready has fairly solid cross-com­pi­la­tion sup­port, and mak­ing GHC ca­pa­ble of us­ing it seems like a rea­son­able project for a stu­dent to tack­le.
  2. “Im­ple­ment over­lap and ex­haus­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 er­rors.
  3. In­cre­men­tal garbage col­lec­tion: this may be a good idea de­pend­ing on how much of the code was al­ready writ­ten. But I fear that this would go the way of the Im­mix GC SoC and would be a bad idea.
  4. “Thread­Scope with cus­tom probes”: I don’t un­der­stand the de­scrip­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 li­braries be­fore, 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”: Un­cer­tain. Go­ing by the Arch down­load sta­tis­tics, Thread­scope is down­loaded more often than one would ex­pect, so per­haps in­te­gra­tion would be use­ful.
  7. “Had­dock with em­bed­ded wiki fea­ture, a la RWH, so we can col­lab­o­rate on im­prov­ing the doc­u­men­ta­tion”: This is a bad idea mostly be­cause there are so many di­verg­ing ideas and pos­si­ble im­ple­men­ta­tions - it’s just not clear what one would do. Is it some sort of Had­dock server? A Gi­tit wiki with clever hooks? Some light­weight in­-browser ed­i­tor com­bined with Darcs?
  8. HTTP Li­brary Re­place­ment”: A good idea, as­sum­ing the linked at­tempts and al­ter­nate li­braries haven’t al­ready solved the is­sue.
  9. “Us­ing Type In­fer­ence to High­light Code Prop­erly: The diffi­cult part is ac­cess­ing the type in­for­ma­tion of an iden­ti­fier in­side a GHCi ses­sions - a prob­lem prob­a­bly al­ready 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 Op­ti­mi­sa­tion Tool”: This ini­tially sounds at­trac­tive, but pre­vi­ous refac­tor­ing tools have been ig­nored. The tools that have got­ten up­take are things like GHC’s -Wall (which warns about pos­si­ble se­man­tic is­sues) and hlint (which warns about style is­sues and re­dun­dancy with stan­dard li­brary func­tions) - not like Hera.
  11. “We­bkit-based browser writ­ten in Haskell, sim­i­lar in [plug­in] ar­chi­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 en­tire op­er­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 in­ci­den­tally through sup­port­ing li­braries), nor a task it is uniquely equipped for. It is an in­fi­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 be­ing diffi­cult to coax per­for­mance out of; and diffi­cul­ties would likely be ex­ac­er­bated by the usual Haskell is­sues with space us­age & lazi­ness. (DPH/CUDA use un­boxed strict data, but there are in­ter­face is­sues 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 in­stead how ‘pop­u­lar’ it is. There are a few differ­ent sources we can ap­peal to:

  1. Pack­age down­loads:

    1. Don Stew­art pro­vid­ed, for , Arch down­load num­bers (de­funct)
    2. The De­bian (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 re­port which will be closed by Matthew Gru­en’s Hack­age 2.0 (2010 SoC)
  2. Re­verse de­pen­den­cies can be ex­am­ined sev­eral ways:

    1. Hack­age De­pen­dency Mon­i­tor
    2. ca­bal-query
    3. Hack­a­geOne­Five
  3. Search­ing for men­tions, blog posts, and un­re­leased pack­ages else­where; key sites to search in­clude:

    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. Be­low is a slightly cleaned-up ver­sion of my com­ments there.

    I re­ally ap­pre­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 ex­cit­ing im­prove­ment for the en­tire 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 re­sults that live on, but which aren’t im­me­di­ately rec­og­niz­able as awe­some new things. Fur­ther­more, GSoc ex­plic­itly lists a goal as in­spir­ing young de­vel­op­ers to­wards on­go­ing com­mu­nity in­volve­men­t/open source de­vel­op­ment, and these notes don’t re­ally take that into ac­count.

    For ex­am­ple, I don’t know of any di­rect up­take of the code from the Haskell­Net pro­ject, but the au­thor did go on to write a small text­book on Haskell in Japan­ese. As an­other ex­am­ple, Ro­man (of Hpysics [sic]) has, as I un­der­stand it, been in­volved 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 nu­ances. Per­haps some­thing like the fol­low­ing:

    • Stu­dent com­pleted (i.e. got fi­nal 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 im­pact (i.e. wide use/no­tice­able im­pact)
    • Stu­dent con­tin­ued to par­tic­i­pate/­make con­tri­bu­tions to Haskell com­mu­nity

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

    1. GHC-plugins – Not only was the work com­pleted and does it stand a chance of be­ing merged, but it ex­plored the de­sign space in a use­ful way for fu­ture GHC de­vel­op­ment, and was part of Max be­com­ing more fa­mil­iar with GHC in­ter­nals. Since then he’s con­tributed a few very nice and use­ful patches to GHC, in­clud­ing, as I re­call, the mag­nifi­cent Tu­ple­Sec­tions ex­ten­sion.
    2. GHC refac­tor­ing – It seems un­fair to clas­sify work that was taken into the main­line as un­suc­cess­ful. The im­prove­ment weren’t large, but my un­der­stand­ing is that they were things that we wanted to hap­pen for GHC, and that were quite time con­sum­ing be­cause they were cross-cut­ting. So this was­n’t ex­cit­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 un­der­stand, and it still breaks be­tween re­leas­es, but it has an in­creas­ing num­ber of clients late­ly, as wit­nessed by dis­cus­sions on -cafe.
    3. Darcs per­for­mance – by the ac­count of Eric Kow & other core darcs guys, the hashed-s­tor­age stuff led to large im­prove­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, be­cause the judge­ment cri­te­ria are too harsh and too ar­bi­trary. They re­flect a bias to­wards “suc­cess” of a gsoc project as some­thing mea­sur­able di­rectly mea­sur­able in up­take and users within a rel­a­tively short span of time.

    GSoC projects are cho­sen, on the other hand, with an eye to­wards long-term pay­off in Haskell in­fra­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 in­ter­est­ing, use­ful, or im­por­tant.

    ↩︎
  3. For ex­am­ple, how long must a stu­dent ‘con­tinue to par­tic­i­pate/­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 de­vel­op­ers on the pop­u­lar win­dow man­ager, but then wound down his Haskell con­tri­bu­tions and stopped en­tirely ~2009 (much to my dis­may as an Xmonad de­vel­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 re­ply.)↩︎

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

  6. As of 2011-03-18, I have lo­cal 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 de­vel­op­ment that sur­prises me, since I had been un­der the im­pres­sion that most GHC work ul­ti­mately winds up be­ing scrapped or aban­doned like Liskell or Mo­bile Haskell.↩︎

  8. 2011-12-11, Google+:

    “Re­gard­ing the par­al­lel ca­bal-in­stall patches - Dun­can is con­cerned that my changes are too in­va­sive. I hope to get them merged in dur­ing the next few months after some re­work­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 de­vel­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 ex­pres­sions over a pipe as op­posed to be­ing a one-shot CLI tool.↩︎

  11. On Google+:

    Ah, gh­cLiVE is­n’t de­signed to have a server host­ed, it’s de­signed to run out­side a sand­box. Not that I would mark this suc­cess­ful my­self, but mostly be­cause it uses Yesod and ca­bal de­pen­dency hell means very few peo­ple ended up us­ing it…I’d like to port gh­clive to scot­ty, which has far fewer build de­pen­den­cies, I think peo­ple would ac­tu­ally use it then

    ↩︎
  12. Guess­ing 50% sim­pli­fies the cal­cu­la­tion, and is­n’t too far off: Do­ing a quick sum of all the non-2012 suc­cess­ful/un­suc­cess­ful rat­ings, I get a chance of be­ing 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 is­n’t ter­ri­bly differ­ent from a guess of 0.5.↩︎

  13. Many good and worth­while projects suffer this fate be­cause of their aca­d­e­mic ori­gins. There’s no re­ward for some­one who cre­ates a great tech­nique or li­brary 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 ac­knowl­edges, but how often does any­one ac­tu­ally use any of it?

    (It­er­a­tees may be the ex­cep­tion; al­though there are some­where up­wards of 5 im­ple­men­ta­tions as of 2010 by Oleg and oth­ers lead­ing to a ver­i­ta­ble Tower of It­er­a­tee sit­u­a­tion, the orig­i­nal it­er­a­tee has picked up 4 re­verse de­pen­den­cies, its most pop­u­lar suc­ces­sor 33 and it­er­a­tees in gen­eral may one day be­come as widely used as bytestrings.)↩︎

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