I love Python

Today's distraction is Python and scripting languages, so non-programmers should probably go browse YouTube while the nerds get their freak on.

Back in the day when I had a job, I found myself assigned to a long-running major project that relied on lots of special scripts to help the build, validation and release processes. The problem was that the project was so long-lived that the people who had written those scripts had left ages ago and had taken their specialist script-writing skills with them. Since everyone else was so busy writing the project code, they had no time to spend on the scripts and besides, they were C++ wonks and treated the build scripts as magical voodoo that either worked, or didn't. Increasingly, they didn't.

As the project had grown, it had changed. Source code wasn't where it used to be. New types of resources were added in new subdirectories and the scripts weren't updated to process them. Additionally, poor design required stupid bodges like the source tree being subst-ed to a specific virtual drive on everybody's PC, or the script simply wouldn't work.

Shortly after I joined the project, I was asked to run the validation software over our source code, so we could send a report to the customer showing them how full of quality it was, which it was, it was just the non-deliverable scripts that we'd let ourselves down on. Anyway, I dug out the validation script, ran it and was rewarded with abject failure- the script couldn't find PC-Lint.

Digging through the script revealed a number of horrors. PC-Lint was installed on a single machine for licensing reasons (presumably) and was called remotely by the script. Problem was, the company naming scheme for PCs had changed since the script was written, so the script could no longer find the computer with PC-Lint on it. I fixed the broken link and realised that the machine with PC-Lint wasn't even a server, but was some engineer's desktop PC. Better still, the engineer had switched projects and as required by our security standards had wiped his PC and installed a clean image onto it, without PC-Lint. Where's the installation media for PC-Lint? Best ask our tech support people, they'll raise it as an issue on their magical issues database and ignore it.

The other major horror I found was the script itself; it was written in Perl. Perl is a wonderfully powerful language and I'd always wanted to learn it, so here was the perfect excuse... er, opportunity.

The problem was that I was trying to learn Perl by trying to fix a complex existing script rather than by writing my own stuff from scratch. Perl's philosophy is "there's more than one way to do it", which means that it makes very little demands on how the programmer writes his program. You can write very cleanly and elegantly, or you can write an incomprensible mess (like this post, but with more $, % and &). The code in question was very much of the second variety. Very clever code, but practically incomprehensible to any poor sod other than the original author. Great for job security, except that I collared the original author to have a look over it and he couldn't understand it either- too much time had passed between writing the code and re-reading it, he'd forgotten his original chain of thought.

I got it working eventually (after a certain amount of complaining from management that the other guy used to only take an afternoon and why was it taking me so long?) and delivered the report that proved how ace our proper code was, but after that, I started getting assigned all the script-fixing tasks by my team leader who unlike upper management knew exactly why it had taken me so long and why no-one else had run the script in over six months despite it being a weekly deliverable. Time and again, my mental gears clashed because all of a sudden the original programmer had suddenly used an unless statement instead of an if, which is even better in a one liner, because then the conditional unless is after the conditionally-executed statement...

Anyway, I began to wonder if there wasn't perhaps a better way to do things. A cleaner way. A way where an engineer could write a script, then six months later a completely different engineer could look at it and actually not have to spend the day flicking back and forth between the editor window and the language documentation, looking up obscure forms of use for common language features. Eventually, I looked into Python.

In contrast to Perl, Python's philosophy could be described as "There's one way to do it". Python code is generally a lot more readable than the average Perl script. Yes, you can write clean, readable Perl, but it requires discipline from the programmer that often isn't there. Generally, it's a lot quicker to get the gist of a Python program than for Perl, even for developers who don't have any background in either language (at least it was for the poor sods on my team that I tried my ideas out on). Sure, a lot of programmers will throw a fit at the idea that indentation matters, but if you threaten them with a really messy Perl script with plenty of regexp line-noise in there, they eventually give up and see things my way.

I rewrote a few of our Perl scripts in Python in my spare time and found that while a lot of text-processing tasks are easier to write in Perl, the Python equivalent is often more maintainable; six months later, I could still understand how the script worked. Perl makes for brilliant hacker-ish programs, Python can make for maintainable code, which is immensely important for a software engineering team, if you can convince people to get past installing yet another scripting language.