June 30th, 2006 by Mark Ramm
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.
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.
June 25th, 2006 by Mark Ramm
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.
June 21st, 2006 by Mark Ramm
Prentice Hall’s Open Source Software Development Series already has some classics. Arnold Robin’s Linux Programming By Example is a fantastic book for learning the Linux and unix API’s. It dives into real world code, showing how Open Source projects handle the real issues and challenges that impact their projects. When you read Arnold’s book, You aren’t just looking at toy examples, most of the code comes from real world projects and is not only “production ready” it’s already been in production!
So it’s a real thrill to be in this series, and to be working with a publisher and editor who understand the value of next generation dynamic languages and web frameworks like TurboGears.
The light-saber (or if you prefer a law-suit free name the laser-sword) is designed to represent both the patience and practice required to achieve mastery, and the power and skill that comes when you have achieved it.
TurboGears, like Linux provides free infrastructure that makes it possible to create new products, more quickly, with more reliability, and more powerful features
Sure, it takes time and effort to wrap your head around SQLObject, CherryPy, Kid, and Mochikit but you can understand the basics and start writing usable code in a couple of hours, and once you’ve mastered the components of TurboGears you’ll be able to create dynamic, database-powered, ajax-enabled, web applications more quickly.
The great thing about TurboGears is the gentile slope of the “learning curve.” Sure, the journey from absolute beginner to Jedi Master can take a while, but right from the beginning you’ll be able to get things done.
June 12th, 2006 by Mark Ramm
Clark Ching created a great little whitepaper describing a 1 hour presentation on how to do Test Driven Development, that even IT managers can understand. One of the keys to something like this is having the chutzpah to actually stand up in front of a group and do some test driven development live. Anyway, this presentation is something I should be able to show to my CEO and have him understand. Everything is done in Excel with very simple VBA macros. But, It should also be trivial to translate this from Excel/VBA to Open Office/OO Basic or Python.
I actually think this could be a great presentation for something like the Ann Arbor IT Zone, which caters more to the business end of IT and Software Development. But I don’t want managers going out and pushing Test Driven Development on their unwitting employees. It is something you have to value before you can practice it well.
June 11th, 2006 by Mark Ramm
No, were not there yet. But the thought has more than crossed my mind for something in November or possibly January. Unfortunately, that’s a long way off, and still mostly just a dream.
For those of you who want something a little bit sooner than that — I just heard a few min. ago that Bruce Eckel (Author of the amazing book Thinking in Java) is at least thinking about transforming his upcoming Thinking in Java conference into something that involves Python and TurboGears. The conference is scheduled for July 18-21, and it looks very interesting.
Nothing is definite yet, but Bruce is a fantastic writer and educator, and a longtime Python advocate, so if there’s any way that I can arrange for the time away from work, and come up with the money to go, I’ll be there.
Let me (and more importantly Bruce!) know if you’d be interested in doing something TurboGears related at conference.
P.S. Somebody asked recently, so I thought I’d mention that you can always contact me at Mark @ this website address.