It seems like this week’s popular anti-Ubuntu FUD is that Canonical are missing people who can fix particular classes of bugs, many people have said the same thing in comments on my previous blog post.

So I’d like to point out that Canonical are Hiring! and we have many open positions listed on our Employment page.

If you’d like to work on open source software, for a fun company with some of the smartest people you’ll ever work with, or you know someone who would, don’t hesitate to check it out.

There’s been a meme going around the open source community for a while now.  That programming in C is somehow dirty, distasteful and worst-of-all inefficient compared to programming in a high-level language such as C# or Python.

Its detractors will tell you how it takes much longer it takes to program anything in C.  They’ll point at how much C code it takes to do something as simple as create a GObject sub-class compared to the equivalent in Python or C#.  They’ll also probably complain that everything in C has to be compiled first, which takes even more time up.

No argument would be complete without them pointing out that C has no standard types for strings, let alone linked lists, binary trees, associative arrays, etc. and that you have to spend all that time implementing your own.  They’ll probably make a point about how C’s static type system means that even if you have a array type, you need to know in advance what types you’re going to put into it and can’t just mix and match.

Don’t feel tempted at this point to counter with a discussion about how great and flexible pointers are.  You’ll receive a lashing about how they’re even more evil than people who talk in the theatre.  The rant about the C problems of uninitialised memory, out of bounds pointer errors and segmentation faults is a timeless classic.  Especially when they get to the bit about how much time was lost debugging them.

And do you know what?

I simply do not agree with them.

I cannot think of a single project where the majority of time was wasted writing GObject header files compared to the single line of Python I needed.  I can think of lots where I’ve sat for hours trying to figure out which class I needed to derive from, or reworking the code after I realised I derived from the wrong class to begin with.  The high-level language doesn’t make this any easier.

As to the number of projects where I’ve needed to write a linked list or hash table implementation because C lacked a convenient dynamic array or associative array type like Python?  If it takes you any time to write that kind of code, you’re doing it wrong.  I’ve spent far more time realising that the structure is a performance bottleneck, and planning on the whiteboard a faster alternative.  Neither language helps with this whiteboard time.

And all those pointer issues?  This comes down to the tools that you’re using.  If you’re writing in a language and not using its development environment properly, then it’s little surprise that you’re not being as efficient in it.  gdb, valgrind, gprof and gcov are your friends.  Use them well.  I’ve spent just as much time dealing with other language-specific issues to make me believe that pointers aren’t any more evil as (for example) monkey patching.

The vast majority of my time on any new project is first of all spent thinking, and on a more mature project its figuring out what I did wrong and how I need to rework it.

Yes, the next biggest use of my time is working out what the best way is to express that.  If I’m writing in C, that means I’m deciding whether it needs a linked list, or a hash table, or some other fancy structure.  But if I’m writing in Python, believe me I spend just as much time normalising my class structure and coming up with all sorts of insane Pythonic ways of doing things.

If you’ve ever written in Perl and not lost a day or two to optimising your regular expressions, or eliminating code to arrive at the shortest possible expression, you’ve never written in Perl.

Refactoring takes you just as long in Python as it does in C.  Just because when you do it to C code you end up setting segfaults doesn’t mean that when you do it to Python code, suddenly your class structures don’t match anymore.

Proponents of test-driven-development, AGILE, LEAN and ANEMIC programming methodologies will probably argue that it’s easier to practice their religion with a high-level language.  I’m not buying that either, I’ve managed to write several large software projects in C that have a comprehensive test suite – including testing for allocation failures.

Ah, Rapid Application Development I hear you say?  Well, the only people I’ve ever heard say how great RAD is are people who’ve never had to support the software that was written rapidly, or debug issues with it years later.  RAD is great when v2 is going to be a complete rewrite, and v3 a complete rewrite again.  Very few websites have upgrades without announcing a completely new codebase.

It’s certainly true that it’s faster to mash up some code in a high-level language.  I use shell scripts and bits of Perl for this kind of thing all the time, and I frequently even do basic mock-ups or essays in Python.  But ultimately it all tends to be throw-away code, that I don’t really ever intend to take seriously or attempt to support later on.

For larger projects, I just don’t see any difference in the time it takes to write.

I’d like to cite an example.  The GIT and Bzr revision control systems are about the same age, one of them is written in C and one of them is written in Python.  It hasn’t taken them any less time to write the one in Python than it’s taken the others to write the other in C.  The one in Python doesn’t have extraordinary features that the one in C lacks.

C# fans would point out how much faster it is to UI code.  Really?  Then why isn’t Banshee that much dazzingly better than Rhythmbox?  Sure they’re different, but there’s nothing there that suggests one language is better than the other.

And do you know what?  I trust code written in C far more than I do any higher level language.  No, that’s probably not fair.  I trust C programmers far more than I do programmers of other languages.  If you tell me I have the option of choosing a program or library written in C over one written in Python or C#, I’ll take the C one every time.

Here at Canonical Towers we have several staff who worship at the altar of Extreme Programming, and as such many of the methodologies and rituals prescribed by that religion find their way into our day-to-day working practices. A few of these came together in an interesting way a few weeks ago, and it was suggested by a cow-orker that I blog about it so he could give the URL to people.

