Dreaming in Code, Chapter 3: “Prototypes and Python”

Bookmark and Share

February 13th, 2007

Another day, another chapter: I’ve now read through Chapter 3 of Scott Rosenberg’s Dreaming in Code, and will offer a few comments and observations. If you have no idea what I’m talking about, you might want to skip back to some earlier blog entries that discuss the preface and initial chapters of the book; links are provided below, at the end of this posting.

Basically, Chapter 3 discusses the evolution of Chandler’s vision, purpose, and software architecture. It’s written in a sufficiently non-geeky fashion that any reasonably intelligent person above the age of 13 should be able to understand it. Whether they’ll want to read it is an entirely different question; I found the discussion interesting, but that’s because I’ve spent my entire adult life doing this stuff. As my family diplomatically reminds me from time to time, there are several billion people on the planet who really don’t care about the nuances of object-oriented programming, or the reasons why one programming language is better than another. But as I’ve suggested in earlier blog postings, the pervasive influence of computers in today’s society — in our iPods, our cellphones, our digital televisions, in literally every product and service we use in day-to-day life — means that the non-geeks should be interested, if only for a brief time, in how all of this software stuff gets put together.

This is not a new theme; it’s a modern variant of the “two cultures” theme espoused by the late British scientist C.P. Snow back in 1959. At Snow said at the time,

“A good many times I have been present at gatherings of people who, by the standards of the traditional culture, are thought highly educated and who have with considerable gusto been expressing their incredulity of scientists. Once or twice I have been provoked and have asked the company how many of them could describe the Second Law of Thermodynamics. The response was cold: it was also negative. Yet I was asking something which is the scientific equivalent of: Have you read a work of Shakespeare’s?

“I now believe that if I had asked an even simpler question — such as, What do you mean by mass, or acceleration, which is the scientific equivalent of saying, Can you read? — not more than one in ten of the highly educated would have felt that I was speaking the same language. So the great edifice of modern physics goes up, and the majority of the cleverest people in the western world have about as much insight into it as their neolithic ancestors would have had.”

Well, the issue here is not the Second Law of Thermodynamics, but rather how a bunch of savvy, experienced software developers could organize their thoughts, and their technical strategy, into a plan for building a better PIM — maybe not a Microsoft Outlook-killer, but maybe that would elicit the same gasp of delight that most of us felt when we first began using Web browsers 10-12 years ago, or when we first began interacting with Google 5-6 years ago, or (more recently) when we first had the pleasure of using Google Maps. Whether you’re an experienced programmer or a technophobic Luddite, you simply cannot use Google Maps without muttering to yourself, “Wow! How do they do that?”, followed by gasps of delight as you move the map around, zoom in, and zoom out. (And if you think that’s fun, check out the Earth Sandwich project, as explained in this hilarious zefrank video, and assisted with the Find The Opposite tool)

As Rosenberg describes it, OSAF founder Mitch Kapor “had a clear picture of the program he wanted to build. Like Agenda, it would be a PIM, or personal information manager, a tool for managing email, appointments, addresses, tasks, and notes. … And it would be explicitly designed so that any developer could add new capabilities to it. Open source programmers could code new modules or ‘parcels’ for, say, managing digital photos or music collections. And nontechnical users would be able to add new categories and labels to the program on the fly.”

While the “vision thing” is obviously a crucial part of any software development effort, so is the architecture and choice of implementation technology. To explain how the Chandler project made its decisions in this area, Rosenberg takes us on a historical tour of programming languages, ranging from binary code to assembler, to FORTRAN, and ultimately to the two languages that the Chandler team seriously considered: not Java and C++, but rather Python and Perl. It’s a fairly lengthy discussion, but I enjoyed it … and you will too. I command you to enjoy it; resistance is futile!

Finally, Rosenberg gives us a brief history of the unveiling of the Chandler project — to the world at large, especially as it hadn’t even been built, but to the Silicon Valley geek community. I must admit that I wasn’t aware of it at the time, but that’s probably because I don’t live in Silicon Valley; but apparently it began with an October 20, 2002 article in the San Jose Mercury News by respected technology journalist Dan Gillmor (whose website is here, and whose current reporting efforts are largely focused on the Center for Citizen Media blog).

Rosenberg tells us that “Gillmor’s October 20 column reported: ‘An early version of the calendar part of the software should be posted on the Web by the end of this year, and version 1.0 of the whole thing is slated for the end of 2003 or early 2004.’”

And, as Rosenberg tells us in the final sentence of the chapter, “The guesses proved more than a tad optimistic.”

Stay tuned…

Reviews of earlier chapters of “Dreaming in Code”
Preface
Chapter 0: Software Time
Chapter 1: Doomed
Chapter 2: The Soul of Agenda
Endnotes

Leave a Reply