Extreme programming, kind of

A very large percentage of program errors – and the problem that drives programmers to debuggers – occur because variables obtain unexpected values during the course of program execution. Functional programs bypass this particular issue by simply not assigning values to variables at all.

From Functional Programming in Python.

Baby and the bathwater anyone? Maybe not though. It’s functional programming week again on aftnn.org. Been programming OCaml, getting into it. It’s kind of funky.

It all started on Saturday when Miles and I went to a programming contest run by the BCS. It was a bit of a surprise thing, Miles was going with some people from work, but they dropped out.

The competition was in Southampton of all places, but we got a lift from one of the members of London.pm. There was me, Miles and three judges in a Polo. It was the first year Perl had been allowed and they been drafted in to provide knowledge. On the drive down we discussed languages, the competition, Perl promotion strategies and much more. The most surprising thing was that they were all Mac owners.

The venue was an IBM research centre in a converted stately home, which was lovely, except for the horrible IBM-ification. The other teams were all bigger, about half half split between three and four members. A mix of age ranges. I thought it would all be students, but there were some guys in their thirties too. And some horrible t-shirts, in XL only.

The problems were nice really, some string processing, some graph stuff in the form of a package dependency calculator and some others. They were fairly straightforward, but we failed to do them in time. On the way down the driver judge, Leon, said “It’s a time management problem basically” and he was right, we failed for all the reasons that I used to fuck up exams. We didn’t read the questions thoroughly, we didn’t manage our time at all really. We spent far too much time on one problem, which we didn’t even solve! In fact, using Perl was more of a hindrance than a benefit. We tripped ourselves up a bit by not knowing the language totally inside out. If it had been Java, yes it’s a less flexible language, but that means I can know it all inside out more easily. Then again REs did help us parse quickly… and that’s how I got into the functional programming. After much postmortem I started thinking it would be really interesting to tackle the problems in different languages. I wanted to try a functional language. Lisp is interesting, but I know it a little bit (not enough), so I thought I’d try something else. Haskell seemed worth a go, but laziness and monadic IO takes a bit of getting used to apparently, so I thought I’d try one of the ML family and OCaml sounded the coolest, not least because it’s quick. I may try again in Lisp later. I’d like to have a go in Java as well. That one might actually be against the clock as well.

I’d quite like to go to the contest again next year:

  • More people in the team
  • More careful question evaluation - restating the problem as a set of bullet points probably would help
  • More paper design before coding (we did some this time, but not enough)
  • Better knowledge of the language

On the other hand, I felt like I was selected and tested randomly and I didn’t do so well. Next time I’ll be ready and it sort of seems like cheating. It’s certainly much less of a challenge. Then again the winners this time did get rather tasty Pocket PCs!