The first ritual is that of the sprint, I don’t think this is orthodox XP but rather something inspired from it that we picked up from the Python community. With all of the Canonical developers scattered across the globe mostly working from their own homes, it’s become a useful tool; particularly for the Launchpad team.

The basic idea for those that haven’t heard of it is simple, and perhaps obvious; you get a selection of the team together in one place, sit them around the same table with particular goals to complete. In effect it’s highly compressed facetime and high bandwidth interaction to nail those tasks that need it, before you head off again and work at a more sedate pace.

The second is directly from XP doctrine and is that peculiar observance known as pair programming, something that is often coupled with sprints. For anybody who hasn’t encountered this before, it’s something I’ve always found rather odd. You get two programmers together, both itching to code, and you take one of them’s laptop away; and you don’t just force them to fight over the keyboard either, the laptop-less soul isn’t allowed to touch it.

The theory here is that it frees the deprived individual of the hassle of coding and allows them to direct the programmer in ways that may not be immediately obbious, or alternately think about the next bit of work that needs doing. Another interesting side-effect is it can be an interesting way to learn code you’ve not worked with before, if you’re the one doing the coding and you’re being guided what to do by a sage who already knows it.

I have a funny story here, so I’m going to digress from the main stream for a moment to tell it. A few months ago I was working in the London office, Mark had been up all night coding and had then given me responsibility to get his changes landed onto the Launchpad mainline. I’m not that hot on quite a bit of Launchpad, and fade to utterly clueless the nearer the code gets to the web application itself; and when trying to merge the two there were conflicts which I needed Mark’s help to resolve.

Now as anybody who’s met Mark knows, he’s a pretty good example of a Type-A personality, yet he suggested that we do a spot of pair programming to get the code in and I’d be the one with the laptop as it’d help me get to grips with the affected parts. This hilighted something I’ve always seen as a problem with pair programming, dealing with it when the a person with the keyboard has a totally different way of working to you. In particular, I’m an emacs user, whereas Mark is a die-hard vim user; but also right down to the working directory I would work from, how I test results, etc.

When you’re the one without the laptop, this can be quite infuriating, as you know exactly how to solve a problem and the idiot with the keyboard is dithering about doing things you don’t understand just to get there. If you’re a Type-A personality, you generally snatch the laptop away at this point and do it yourself; or at least you would, if you could drive the strange editor the other person uses.

I swear Mark was sulking as he gave the laptop back and let me do it.

Anyway, there is some relevance to that and we’ll come to it in a moment.

The third and final methodology is the concept of unit tests and more specifically test driven development. For anyone who hasn’t come across this before, I highly recommend it; I was suspicious too when Robert Collins took it upon himself to teach me the true way, but now I’m sold.

Simply the idea is that if you have any code that doesn’t have another piece of code in a test suite that checks that it’s working correctly, that code is broken. More particularly unit testing involves checking just one feature or requirement at a time, and stacking them together to test all of the code paths. I’ve actually found that this improves the APIs I design, as I write the code in small blocks and functions to make them easier to test.

Test driven development takes it even further, you write the unit tests first, before you write the code they’re supposed to test; usually one or two at a time. Obviously these tests will fail at first, it’s then your job to write as little code as possible to make them pass. If your code isn’t right, you add a unit test that will fail, and modify the code to make it pass.

This really comes into its own when you’re fixing bugs later, once you’ve identified the bug you write a test case or two that cause the problem; these will of course fail. You can then modify the code to make them pass, and at the same time be sure you’ve not broken other functionality because of the existing test suite. I’ve also found it really useful for particularly complicated or tricky pieces of code, especially those intricate algorithms that do particularly heavy lifting.

So onto the event itself, this was a sprint in our London office to indoctrinate Gustavo Niemeyer with the various projects he’d be working on. The goal for this sprint was decided to start the conversion of HCT to Bazaar-NG, and to do this Gustavo and I would pair program.

Now my last experience of pair programming had been that story with Mark (see, it had some relevance) and I knew I’d be just as bad if I wasn’t allowed to have the keyboard. I was also acutely aware that if Gustavo was just sitting by and watching, he wouldn’t get much benefit from it either, so he needed to be actively involved in the coding so he could learn the things he’d be working on.

I came to what I thought was a pretty neat, and obvious, solution to these problems. We set up my laptop with the code we’d be working on, and on my display were two side-by-side terminals both running screen sessions. Gustavo then set up two same-sized terminals on his, ssh’d into my laptop from both of them and joined the screen sessions. In the left-hand one he ran vi, and in the right-hand one I ran emacs.

Thus we both had keyboards, and both had editors, yet could see each other working and even steal the keyboard without danger of violence. We didn’t just sit side-by-side and code on different things though, that’s not pair programming and is just ordinary programming with a bit of a voyeuristic twist.

What we did was: in my terminal I started writing the test cases for the code we needed, it was Gustavo’s job to write the code that would make them pass. We actually added a third terminal in which we could run the test cases themselves; so I could run them when I’d added something that would fail, and Gustavo could run them when he thought he’d made them pass again.

This turned out to be a rather fun way to work, and at one point I was almost able to try and convince myself that the code was writing itself to pass the test cases I was writing. It also got me thinking that it’d be really neat to use genetic algorithms to breed code to pass test cases.