Pragmatism in Programing

A book called "The Pragmatic Programmer: From Journeyman to Master" by Andrew Hunt and David Thomas promises to "cut through the increasing specialization and technicalities of modern software development to examine the core process--taking a requirement and producing working, maintainable code that delights its users."

Pragmatism is a school of epistemology. Most of the thinkers who describe themselves as pragmatists consider practical consequences or real effects to be vital components of both meaning and truth. In ordinary usage, pragmatism refers to behavior which temporarily sets aside one ideal to pursue a lesser, more achievable ideal. It is difficult to determine what ideal the authors are setting aside in order to achieve their programming goals, however their list of tips (sample shown below) looks interesting. The Stroop effect is also kind of neat. See also Jon Aquino's blog post for his explanation of the benefits of reading code aloud.

Extracted From The Pragmatic Programmer
by Andrew Hunt and David Thomas.
Copyright 2000, Addison Wesley.

1. Care About Your Craft. Why spend your life developing software unless you care about doing it well?
2. Always Use Source Code Control. Source code control is a time machine for your work---you can go back.
3. Use Blackboards to Coordinate Workflow. Use blackboards to coordinate disparate facts and agents, while maintaining independence and isolation among participants.
4. Estimate the Order of Your Algorithms. Get a feel for how long things are likely to take before you write code.
5. Some Things Are Better Done than Described. Don't fall into the specification spiral---at some point you need to start coding.
6. Costly Tools Don't Produce Better Designs. Beware of vendor hype, industry dogma, and the aura of the price tag. Judge tools on their merits.
7. Invest Regularly in Your Knowledge Portfolio. Make learning a habit.
8. Separate Views from Models. Gain flexibility at low cost by designing your application in terms of models and views.
9. Work with a User to Think Like a User. It's the best way to gain insight into how the system will really be used.
10. Don't Be a Slave to Formal Methods. Don't blindly adopt any technique without putting it into the context of your development practices and capabilities.
11. Sign Your Work. Craftsmen of an earlier age were proud to sign their work. You should be, too.

Perpetual Motion and Lossless Infiinite Compression

Once a master was walking with a student.
The student exclaimed, "I have an idea for a new data compression scheme. I'll use a lossless compressor and pipe the output back into the input, looping until the desired size is achieved."
The master considered mentioning Shannon and his Limit,
but instead bought a balloon from a street vendor and releasing the knot, he deflating the balloon and handed it to the student saying,
"Remove the air from this balloon."
At that moment the student was enlightened.

Stepwise Refinement

Khan's Koan

In the days when Khan was studying at ETH,
he was hacking at a terminal when Wirth happened by.
"What are you doing?" Wirth asked him.
"I'm teaching the computer to think," Khan replied.
Wirth reached behind the terminal and unplugged it.
He placed a large blank sheet of paper in front of Kahn,
saying, "First teach the paper to think."
At that moment Khan was enlightened.

Here are a couple of excerpts and links from articles by the master.

Program Development by Stepwise Refinement by Nicklaus Wirth

