Compound Thinking

Change the World — One Program at a Time

This is a very late comment about Pycon2007.

At that conference one Ruby/Rails book author said something like; “I really like the vibe here. Everybody here is talking about making a difference, educating third world children, building better communities, and making the world a better place.” And he was setting this as a stark contrast to his experience of RailsConf where “everybody was talking about how much money they made.”

On one level it’s hard to fault the Rails conf people for this. Money does on some level validate what they’ve been doing, and it isgood to feel that kind of validation.

But, I think it’s fair to say that the Rails people have been too focused on proving something, and that has lead to a perception that many rails folks have a chip on their shoulder, or are totally focused on money as a metric of success. The extent that some elements in the Rails community have embraced this perception (as mentioned on Martin Fowler’s recent blog posting), is actually a bit frighting.

So, I think Chad is doing exactly the right thing by encouraging the Rails community to take a look at how they can improve their image. A couple days ago Chad posted a blog entry entitled “Change the world” and I hope that it makes an impact in the Rails community. I definitely see Chad Fowler many of the other members of the Rails community that I know personally as good guys, and I’d like to see the current negative stereotyping of the rails community come to an end.

I’d like to see the Rails community as a whole step up to the plate, and focus their attention and marketing efforts on new projects with altruistic goals. Turn the whold Buzz machine towards something that will really change people’s lives — replacing Java just isn’t a worthwhile goal when compared with helping to feed hungry people.

So, in the hope that a little good natured competition can spur things forward, I’d just like to mention that I think the Python community is beating the pants off of the rails community in the change the world department. Here are a couple of projects that I could think of off of the top of my head which the Python community is working on:

• Irrepressible.info — which is focused on fighting censorship
• the OLPC project — which aims to bring better educational materials to millions of underprivileged childeren around the world
• the Open Planning Project – which aims to provide tools for grass roots community improvement tools.

On another note, over the last 6 months or so Compound Thinking has been been working for Philantech on a project called PhilanTrack which takes a slightly different tack. The goal of the Philantrack project is to make it easier to manage the process of giving, receiving and reporting on grants.

The idea is that “greasing the wheels” of grant giving, and allowing non-profit organizations to focus more on doing the work, will make the nonprofits more efficient, more fun, and ultimately make the world a better place.

We may not think about it, but we geeks have a lot of individual power, and collectively we really can make the world a better place. If you’re working on a Rails or Python app that can change the world for the better, drop a comment here and let us all know.

TurboGears 1.1 Sprint May 26th

I’m trying to help organize a globally distributed TurboGears sprint for may 26th. And it would be a great place to get your feed wet with developing for the TurboGears core. So, if you’re up for a learning experience, and you’ve got some time it would be great if you could lend a hand.

If anybody is willing to show up in Ann Arbor, I can provide food, a place to hack, and some good clean post-sprint debauchery. For, unfortunately those sprinting outside of the Ann Arbor area will have to provide their own space, food, and most of all their own debauchery.

If you’re interested in participating in the sprint, please join the Sprint Coordination mailing list.

We’ve got folks committed to:

• Migrating test infrastructure to CherryPy 3
• Finalizing the TurboGears 1.1 configuration system, and implementing what we decide on
• Workiing on the turbogears SQLAlchemy integration to make it easier to use multiple databases
• Doing some general clean up of open tickets

My personal goal is to help get the trunk into a usable state, which means tackling the configuration issue. Once people can run their existing projects on the trunk, TG developers (like me) will be able to do our daily work on turbogears projects on the trunk. Which in turn should help us to attract more developers and testers and continue to make TurboGears a great tool for rapid web application development.

Code Mash

Some friends of mine are putting together a non-denominational developers conference called code-mash in Ohio this January.

Looks like Python and Ruby are both going to have a good number of talks. I’ll be talking about SQLAlchemy, which is the best object relational mapper I’ve ever seen. There’ll be talks about Test Driven Development in Python, Enterprise Architectural Patterns for Python developers, along with lots of cool talks about Lean Software Development, the side benefits of Test Driven development.

You can still submit a talk proposal before November 30th, and you’ll get free room and board. I think it would be great to see somebody talk about Dabo and Desktop application Development in Python, and they seem to be missing any talk about OSX/Cocoa stuff, which I’m sure is because they haven’t had any proposals yet.

It would also be nice to see a good cross platform development with Mono talk…

