On Feb 9, 2011, at 6:18 PM, Gwern Branwen wrote:
2 years ago in February 2009, I wrote up a history of Summers of Code
through 2008
(http://www.haskell.org/pipermail/haskell-cafe/2009-February/055489.html).
But the Wheel turns, and years come and pass, leaving memories that
fade into 404s; a wind rose in Mountain View, whispering of the coming
Summer...
I have considerably expanded and updated the coverage:
http://www.gwern.net/Haskell%20Summer%20of%20Code.html
There was some discussion of this on reddit. [1] Below is a slightly cleaned-up
version of my comments there.
I really appreciate this roundup. But I think the bar is set somewhat too high
for success. A success in this framework seems to be a significant and exciting
improvement for the entire Haskell community. And there have certainly been a
number of those. But there are also projects that are well done, produce
results that live on, but which aren't immediately recognizable as awesome new
things. Furthermore, GSoc explicitly lists a goal as inspiring young developers
towards ongoing community involvement/open source development, and these notes
don't really take that into account.
For example, I don't know of any direct uptake of the code from the HaskellNet
project, but the author did go on to write a small textbook on Haskell in
Japanese. As another example, Roman (of Hpysics) has, as I understand it, been
involved in a Russian language functional programming magazine.
So I think there needs to be a slightly more granular scale that can capture
some of these nuances. Perhaps something like the following:
[ ] Student completed (i.e. got final payment)
[ ] Project found use (i.e. as a lib has at least one consumer, or got merged
into a broader codebase)
[ ] Project had significant impact (i.e. wide use/noticable impact)
[ ] Student continued to participate/make contributions to Haskell community
A few more detailed comments about projects that weren't necessarily slam
dunks, but were at the least, in my estimation, modest successes:
GHC-plugins -- Not only was the work completed and does it stand a chance of
being merged, but it explored the design space in a useful way for future GHC
development, and was part of Max becoming more familiar with GHC internals.
Since then he's contributed a few very nice and useful patches to GHC,
including, as I recall, the magnificant TupleSections extension.
GHC refactoring -- It seems unfair to classify work that was taken into the
mainline as unsuccessful. The improvement weren't large, but my understanding
is that they were things that we wanted to happen for GHC, and that were quite
time consuming because they were cross-cutting. So this wasn't exciting work,
but it was yeoman's work helpful in taking the GHC API forward. It's still
messy, I'm given to understand, and it still breaks between releases, but it
has an increasing number of clients lately, as witnessed by discussions on
-cafe.
Darcs performance -- by the account of Eric Kow other core darcs guys, the
hashed-storage stuff led to large improvements (and not only in performance)[2]
-- the fact that there's plenty more to be done shouldn't be counted as a mark
against it.
[1]
http://www.reddit.com/r/haskell/comments/fid5w/haskell_summers_of_code_retrospective_updated_for/
[2] http://blog.darcs.net/2010/11/coming-in-darcs-28-read-only-support.html
Cheers,
Sterl.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