Programming is usually taught by examples. Experience shows that the success of a programming course critically depends on the choice of these examples. Unfortunately, they are too often selected with the prime intent to demonstrate what a computer can do. Instead, a main criterion for selection should be their suitability to exhibit certain widely applicable techniques. Furthermore, examples of programs are commonly presented as finished "products" followed by explanations of their purpose and their linguistic details. But active programming consists of the design of new programs, rather than contemplation of old programs. As a consequence of these teaching methods, the student obtains the impression that programming consists mainly of mastering a language (with all the peculiarities and intricacies so abundant in modern PL's) and relying on one's intuition to somehow transform ideas into finished programs. Clearly, programming courses should teach methods of design and construction, and the selected examples should be such that a gradual development can be nicely demonstrated.

Computing Science Education: The Road not Taken by Nicklaus Wirth

As computing professionals, it is our duty to speak up against a culture that equates computer literacy with mastering the intricacies of a production programming language.

This reminds me of E. W. Dijkstra’s tale of his worst night after reading the specifications of the new programming language PL/1 in 1965. He said he had the painful vision that in the future programming will be equated with learning PL/1, and computer science with mastering OS/360 JCL. Replace PL/1 by C++ or Java, and JCL by Windows or Linux, and you are miraculously transposed into the present time.

Zen and Tic Tac Toe (Part 1)

AI Koan: Sussman attains enlightment

In the days when Sussman was a novice, Minsky once came to him as he sat hacking at the PDP-6.
What are you doing?", asked Minsky.
"I am training a randomly wired neural net to play Tic-Tac-Toe.", Sussman replied.
"Why is the net wired randomly?", asked Minsky.
"I do not want it to have any preconceptions of how to play", Sussman said.
Minsky shut his eyes.
"Why do you close your eyes?", Sussman asked his teacher.
"So that the room will be empty."
At that moment, Sussman was enlightened.

Tic-Tac-Toe is my current favorite in the search for the perfect task to demonstrate good programming practices. I believe it can be used to demonstrate the vast range of solutions that are available for many similar problems, and it should also be a good example of the range of quality in solutions.

Tic-Tac-Toe has a special personal significance to me as it figured in the first piece of hardware that I ever designed in 1969, and it was the first program that I ever wrote using my first personal computer in 1978.

In 1969, I was a sophomore in high school trying to come up with a decent entry for a science fair. I had recently learned to make electric relays using wire, nails, and tin cans, and I decided that it might be possible to wire up nine of these relays to switches and lights in such a way as to play a fair game of Tic-Tac-Toe. I worked for months on the wiring diagram until I came up with what I thought was a solution. Unfortunately, the relays kept sticking and I could never get the thing to work. I never learned whether my solution would have worked if I had access to better hardware.

Later, in 1978, I had bought a Radio Shack TRS-80 microcomputer that had an excellent chess program that I liked. Unfortunately, or perhaps fortunately, the game cassette tape deteriorated after a few months and I was left with no use for the computer. I decided that I would have to learn to program chess myself, so I got out the manual and, quickly getting over my delusions of grandeur, I settled for programming Tic-Tac-Toe. Hundreds of lines of code and about ten hours later, I had a working version of the game that met all of my requirements. I was hooked on programming, but obviously had a lot to learn, since the program was incredibly more complex than my teenage relay machine.

All of these years later, I have decided to revisit the problem of the Tic-Tac-Toe machine with 9 relays and determine if it is indeed possible to construct such an elegant solution to the problem. I will also endeavor to discover if the solution will carry over to software implementation as well, or if it is only possible in dedicated hardware.

...

More Inspirational reading

For fun and enlightenment, I recommend:
THE HACKER CRACKDOWN, Law and Disorder on the Electronic Frontier by Bruce Sterling

To increase your programming prowess on the subject of optimization I recommend Michael Abrash's Graphics Programming Black Book.

Blackboards and Memory Systems

When I was a freshman in college, I took an introduction to psychology course that required either a field trip to a mental institution or an independent project of my own choice. I chose the later because I had developed an interest in how human memory works, and also perhaps due to a certain amount of squeamishness about the insane.

My project was inspired by a television program where a "memory magician", whose name I (ironically) can't recall, would begin by being introduced to each person in the audience. Later, after performing some other tricks, he would recite each person's name correctly as they stood up. He said that this feat was not accomplished by magic tricks, but was due to a system that anyone could learn, and went on to explain that the key to remembering was to associate something in the sound or meaning of the words with a visual image of the person. This was not like a trivial example of say, Mr. Green wearing a green shirt, but something outlandish and unforgettable. I didn't learn exactly what this meant because, as it turned out, in order to learn this secret method, I had to send in $29.95 for a pamphlet and audio tape.

So armed with only this one rather questionable bit of knowledge, I begin my project on memory systems. Rather than doing research and regurgitating the work of others, I decided that I would perform a field test and report my results. Since I couldn't really persuade dozens of strangers to meet my test subjects, I felt that the next best thing would be to have the subjects memorize a list of 200 words arranged in two columns. The test would be to produce the second word when given the first after hearing the list only once.

Now associating 100 pairs of nouns that were randomly chosen from the dictionary sounded quite a bit more difficult than memorizing names, and I fully expected the tests to report rather poor results, which I hoped wouldn't affect my grade on the project, since in science, results are results. Imagine my surprise when my first two test subject were able to recall all 100 responses correctly when given the key word! I tried the system myself and found it was absurdly easy to memorize any number of noun - noun associations. The only magic required was to connect the two with a visual image of an outlandish and unforgettable action. I still remember the first pair of words on my list: squirrel - doorknob. What I did was to imagine a squirrel opening a door in the sky and peering out. This image was so vivid that it has stuck in my mind for mumble mumble years.

Needless to say, I was pretty excited to report my astonishing discovery, but it turns out that the market for associating random lists of nouns was a lot smaller than you would think. What people really want is help remembering names and dates and numbers, which is quite a bit different (try coming up with something outlandish to help remembering say, October 20, 1987). The only thing that really helps with that is the personal computer, which came along mumble years later. That brings me (finally) to the subject of this article, which is using Blackboard Systems to improve your programs.

Real blackboards first appeared in a Philadelphia school in 1809 and were made of pine wood colored with a mixture of egg white and charred potatoes( mmm, can't you smell those potatoes charring in the Franklin stove?) They served pretty much the same purpose as whiteboards do today, as a place to display information that everyone in a room can read.

Software blackboards occupy much the same niche as their real world equivalents. They store data using associative lists in a readily accessible location for the purpose of communicating information between a program's various objects or subprograms. A program may contain more than one blackboard, for instance, if the application allows multiple documents to opened at one time, it might have both an application blackboard and a document blackboard. The application blackboard would be used to store or remember information that pertained to the behavior of the whole application, and the document blackboard's scope would be limited to one document or window.

Some examples of data that might belong in a text editor's blackboard include, the last font chosen, color, font size, number of spaces in a tab, and justification mode. It might be a good idea to store this data in the persistent blackboard for the application so that each new document will inherit the same defaults for these settings.

How useful blackboard data structures can be is not readily apparent until you start using them. It is one of those concepts you keep finding more and more uses for over time. It seems that object oriented technology has brought increased capability for abstraction though information hiding, but there always seems to be a need to access data outside the object metaphor though methods like relational databases or blackboards.

When blackboards or similar structures (like the Windows registry) are used for communication between cooperating programs, it becomes close to the biological concept of stigmergy which is the name given to the communication between social insects facilitated by the structures they build.

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.

...