I’m really excited by the opportunity to get developers of all kinds together and talk about how to be productive and learn more about the strengths and weaknesses of the various tools/frameworks people are using.

Why I Like Python more than Ruby

Note: I’ve been sitting on this one for a week. I don’t want to be misunderstood, Ruby is my second favorite language, and it has a lot to love. But I keep coming back to Python, and I think I know why. So, here goes:

Yesterday Last Week, I in response to a post by Dave Thomas, I wrote about optimizing for readability.

Dave Thomas post basically amounts to an homage to Ruby at the expense of Perl.

Dave likes Ruby because it is far more readable, and therefor more maintainable than Perl. So far I’m totally on the same page. Readability is critical to maintainability and extensibility, and that’s where most of the work on any successful software project is going to be done.

But, here’s where we part company at least a little bit.

I happen to prefer Python over Ruby because optimizing for readability is much more a part of the philosophy behind Python. Most of the lines from the Zen of Python have readability implications:

Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.

Ruby makes better choices than Perl

But the language is still built around something they call “the principle of least surprise,” and the least surprised person here is the initial developer, not the code reader.

In practice means that there are several different names for the same array methods, and many array methods that are only slightly different from one another. If you are familiar with another language’s way to do it, the “least surprising” thing would be for that same method to just work on Ruby arrays right?

And this can make it easier to get started with Ruby. But there’s a downside, when reading Ruby code this means you may need to learn and remember all 78 different array methods. Some of them are obvious, .last will give the last element in the array. No worries there, and I like humane interfaces which give you easily understood and convenient functions, but this is just one example of how Ruby takes it too far, by forgetting that you will eventually have to figure out what eacy of those functions does in somebody else’s code.

Quick Ruby Quiz:

• is there a difference between array.size and array.length ? (no)
• How about array.map! and array.collect! ? (no)
• What about array.delete_if and array.reject ? (yes, reject returns nul if no changes are made)
• And for extra credit, why is there an array.collect (non-destructive) and an array.collect! (destructive) but not an non-destructive version of array.map! ?

I’ve been reading more Rails code recently, and while I like Ruby, and I admire Rails, I find myself constantly wishing I could hold more of this stuff in my head. I learned to write Ruby pretty quickly, but reading other people’s code has taken longer — just because there are lots of nooks and crannies in the built-in classes and modules that will take me a while to learn.

But Python makes better choices than Ruby:

Don’t get me wrong, I like Ruby. And it’s not particularly difficult to read. But the philosophy of the language designers led to design choices that emphasize writability over readability. And in that department I think the advantage has to go to Python. Python lists are easy to use, but more importantly I understood all of the list methods and how to use them in the matter of a few min. Perhaps Ruby’s arrays are more powerful that Python lists, but so far I’ve yet to find something that can be done in Ruby that can’t be done easily in Python.

I mean, think about it — even the things people complain about in Python, like the explicit self or significant whitespace, are designed to with readability in mind.

An Optimization That’s Never Premature

I’m pretty sure every software developer worth his or her salt, has heard of Fred Brook’s C.A.R Hoare’s statement, “premature optimization is the root of all evil,” famously repeated by Donald Kunth. One of the things you quickly learn when doing software optimization is that everything is a trade-off, you can increase performance by increasing complexity, decreasing reliability, limiting the degree of precision required, etc.

But I think there is one optimization that is never premature — readability.

I’m not the only one who sees readability as a key metric in writing maintainable software. Dave Thomas (author of The Pragmatic Programmer, and Ruby advocate) recently wrote the following:

But there was a problem [with my use of Perl]. Perl is a great language…. But even on my most charitable days I could never really claim that these Perl programs were exemplars of readability. And, in turn, this lack of readability made it hard for me to pick one of them up six months after I’d written it and make some change—even small alterations could involve long periods of head-scratching as I tried to work out exactly what the entries in my hash of arrays of hash references actually contained.

Amen, Dave! If you can’t read you code: you can’t adapt it to changing requirements, you can’t build new features into it, you can’t optimize it’s performance. In other words, you can’t maintain it.
And the documented truth of software development is that most of the time and money spent on any sucessful software product is going to be spent in maintenance and upgrades — not initial development.

Writing code that is difficult to read is like running up your credit card buying expensive toys; even though you don’t pay today, the bill is going to come due eventually — and the longer you wait the more it’ll cost.