Lars at the OSL

Several years ago, I went to a small conference of antique rose enthusiasts. There were five speakers scheduled including the greenhouse manager of my nursery. He declined my offer of scanning his photographic slides and the use of a laptop computer for the presentation. He’s a professional photographer and sited the inability of LCD projectors to accurately reproduce color as he reason for refusal.

Each of the conference speakers was to bring a CD of their Power Point presentation to be used on the conference supplied computer or their own laptop to be plugged into the projector. Every single Power Point presentation failed. Some presentations started fine and then the image would vanish. They fiddled with the cables, the projector settings and computer settings to no avail. The only successful presentation came from my greenhouse manager with his old fashioned physical slides.

Somehow, I expected with a conference center filled with geeks that OSCON would be entirely different. Yet I’d estimate that twenty-five percent had difficulty getting their presentations going. I witnessed no total failures on major talks, the delays were noteworthy. How many times in the main conference hall did one or two of the projection screens blank out suddenly or show an image seriously shifted to the right or left? I won’t even go into The Lucky Stiff’s presentation debacle during the Ruby love fest.

I would think that the connection between laptop computers and projectors would be a fairly mature, stable technology. Yet, after seeing so many presenters at OSCON struggle to get their presentation slides on the big screen, it’s clear that industry has more work to do. Why is it so difficult for projectors when it seems so easy for desktop monitors?

Python uses syntactically significant whitespace to define blocks of code. When casually talking with some Ruby and Java developers at OSCON about Python, I inevitably had to wait for them to stop ranting about mandatory whitespace. When I queried as why they we’re so opposed, I never once really understood their objections. I really love Python’s whitespace rules.

One noteworthy complaint I heard was that code written in one editor by programmer A can get its indentation munged by another editor used by programmer B. Yeah, I can see how that can happen, but only if tabs are expanded or replaced by the second editor. That would break a Python program. In another language, you’d have to make the same corrections anyway or the code could be rendered unreadable or deceptively indented even though it still compiles. In Python, properly indented readable code is a requirement. Maintenance programmers in the future will call this a good thing. The problem can be avoided entirely by not using tabs.

The first code time I encountered indenting code was in Pascal in 1978. It made the code so much more readable. The “begin” was by itself on a line, subsequent lines were indented until, on a line by itself, the “end” statement terminated the block. Later, programming in Fortran 77, indentation was used in a similar manner, though without the “begin” and an “endif”, a “wend” (DEC variant) or a labeled “continue” to terminate the block. C was just like Pascal, only with braces to define the block.

Programmers in C started a unsavory habit of placing the opening brace at the end of the line preceding the block while the close brace lived on a line of its own. This meant that the opening and closing braces rarely, if ever, lined up horizontally. To this day, my eye/brain combination has a terrible time matching braces. To my dismay, that style has become the standard, not only in C, but in all its children: C++, Objective-C, Java and C#. Yet, it is the convention to also use indentation. Why? Because the braces alone are not good enough at making blocks readable. Try eliminating the indentation and the code becomes nearly impossible to read. Braces are good enough for the compiler but not enough for humans (at least this one). It’s like the parenthesis in Lisp: once you get four or more opening or closing parenthesis in a row, I can no longer mentally match them up at a glance. Perhaps my brain is defective.

Have you ever heard the doctrine of “once and only once”? Originating in our own software world, it suggests that it is a bad idea to duplicate effort. Throughout the realm of programming, trying to maintain two parallel solutions to the same problem leads to problems. Remember the relief that Java gave us over maintaining separate header and implementation files in C and C++? Remember how difficult it is to keep documentation synchronized with the source code?

Why do the C derived languages use two separate techniques to indicate a block of code? We use braces for the compiler and whitespace indentation for the programmers. Python demonstrates that the compiler can use the same queues that we use to see blocks of code.

Honestly, the technique used to delineate a block of code in a language is a minor issue. I really like Python’s technique because it synchronizes with how my brain seems to work. I’ve lived with braces in my code for years and years. It hardly seems a reason for such vehemence as I heard at OSCON from some other developers.

Ruby: the new black, the cream in the coffee, the acid in the Koolaid

If it’s true that the right mix of illicit pharmaceuticals can alter one’s perspectives leading to new insights and ways of thinking, one might suspect a lot of folks at OSCON 2005 were dosed with Ruby. That first understanding of Ruby’s functional programming aspect is just such a mind-opening experience, bringing to mind the now twenty years gone epiphany I had when I suddenly understood recursive pattern matching algorithms in Lisp. I hope folks who have been tripping on Lisp for decades nod and welcome this new generation of Ruby programmers into their expansive way of thinking.

Lisp suffers an unfortunate history. In spite of its considerable power, it never became a dominant programming language. Good technology at the wrong time, perhaps? I first encountered Lisp in graduate school in an artificial intelligence course. I recall the thrill of its power, and the frustration at its difficulty of code maintenance. It’s not a failure of the language, it’s a failure of the tools that enable expression of the language. It think that is a major reason why Lisp never became dominant.

Another progenitor of Ruby’s more advanced features is Smalltalk. It is another very powerful elegant language that failed to capture dominance. It differs from Lisp in that it had, when introduced, a revolutionary built in integrated development environment. There was nothing else out these like it, yet it failed to sweep the planet. Was it too far out of the main stream? I believe that Smalltalk’s tight binding to its operating environment contributed significantly to sabotaging its deserved success. This, again, exemplifies the failure of the tool rather than a failure of the language.

I heard several times during Ruby track sessions at OSCON, “Syntax is important.” In each case, the presenter was showing off some elegant, yet simple way of expressing a construct that would be awkwardly verbose at best in Java or C++. Lisp and Smalltalk both have elegant, yet simple constructs, too. The syntax alone was not enough to propel these languages into ubiquity.

It takes more than clever syntax to insure the success of a language. It takes dedicated enthusiasts, a demonstration of successful projects, as well as compelling tools to draw developers. Ruby has the first in spades. Perhaps Ruby on Rails will prove to be the second. The third, through my limited view from OSCON, is not evident.

I admit, I drank the Koolaid, too. I am excited about the possibilities of Ruby to succeed where its virtual ancestors Lisp and Smalltalk did not. I sincerely hope that the community surrounding this worthy project expands enough to negotiate the path to ubiquity. Meanwhile, I’m going to sit back and enjoy the trip. Yield to the block, man.