[Abqlispscheme] ICFP 2008

[Daniel Lyons]

On Jun 12, 2008, at 9:39 AM, Denis Bueno wrote:

> On Thu, Jun 12, 2008 at 11:29, Daniel Lyons <fusion at storytotell.org>  
> wrote:
>> languages if they are more amenable to the problem (using Haskell in
>> spite of itself last year made things suck.)
>
> I didn't participate last year, but I'm just curious:  what sucked
> about Haskell?


It's not really fair to lay all the blame on Haskell. The real problem  
was bad project management. We were using Haskell because we thought  
Haskell was cool. Haskell is cool, but only one team member was really  
fluent in it, and one other (me) could get by with it to some degree.  
The other two team members didn't know it at all and were planning on  
picking it up as the contest went on. You can guess how well that  
worked out.

Now, the problem itself seemed to us to dictate a mutable data  
structure and the algorithm seemed to require non-local return. If you  
know Haskell, you see those two requirements and hear two monads. We  
probably could have factored it into a manual continuation-passing  
style, but we weren't clever enough for that, so we wound up trying to  
nest the two monads, in other words, using a monad transformer. Monad  
transformers were new to the team member who knew Haskell and  
definitely beyond my comprehension at that time. So we wound up with  
extremely complex Haskell code only one of us really could understand.  
I bit my tongue, thinking it would have been a lot easier and prettier  
in OCaml where those two requirements would not have posed a problem.  
I even wrote a rope data structure for OCaml after the contest  
(someone else made a nicer one and released it publicly).

However, many of the teams that did well at ICFP last year noticed  
that the problem had to do with drawing images and that the organizers  
probably put clues into the act of drawing itself. So they built GUI  
applications which let them step through the drawing functions and  
watch them happen. This probably would have helped us debug our  
drawing routines, which were broken through the whole contest, but the  
organizers had in fact left clues: the code would draw hints on the  
image and then erase them so that if you had a process that just did  
all of the drawing at once and output a single image at the end, as  
ours did, you weren't able to get the clues to advance.

I don't consider Haskell to be a very good language for GUI  
programming right now, though I guess it's fine if you're on Windows  
or using GTK+. I'm not sure Lisp would have fared any better on that  
front though.

I probably place more blame on Haskell than I should. But I definitely  
felt after the contest that Haskell had made a complex problem more  
complex rather than simpler.

On the other hand it seemed to me like last years contest results were  
much more stratified than the previous year's. It seemed that there  
was a chunk of 50ish teams at the top who had made varying progress,  
then about 130 teams that made the basics work but made no real  
progress (my team, Functional Healing, was in that set) and then the  
remaining 600 or so teams that didn't even get that far. The spread  
was a lot better on the Umix challenge.

Also, last year's challenge didn't seem to benefit from having  
multiple team members as much, but that may just be that they  
underestimated the difficulty of getting through the first barrier.  
Comparing anything to the Umix contest isn't really fair though; that  
was really a revelation and one of the most rewarding things I've ever  
been a part of.

-- 
Daniel Lyons
http://www.storytotell.org -- Tell It!