The right tool for the job


It is easier to bang in a nail with the back of a screwdriver than with a handleless hammer (believe me, I’ve tried and it wasn’t pretty). Even though a hammer is the right tool for that job, sometimes you have to switch tools if the one that you would like to use isn’t complete.

When we began Helium a few months ago, I’d hoped that we would be able to use Python for most of the project. Python is my favourite programming language, and I felt that it would help the project with productivity (by reducing the amount of time spent struggling with syntax) and longevity (since code that is easier to read is also easier to maintain). Since then, I’ve discovered several other more important reasons why Python was the right tool for the job. So why, then, is Helium written in Java?

The answer to this question can be found on the PythonInfo Wiki under WebProgramming. In order to list all of the web frameworks in Python, you have to scroll through several screenfuls of names. This, in and of itself, is enough to make me cringe. I can’t help but feel that this goes against part of Python’s spirit. In fact, one of the postulates of the Python philosophy states that “there should be one – and preferably only one – obvious way to do [something]”. It turns out that there isn’t just one obvious way to build a web application in Python: there are several pages worth of options to choose from.

If the problem only ran as deep as having to make a choice between them, I wouldn’t mind so much; I can get a coin (or, in this case, a 70-sided die) to make that decision for me. The real problem with this kind of rampant fragmentation is that you have no guarantee that the piece you choose will still be an active project in one, two, or five years from now. Furthermore, every piece will be far less mature than if there were very few options to choose from, since the developer effort will be spread thin across so many projects.

Beyond the choice of web framework, it was no more clear which Python Object/Relational mapping tool Helium should use. Every developer you ask has a different opinion of what the best way to do this is in Python. Again, it’s not their disagreement itself which is the problem, it is what their disagreement implies: there is not a single obvious way to do O/R in Python.

For these reasons, we chose to write Helium in Java. For the first few weeks our language choice made little difference. But as Helium grew in size and complexity, we kept finding ourselves stumbling over the language, rather than having the language make our lives easier. There are currently three independent parts of Helium which had to be written in a wrapper scripting language (we, of course, chose Python) because we couldn’t get Java to do what we needed it to. We’re also heavily interfacing with Subversion, and the Python-SVN bindings are far more mature than the Java bindings. Over and over, I felt constantly reminded that Python was the right tool for this job. Unfortunately, it was the hammer without a handle.

On my next web application project, I would like to use Python. But I’m not going to feel comfortable doing so until there’s a clear “winner” or two in the web framework field. Just a few minutes ago, Jon from the Memview team asked me, “What sort of web architecture do you like to use with python?”, and I was forced to shrug helplessly. I didn’t have a good answer. His response captured my feelings exactly: “At least with php you dont have to choose”.