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.

...

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:

    0d=d:IFdVDUd:a=POINT(32*POS,31-VPOS<<5):returnelsemode9:gcol-9:clg:o
FF:d=9:REPEATVDU30:REPEATGOSUBFALSE:IFPOS=28VDUPOS,15,VPOS,24;11,26:IF0E
LSEIFa=0PRINT:UNTIL0ELSEUNTILVPOS=25:v=ABSRNDMOD7:i=0:VDU4895;3:REPEATm=
9-INKEY6MOD3:FORr=TRUETO1:t=rANDSGNt:IFt=rCOLOURv-15:VDUrEORm:i+=m=7AND9
-6*r:IF0ELSEFORn=0TO11:d=n/3OR2EORd:GOSUBFALSE:IF1<<(n+i)MOD12AND975AND&
C2590EC/8^vVDU2080*ABSr;:t+=a:IF0ELSENEXT,:VDU20:UNTILt*LOGm:UNTILVPOS=3

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.

Pascal is for Poets

That motto, "Pascal is for Poets" once adorned a T-shirt belonging to a colleague of mine at Georgia Tech by the name of Gus Baird. I had recently started work at the Research Institute there, and in addition to doing design and coding work on an Army intelligence system designed the ANUYK-71 (known affectionately to us as Micro-Fix), I had the good fortune to be assigned to assist Prof. Baird in teaching a class in Pascal to the 82nd Airborne at Ft. Bragg, North Carolina in the early 80's.

"What will I be doing?", I asked Ed Shanahan, my supervisor at GTRI.

"Just help set up the computers and keep them running," he answered. "You'll probably need to help the students with their lab work."

"Sounds easy enough," I said. "I've had plenty of practice doing that during my VA work-study program days. Do you really think Gus can teach a bunch of Army folks how to program in Pascal in just a week?"

"I hope so," Ed said, "That's what they are paying us to do. All of the people they are sending are supposed to have prior computer experience, so it should be possible."

Ed, Gus, a couple of Tech student assistants, and I met in a hotel outside Ft. Bragg on the Sunday prior to the first day of the new class. Ed and Gus had just gotten back from a meeting on the base, and they were obviously not happy. Apparently, the Army had not, in fact, sent all people with prior computer experience, but about half the class had never even touched a computer before. Mind you, this was 1982, and that was still the norm for most of society.

"There has been a change of plans," Ed said looking at me. "We'll have to divide the class in half, and you'll be teaching the people with no prior experience. Gus will continue as planned so that the experienced people get what the government paid for."

"Meanwhile, ten hours from now, I'll be lecturing to a bunch of malcontents who probably didn't even ask to be sent to this class, for eight hours a day for five days without a lesson plan," I pointed out.

"That's about the size of it," Ed laughed. "We figure you'll be lucky to be able to teach them how to turn it on in a week."

After a restless night, I found myself in front of a varied group of uniformed individuals. They were initially well behaved until the Captain who was in charge of the educational center left. Then, as I began the first tentative attempts at introducing them to fundamental computer principles, the heckling began. Some of the students had been sent to the class under a time-honored Army tradition of sending those who would be least missed. Some of them knew this, and resented it and the fact that they had been immediately put in the "dummies" group.

Somehow I got though that first day. The second day was better; with most of the basic concepts of computing like binary arithmetic, boolean logic, and the Von Neumann architecture having already been covered, the students seemed glad to begin learning the UCSD Pascal language that was available on the Apple II. Surprisingly, it didn't take long to cover the entire language. Pascal is, after all, designed to be a small and easy to teach language, the number of reserved words being less than 40 in most implementations.

I found that the trick to holding the students interest was to keep it real. I had to be able to point to something useful that the Apple II could be made to do by each person in the class by Friday. The answer was something that was not readily available in the early days, a database. Most people can think of some part of their daily work that could be made easier if only they had a custom database to automate it, and my "sweat-hogs" were no exception.

In the next classroom, Prof. Gus Baird was giving the experienced people the full university level course in Pascal, albeit somewhat abridged. From our combined lab sessions, I gathered some of them were having a tough go of it. I believe the expression we used was "a sip from the fire hose." I never had the opportunity to sit in on one of Gus's classes, but I gather he was very knowledgeable, focused, and quite entertaining. His background of writing weapons guidance software had given him a lot of interesting stories, an appreciation for attention to detail, and a low tolerance for error prone programming habits. To him, Pascal code done right was poetry.

Meanwhile, my students were learning the basics of Input/Output using text and then binary methods. The Bell-and-Howell "Black" Apple II computers that the Army had acquired, by the clever trick of using education funds to circumvent the usual Army bureaucracy, had floppy disk drives, which made them as powerful as most small computers of the time. We quickly moved on to searching and sorting techniques, and finally user interface design. Before I knew it, Friday had come and it was time for them to take the final exam that was required to get a training certificate. Nearly three quarters of the class managed to pass the final exam.

Like others who have had the opportunity to teach, I sometimes wonder what my students did when they left the class. Did any of them go back to their posts, clutching their own floppy disk full of database source code, and create wonderful automations, and then go on to become professional programmers? Did it seem as miraculous to them as it did to me that it was possible to learn so much in such a short time? When I think back on it now, it seem hard for me to believe what can be accomplished when you don't know what can't be done.

If any of those students did go on to study programming at a university, they surely found it to be a far different experience. You can't take an advanced programming course until you have had an introductory programming course, and you can't take the intro until you have met the prerequisites. It may take a full year before they are allowed to get back to the level of that Friday. At some universities I know, they may never get beyond that basic level.

Strange as this tale sounds in these times, it wasn't unusual then. Many others tell the same story of how quickly even middle school students respond to teaching programming rather than "using computers" as we do today, and of how empowering it is to both teach and learn to take control of the computer with our own hands. We have lost the simple innocence of those early microcomputer years, mired in the complexity of modern layered software where, far from controlling the machine, you are controlled by it.

What The World Needs is More Neal Stephensons

"When you are wrestling for possession of a sword, the man with the handle always wins." Neal Stephenson in Snow Crash.

In addition to the many incredible books that Neal Stephenson has written, including Snow Crash, Cryptonomicon, The Diamond Age, and the three novels in the Baroque Cycle, he has also written an essay called "In the beginning was the command line" that is available on the web. It is worth the read. There are also several web interviews: A Conversation With Neal Stephenson, Slashdot's Neal Stephenson Responds With Wit and Humor, and the Salon.com Interview.