Saturday, February 3, 2007

Underscoring the Need for CamelCase

Space the Final Front Tier

It is a little known fact that most programming languages allow spaces in their identifiers. By identifiers, I mean such things as variable, function or method names, or just about anything that isn't a reserved word. I mention this fact because the previous post included a one line basic game that didn't have a single space, and required the services of a good cryptanalyst to decipher. I didn't want you to get the idea that I thought this was good form; far from it. In fact I believe that with enough effort, it is possible to make the source for a program read like pretty fair English.

Embedded spaces were used in some extreme programming examples that ended up obfuscating the meaning more than it helped:

For a day in the life := this day to a far distant future
. perform some meaningful calculation on the date

The problem is not so much the embedded spaces per se, but the fact that their use seems to encourage unnecessary verbosity. There was also another problem with spaces that appeared about the time that good programming editors came along; it was difficult to select them for copying to another location, and brother, you really didn't want to type these kinds of names more than once. Most editors provide some kind of mechanism for selecting the word under the cursor. Modern GUI programs use a mouse double-click, but it was also available in keyboard only interfaces by using a special control key. The only problem was that the selection ended with the space.

So it became fashionable to use the underscore in place of a space:

For a_day_in_the_life := this_day to a_far_distant_future
. perform_some_meaningful_calculation_on_the_date

So the underscore improved the readability somewhat by making it easier to see where one program element began and the other left off. Underscores are still somewhat popular today, but they also have a problem. It is difficult to type them since it requires a shift key. Also, for a time, there were actually keyboards that didn't include the underscore, which limited its popularity somewhat.

Enter "camel case" (or CamelCase) as the most recent solution to the problem of creating readable multiword identifiers. Our example becomes :

For aDayInTheLife := thisDay to aFarDistantFuture
. performSomeMeaningfulCalculationOnTheDate

Surprisingly, it doesn't seem to have lost any readability once you get used to it. The brain is a pretty adaptable thing when it comes to reading. After all, ancient Latin was often written without spaces between the words, and in all upper case. It works for literature too, although it probably won't catch on.

The lastDayOfMoscow dawned. It was clearBriskAutumnWeather. Just as on ordinarySundays, the bellsOfAllTheChurches rang forMass.

Monday, January 29, 2007

In Praise of Brevity

“Therefore, since brevity is the soul of wit, And tediousness the limbs and outward flourishes, I will be brief” William Shakespeare

Rheolism is a Tetris like puzzle one line game written by Martin Hollis and David Moore with help from Olly Betts.

The code:


was written in BASIC on the BBC's Acorn microcomputer over a period of ten week in 1992 in response to a challenge to write a one line program, which effectively limited the program to 253 bytes. It makes a one line program that I once wrote called "Ambulance Driver" look rather trivial by comparison.

What is my point in listing this admittedly rather horrid looking program in a blog about programs as poetry, you might ask? Programming and poetry are both obsessed with limits. Consider the limerick. Like many poetic forms, it places specific limits on the number of lines which must usually rhyme and have a specific meter, with extra points given for internal rhymes, alliteration, and a surprise ending. Does this make it difficult to get your point across? Of course, it does, but it also makes it infinitely more satisfying to both compose and read.

In programming, if we do not set limits, then how will we know when we are done? How will the program be capable of running within the limits of our operating environment? Will it be fast enough, but not too fast? Will it keep to the limits of our program's specifications, whatever they may be?

A poem without limits is just prose, and a program without limits is crashed. As Albert Einstein said, "The difference between genius and stupidity is; genius has its limits."

Not Your Garden Variety of Software

Programming is Gardening, not Engineering A Conversation with Andy Hunt and Dave Thomas, is an interview with the authors of The Pragmatic Programmer books in which they describe the Software as Garden metaphor.

Andy Hunt: There is a persistent notion in a lot of literature that software development should be like engineering. First, an architect draws up some great plans. Then you get a flood of warm bodies to come in and fill the chairs, bang out all the code, and you're done. A lot of people still feel that way. ... We paint a different picture. Instead of that very neat and orderly procession, which doesn't happen even in the real world with buildings, software is much more like gardening. You do plan. You plan you're going to make a plot this big. You're going to prepare the soil. You bring in a landscape person who says to put the big plants in the back and short ones in the front. You've got a great plan, a whole design.

Dave Thomas: Also with a garden, there's a constant assumption of maintenance. Everybody says, I want a low maintenance garden, but the reality is a garden is something that you're always interacting with to improve or even just keep the same. ... We want people to view software as being far more organic, far more malleable, and something that you have to be prepared to interact with to improve all the time.

Somehow I'm not totally comfortable with the garden metaphor, but like most metaphors it works as long as you don't look at it too hard. Software development isn't really a garden, but then again, to most people, programs aren't really poems.

Recommend Study in Open Source Software

In a previous posts, I mentioned the need for a list of open-source software that would be listed as recommended study for programmers. It would seem that the first step is to list some of the possible candidates. Wikipedia has a list of open source software packages that makes a good starting point.

The next step is to list some basic requirements for inclusion in the list. The target audience should mainly be the undergraduate student of Computer science, although good examples of well crafted source code will be of interest to a much larger group. This puts some bounds on the size and type of software project since not all can reasonably be studied in a typical programming class. Let's assume a university course with the proposed title of "Survey of Real World Software." Prerequisites for the course would include familiarity with several common programming languages such as C, C++, and Java. New and relatively esoteric languages such as Python, PHP, and others are not usually a part of a standard CS curriculum.

I believe that modern graphical user interface (GUI) code requires a separate course of study due to the specialized nature of event handling. The same is true for most kinds of network or website applications. What is needed is a relatively small, yet useful software application that concentrates on delivering specific functionality. This would seem to apply to small compliers, server applications, and other batch processing tools. The GNU/Linux command line tool suite should be a fertile ground for this programmer's garden.

One example that comes to mind that I have personally learned a great deal from is the PL/0 compiler created by Niklaus Wirth in 1975. At 790 lines of Pascal, it is a marvel of elegant efficiency. If you prefer, there are some C translations here in 490 slightly more packed lines. This is an excellent introduction to parsing, among other things.