Compound Thinking

Python, Ruby, Rails and Readability

When developing code you should always choose readability over convenience. Code will be read many, many more times than it is written…

–Practices of an Agile Developer by Venkat Subramaniam Andy Hunt

This quote from Ruby advocate and Rails book author Andy Hunt, explains why I work in Python even though Ruby has anonymous blocks and slightly less historical baggage than Python.

I recently taught a couple of free introductory classes, one for Python and another for Ruby. People with little experience in either language, could quickly read Python code. But with Ruby — and Rails in particular — there is so much heavy use of the “power features” of the language — like dynamic classes — that code readability was severely compromised. New programmers were quickly confused and lost. There were lots of “where does this happen” questions. Dave Heinemeier Hanson carries most of the blame here: Rails is built on his philosophy that values “convention always trumps configuration” and “less code is better” so highly that other critical considerations like the value of locality and orthogonality play in making code readable. In my view this is a serious mistake. After all, Code is read more often than it is written!

Wherever possible methods should be understandable on their own. No matter how powerful dynamic classes and objects are, using them means there will always becode elsewhere in your system that changes the behavior of the code you write — that means you have to know about and understand all of that elsewhere just to understand — and debug — the object in front of you.
For example, Rails has this nifty feature where Database classes map to table names that are the plural of the class name. This auto-pluralization like other Rails hacks is cute and fun at first, and it certainly makes the surface of the code shiny and pretty, but it also creates a layer of indirection and “magic” that obscures what is happening under the covers.

Of course, sometimes you have to make hard choices and it’s worth sacrificing code readability for other concerns. I’m not disputing that, I’m just saying the code you write — if it’s used and maintained — is going to be read many, many more times than it is written. So, you ought to optimize for the code reading experience, and more than any other language I’ve used, Python is designed just that.

TurboGears at Penguicon

I’ll be doing an hour and a half introduction to TurboGears next weekend at Penguicon. So if you are in Great Lakes area, and you want to get a jump on developing dynamic ajax-enabled web applications feel free to stop by. It should be a lot of fun.

But, I’m not just plugging my talk, I’m also looking for help. I would like to video-tape my tutorial, and need a couple of people to help me make that happen. I think I can get one mini-dv camera, but I’d like to set up a second camera for crowd shots, close up shots, and various other pieces. To really make this work I would also need somebody to help with cameras and sound.

Ultimately, if we can make it work out I’d like to post this so that we can have a more extended TurboGears tutorial available online.

Verbal Inflation Costs Real Money

It is easy to tell stories to ourselves and to others that exaggerate, bend, or even outright break the truth. Especially when we are under stress, especially when we are in a hurry, especially when we feel let down.

“They always drag their heels on things like this” is not the same as “They try very hard to make sure that everything goes through a review loop.” But both are stories told to me about the exact same event.

Lately I’ve caught myself telling the first story by emotional reflex rather than thinking my way through to the second, and because we are all under a lot of pressure recently, I’ve seen others doing the same thing.

Luckily enough, an article about this showed up on my desk the very day I needed it

Really? Is That True?
We’re all well acquainted with financial inflation: a fall in the value of money over time. But there’s another type of inflation that’s far less understood, much more common and infinitely more harmful. It’s verbal inflation: people’s tendency to use speech that exaggerates the size—or impact, frequency, or emotional nature—of situations and events, making them far sound worse than they are. And it’s another situation where slowing down usually provides the answer.

Python Database Projects Arise!

I just saw a post on bringing SQLAlchemy and Zope Transaction Manager together, now that’s good stuff.

I’m looking forward to having time to look into both of these projects soon. It seems like projects at work and TurboGears in general could certainly benefit from the combination of a good general purpose Transaction Manager, and a good ORM based on the Data Mapper pattern.

All this got me thinking about Python’s Database connectivity story. Yes, SQLObject and the Active Record pattern is easier to use than SQLAlchemy and the Data Mapper pattern. But, it is also true that Active Record is just a subset of Data Mapper where there is a 1 to 1 mapping between objects and table rows. So it should be fairly easy to implement an active record type interface on top of a good Data Mapper.

Then you get all the ease of use of Active Record, and only a small step up in complexity gives you all the power of Data Mapper. You can use both patterns in the same application, and choose the level of abstraction you need.

There are two projects working on this, Active Mapper, and Pocoo’s DatabaseApi. This is one place where Python is on the edge of greatness. SQLAlchemy is way easier to use and than Hibernate, and is already almost as powerful. Moreover, I don’t know of anything like it in Perl, Ruby, or even Smalltalk.

Stay tuned. The revolution will be televised.