Rhope Crash and Burnby Mike Pavone
Sometime during the development of Rhope, I thought it would be neat to make an entry into the ICFP programming contest and then release the language immediately after the competition was over. By the time the 2007 ICFP contest came around, I decided Rhope was ready enough to give it a shot. I knew I had basically no shot at winning (the ICFP contest is challenging enough with a mature language), but I figured Rhope was ready enough that I wouldn't completely embarrass myself. So I called up a couple of my college buddies and team Rhope Burn was formed.
In the time leading up to the contest, one of my teammates said he was interested in trying to use the visual part of the language for our entry. I rather liked this idea, but there was a small problem. I had abandoned the old visual editor as an unmaintable wreck of source code. My intention was (and still is) to rewrite the editor in Rhope itself once the language had the requisite features to do so. At the time, the interpreter could only run a single program at once and there was no functionality to construct a program from within the language itself so writing this new editor wasn't particularly possible (well I could have made one that translated the visual program into a textual program, but that would have made the graphical language a second class citizen).
So I started in on adding the necessary features in the hopes I could get at least a basic visual editor working in time for the contest. For some inexplicable reason I didn't think to do a SVN commit or at least a backup of the current source code before I started this little endeavor. This proved to be fatal to our chances in the contest, but I'll get to that later.
At this point, neither of my team members knew how to program in Rhope. Being the procrastinator that I am, I only managed to deliver them a tutorial a few days before the start of the contest. Responding in kind, neither of them actually looked at the tutorials until after the contest started. To make matters worse, one of them decided he wouldn't be able to learn the language in time to be of any help.
Those changes I started working on to support the visual environment introduced some rather nasty bugs in the interpreter and the most recent copy of the source I had from before I started that change was too old to be useful. There were also other serious bugs in the interpreter that I was unaware of. I hadn't written anything other than relatively trivial programs in Rhope at that point. Once I started working on our competition entry, a bunch of new bugs I hadn't seen before came out of the woodwork. As a result, I spent more time fixing bugs in Rhope than working on the problem. Since my sole remaining teammate was still a Rhope novice, he wasn't able to make up for my huge drop in productivity.
Sometime late Sunday night, we had written a DNA interpreter. Individual parts had been tested, but the program as a whole had not. I added my teammate's code to mine and gave it a spin. The interpreter crashed.
It didn't make any sense. His code worked fine by itself and so did mine, but when I put the two together the interpreter would crash right away. With my mind addled by lack of sleep, I wouldn't figure out the problem until my commute to work the following morning. Team Rhope Burn had failed.
Still, participating in the contest was a valuable and enjoyable experience. For the first time, someone other than me had written code in Rhope. It was also my first experience working with a distributed team of programmers and my first experience with a coding competition. Our lack of success also made it clear that Rhope wasn't ready for public consumption.
Rhope has come a long way in the past year, so hopefully team Rhope Burn won't fail so spectacularly in 2008's competition. I'm still looking for one or two people to join the team. If you want to join, e-mail me at email@example.com or add a comment here.