JavaWocky

I looked the deadline in the eye and blinked.
I ordered the GUI Builder - only then did I think.
Productivity it will enhance, but only if you do the dance.
So stay in step, keep to the road
and never ever hack the code.


The following is from an article at: Hacknot titled "Beware the GUI Builder":

Twas WYSIWYG, unsightly code
Did file and frumble by the way;
All grinsy were the morrow-knows,
And the dumb sooths outlaid.

Beware the GUI Builder, son!
The drag that drops, the cut that pastes!
Beware the graphic god, and shun
The nerdious interface!

He took his QWERTY keys in hand,
Long time the dialog he fought-
So rested he by the Widget tree,
And sat awhile in thought.

And, as in WIMPish thought he sat,
The GUI Builder, icons lame,
Came blitting through the worldly web,
And googled as it came!

Grid bag! Grid bag! And layout do
The QWERTY keys went clicker-clack!
With one last call, he uninstalled
And went compiling back.

And hast thou slain the GUI Builder?
Come to my arms, my beanish boy!
O wizard real! Just look and feel!
He buffered in his joy.

'Twas WYSIWYG, unsightly code
Did file and frumble by the way;
All grinsy were the morrow-knows,
And the dumb sooths outlaid.

With apologies to Lewis Carroll

Deep or Wide

Put on your hip boots, it's about to get deep here.

The other day I was thinking about how hard it is to be a Java programmer when I realized something. Old style languages like Pascal were very small so that in order to do anything useful, you had to know a lot of good algorithms. On the other hand, a modern language like Java is very large and already has support for most common programming tasks. This calls to mind the depth vs. breadth tree search problem. Under this metaphor, being a good Pascal programmer involves a lot of depth, but not a lot of breadth of knowledge. Whereas being a good Java programmer involves having a large breadth of knowledge about the libraries, but very little depth about how they work.

These are fundamentally different kinds of knowledge, and different programmers will attain proficiency at each language differently. Java, or indeed any modern language, requires memorization of vast numbers of APIs. Otherwise you risk reinventing the wheel, and the bugs that go with it. Which methodology is superior? I suppose I must reluctantly admit that breadth overcomes depth more often.

The depth vs. breadth tree search is often explained in the context of game theory, especially using chess as an example. As a chess player I have always relied on depth as a strategy, but a good player with a broad knowledge of standard chess openings will beat a depth first thinker every time. This is unfortunate, since it means that to be a serious chess player implies years of study and memorization just to know the state of the art. No one enjoys this, but it is necessary to be taken seriously.

What is true for chess players is also true for modern programmers. Is there any escape from the problem of rote memorization? All professional fields have this problem, but programmers are different. We don't have to live within the limitation of human brains. Isn't there a software solution that will free us from the chains of memorization? I know it isn't Google. That instrument is way too blunt. It isn't Javadoc. That is too tightly focused. It is something like Googling Javadoc though, with more intelligence. I want something that reads my code, determines basic purpose, and suggests possible solution classes that are appropriate to the job at hand. A kind of automated design pattern filter. Not AI, mind you, just good old fashioned breadth first tree searching.

...

Fast Times at a High Tech Company (Part 1)

A personal look at Hayes, the canonical microcomputer modem manufacturer in the turbulent 80's.

In his fascinating INCOMPLETE HISTORY OF PERSONAL COMPUTING Ver. 6.3, Rory Donaldson says, "As the ‘80’s progress a number of familiar names come and go: Wang, Lanier, TRS-80/TRS-DOS, CP/M, SOL, Osborne, Kay-Pro, Cromemco, Stellation II, Digital Research, MicroPro, Ashton-Tate, Vic, Commodore, Atari, Northstar, Morrow … These companies were largely victims of the futile attempt to freeze the past to guarantee their future."

Hayes Microcomputer was the first, and for over a decade, the dominant force in modem manufacturing. They too fell victim to the relentless press of change that weighed so heavily during the '80's.

As this article in the Atlanta Journal-Constitution shows, the founders of Hayes Microcomputer, Dennis Hayes and Dale Heatherington were eerily similar in temperament to Apple's Steve Jobs and Steve Wozniak. Dennis was the business tycoon and Dale the shy inventor. This photo album chronicles the early days and the final fall, but I was there in the middle period when times were golden, money flowed freely, and it seemed like the sky was the limit.

My story begins in Florida in 1986 where I was taking a sabbatical from work to get a masters in business administration that I hoped would further my hopes of starting a software company. I had made it past the half way point in the degree program when I got a call from Charles P. an old friend with an offer that I couldn't refuse. "You should come and be a consultant for Hayes Microcomputers," he said, "We need someone who can write efficient Z-80 assembler for our new modem. You can name your salary."

Unfortunately, I hadn't gotten to the course in business administration that covered salary negotiation, so I admitted, "I have no idea what consultants make."

"Why don't you ask David what he's getting?" Charles said, "He's just started work here as a consultant too."

David G. had been an undergraduate student assistant at GTRI when Charles and I had worked there. He had won a National Youth Science Foundation or some-such award in high school, and was the fastest programmer I ever met. If you used too much southern drawl, David would finish writing the code before you were finished with the specifications. He ended up only working at Hayes for a few months before going on to Auburn University for a PHD in math. He let me know that he was getting xx dollars an hour, so I figured I should be able to ask for xx+10. Hayes agreed immediately, so I must have asked for too little. I later found out many consultants were making xxx dollars an hour. Ouch! Oh, well it was still more money that I had ever seen at that point in my life.

A week later I pulled into the parking lot of a modern glass and steel office building nestled on the shore of a man-made lake in the back of Norcross Georgia's Technology Park. From the size of the parking lot, there seemed to be about a hundred and fifty people working at the Hayes Research Facility. I couldn't help admiring the peace and tranquility that the swans congregating near the lakeside gazebo foretold, especially compared with my previous Atlanta digs at the Electronics Research Laboratory in the Georgia Tech campus downtown. You couldn't ask for an easier commute. This was the life!

After the usual formalities, I found my way up to the third floor cubicles and met the rest of the team. "Welcome to the Very team," said Charles.

"The what team?" I asked.

"Its Marty's idea of humor. You know that Hayes modems are called SmartModems, right?" Charles continued, not waiting for an answer. "Well we are creating the Very SmartModem."

"Let me explain," Marty said. "We are actually working on two products in one. Those folks over there," he pointed to the southwest end of the third floor, "are working on the new 9600 baud technology that we call ping-pong. You'll understand the name when you hear it. Our firmware will make the 9600 the first Very SmartModem out-of-the-box. However, we are also working on a device to make one of these," Marty paused to indicate a current generation Hayes 2400 buad Smartmodem, "into a Very Smartmodem too by adding this Very box."

"But how does a Very vary?" I punned, picking up the box. "Very Very, please tell Larry how does your IQ grow?"

"With wizard's spells and unix shells, and pretty bits all in a row." came a voice from the next cubicle.

That was my introduction to Robert W. , one of the funniest guys I've ever met and a serious Monty Python fan. We would spend the next few years turning every design meeting into one long rehash of every Python sketch ever done. Robert had gotten his start at IMSAI, one of the first microcomputer manufacturers. The IMSAI was powered by an Intel 8080 CPU, and Robert is the only other person I ever met who could program the 8080 using hexadecimal.

In fact, everyone on the Very team was absolutely stellar. Charles, who I've already mentioned, is one of those rare people who regularly have original thoughts, and is one heck of a designer. Charles and I had collaborated on a very successful project redesign while we were at Georgia Tech Research Institute. Our team there had completely replaced hardware, rewrote the OS, and the drivers, and every line of the application software in four months. We went from 60,000 lines of code to 15,000 while increasing functionality.

Speaking of GA TECH, Marty had worked in the mainframe computer lab there while working on his masters and was an OS guru and all around smart guy. When I once had to go to Jody F., the team leader, and tell her that I had hit a problem that I couldn't solve, she said, "Have you talked to Marty?" True to form, Marty was responsible for building the master contorl program for the modem, a kind of low level OS.

"As I was saying," Marty continued, "the 9600 baud speed up over the current standard of 2400 is reason enough for people to buy it, but we need something extra to sell an add-on box to owners of the current generation. That something extra is X.25."

"X.25 implementes the physical, data link, and network layers of the OSI Model." he said, "In essence it gives the user the capability to route their own call through a network. Are you a Compusere user? Have you ever heard of PC Pursuit? No? It's a new service that allows you to connect to a service provider locally though your modem, then make a virtual call to say, the west coast, and dial out to a local modem there, all without long distance charges."

"Yes, and X.25 is an error-free protocol," added Robert. "So it is possible to use data compression to speed up the link."

"Why is that a requirement?" I asked. "I've used Kermit to download compressed data using current modems."

"True, but we are going to be compressing all of the data going though the modem on-the-fly without users needing to care how it is happening." Robert answered, "Besides, there is another important advantage to X.25, it supports multiple data channels over a single connection."

"OK, so X.25 divides the software neatly into layers. Who is implementing what layer?" I asked.

Marty looked at me. "You're really asking what your job is, aren't you? So we'll start at the DCE (Data Communications Equipment) at the back of the modem where the phone line connects and work our way forward to the DTE (Data Terminal Equipment) where the PC connects. That tall guy over there is George. George has written the modem engine code for all of the SmartModems since Dale Heatherington left. The modem engine pushes bits to the DSP (Digital Signal Processor) which encodes them into tones that will go over the phone line."

"Next in line is back end of the Very which I am implementing." Marty continued, " We are implementing a synchronous Lap-B protocol to get the best possible throughput for X.25. I'm also designing a macro language that we will be using to implement all of the control logic."

"Then comes the X.25 protocol stack which Letha is programming," Marty said indicating the only other female on the team besides Jody, the team leader who I had spoken with earlier. "Followed closely by Robert, who is doing the PAD, which is the user interface for making X.25 virtual calls."

"Yea, and in my spare time I'll be implementing the compression algorithms," Robert added.

"That brings us to the front end of the modem and your job, the DTE driver."

"That doesn't sound like much code," I complained. "I'll get bored."

"Don't worry," Charles interjected, "We have an extra special something that the head of research, Dr. Copeland came up with called MSP that should keep you interested. I'll show you later on today. "

...

Cue the organist. That concludes this exciting episode. Tune in next time when Larry discovers the truth behind the secret Multi-Streaming Protocol.

Everything is Miscellaneous

Author David Weinberger has just released a marvelous new book called Everything is Miscellaneous, subtitled The Power of the New Digital Disorder. This book is about the way we categorize information, how that is changing in the digital age, and how that affects how we think, the very nature of meaning, and perhaps even the meaning of nature.

He captures you attention right away in the Prologue, which begins by bringing out real world examples of how and why we classify and organize real-world things, and then moves on to point out how this limitation of purely physical things has infected our mental organizational picture up-to-now.

Visit David Weinberger's blog or view his Google Tech Talk on Google Video.

Highly recommended.

Teaching is the Best Software Test

With all of the emphasis that has been recently placed on software testing methodology, I thought I would share my final acceptance test that never fails to find those last lingering bugs and badly designed features. All you have to do is offer an advance training course to some of the typical users of the software before you do final delivery. Some of you already know what I'm talking about and are nodding your head as you read this. The rest of you, read on.

In my experience, teaching the first training class can be one of the most humbling experiences an application designer will ever encounter. First you will have to prepare a lesson plan, and once you start putting down on paper what the steps are to accomplish some example scenario, you will likely discover, as I did, that it doesn't seem so simple as when you were designing and testing. But suppose you are so supremely confident that you decide to wing it and just go in cold. After all, you designed the application, so what could you possibly need to look up?

"OK class, first I guess I'll have to walk you through creating some sample data so that we can have something to try out all of the features on. Hmm, we'll need a blank database to get started, so we'll just copy the one from the examples folder."

"I can't find the examples folder. Where is it?" someone asks.

"It's right there in the C:\MegaApp folder."

"I don't see it."

"Ok let me look. Hmm, are you sure you installed it in the same place as I demonstrated?"

"I don't know, I never pay much attention to that installer stuff. It's always the same."

"Ok here it is in the My Documents folder. I don't have time to fix it so you'll just have to remember to look here whenever I say to look in the MegaApp folder."

"OK class, let's move on. Use explorer to copy the blank database to a new folder."

"I can't find the blank database. What is it called?"

"Blank.dbs"

"I don't see it. Wait, there is an icon shaped like a cylinder labeled blank. Could that be it?"

"You must not have file extensions showing. Not really surprising really since that is the default, I suppose. OK class, listen up. Everyone make sure you have file extensions showing. The option is under folder Options under the Tools menu in explorer. Not finding it? I'll be around to show you in a minute."

Later: "OK, you should now have a copy of the Blank database in a new folder. Let's rename it Sample1.dbs. Done? OK, now double-click on the icon to open it in MegaApp. Problem?"

"Mine opened in Microsoft Word. Looks like garbage"

"Mine opened in something called PRODAS, and crashed."

"Mine just opened the folder in explorer. Were we supposed to rename the file instead of the folder?"

"OK," you say, starting to get rattled, "Apparently these PCs we borrowed from operations aren't as clean as the ones we tested with, and the DBS file extension might be used by a few other apps. Let's take a break while I work this out."

Much later: "Is everyone ready to get started again? OK, now as I was saying, the blank database Sample1 is now open in MegaApp. Question?"

"Mine isn't blank any more. I got bored waiting and filled out some data already."

"OK, just exit MegaApp and throw the file in the trash and make a new copy."

"I threw it away and emptied the trash, but I can't find another one to copy now. Wait, I remember, I decided to skip the copy step and just open the original. It didn't seem important at the time."

"Fine. Will someone please pass him a copy on a floppy? These machines don't have floppies do they? How about a USB stick?"

"I've got one, but when I insert it, it says I need to install a driver. Do we have an internet connection?"

"No, I'm afraid not. I'll tell you what, just uninstall MegaApp and reinstall it. It'll only take a few minutes. While we're waiting, are there any questions? Yes?"

"My screen just went all black. What did I do wrong?"

You're really starting to panic now, "Uh, I'm not sure. What were you doing before it went black?"

"Not a thing. In fact, I haven't touched it for over twenty minutes."

Relief, "Ah, just move the mouse a little. Is that better? It was just the screen saver. Ha, ha."

"OK, I'm finished uninstalling and reinstalling, and maybe I'm just dumb but couldn't all this have been avoided if there was just a New Database option in MegaApp?"

"Oh, well I suppose so. It didn't seem very important with all of the real features that we had to implement, and it's just a few steps after all."

...

And that's just the beginning. By the end of the day total exhaustion sets in from having to constantly troubleshoot 10 problems simultaneously. After a day or two like that you learn that you will do anything to keep the class out of Windows explorer where data magically vanishes down a black hole. Stay in your own app and odds are you won't be surprised more than five times in an hour, but avoid Windows like the plague.

There is a good reason why many modern software packages still include the tried and true installation instructions: "Insert the disk and click on the Start button and choose Run... Type D:\install where D: is the drive letter of your CD-ROM."

As retro as it sounds, it almost always works. If autoplay is enabled , you're usually golden, given you get past the virus checker or the Add or Remove Programs wizard if the user happens to fancy that method, but if not, those simple words printed on the cover of the CD-ROM will save you many support hours, because no one can talk someone through the steps of using a GUI to copy a file. Believe me, even if you can forget your muscle memory and you mirror each step yourself, it will all go horribly wrong because it can.

So schedule that advance training class. You'll be glad you did, but only after a lengthy recovery period.

Has Google Gone To The Dark Side?

Recently I noticed that my PC was thrashing around with a lot of disk I/O while I was trying to work. When this happens, I usually find that I inadvertently left Automatic Updates on or a virus scan is running, but this time I find that a process in Task Manager called GoogleToolbarNotifier is using up quite a bit of CPU time every second or so. Self-Googling Google, I found this site that explained that this is basically Google's answer to Microsoft's attempts to set the default search engine to MSN. Since I didn't want my PC to be part of this virtual battleground, I used the listed instructions to delete GoogleToolbarNotifier, and once again my PC is tranquil and speedy.

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.

...

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.

Calls for an Open Source Hall of Fame

A blog called Software as She's Developed called two years ago for an open source hall of fame. No nominations appear to have been made, but clearly Michael Mahemoff, a London-based freelancer and author of Ajax Design Patterns is a kindred spirit. So let's pick up the torch and run with it!

No Rhyme or Reason

Art in the blood is liable to take the strangest forms. Sherlock Holmes

Back in the day, around 1980 or so, there was a magazine called Omni. It was like the Wired of its day with lots of strange and wonderful things, but that's a subject for another day. What I want to talk about today is the Omni science limerick contest. They intended to publish the top ten or so best limericks on the subject of science and give a grand prize which I've forgotten. Anyhow, I composed some limericks for this contest, which I never submitted, and consequently I never won. So without further ado....

By the limerick bug I was bitten
and though I wrote it all at one sittin'
I tucked it away
until today
when I finally showed off what I'd written

Not some people might say that its terse
while others might even say worse
but in spite of the facts
and all that it lacks
I present my biological verse.

If amoebas are hard to envision
reproducing by cellular fission
the professors might bray
but its simpler to say
that they multiply by division

And now the second masterpiece...

There was a young fellow named Prince
whose gravitational field was intense
he collapsed on his soul
and became a black hole
on the subject of matter, he was dense

If there are any former editors of Omni out there, let me down easy, OK?

War and Peace

“To the man who loves art for its own sake,” remarked Sherlock Homes, tossing aside the advertisement sheet of the Daily Telegraph, ”it is frequently in its least important and lowliest manifestations that the keenest pleasure is to be derived.”

It is scarcely news that the literature of programming has become somewhat dumbed down in the last decade or so. In the bookstore, "Programming for the complete idiot" sits alongside "Learn Visual C++ 9.7 in 8 hours or less." And the state of computer magazines is also a joke with a few articles, mostly reviews, of less than two pages scattered amongst a liter of advertisements for a total page count of less than a hundred. I guess, to be fair, they have to compete with the internet.

Well, for anyone who might not be old enough to remember, I'm here to tell you the state of the computer press was not always so drear. There are still many wonderful books on computer science (such as Algorithms + Data Structures = Programs by Niklaus Wirth), but you won't find many of them on the shelves of your local bookstore, and many are out of print. Computer magazines, however, are all but gone. What remains is but the shell of their former selves. I exaggerate, you say? Let me just reach down into the depths of my archive and see what I can find. Hmm, how about a September 1981 copy of Byte (the small systems) Magazine?

A quick check of the page count gives 496. That's four hundred and-ninety six count 'em, pages. The theme of this particular issue is Artificial Intelligence. There are 13 articles, 6 reviews, and 18 other pieces under the heading of Nucleus. Some of the more impressive titles include:

Tree Searching, Part 1: Basic Techniques by Gregg Williams,
One Step Forward - Three Steps Backup, Computing in the US Space Program by Patric Stakem,
Artificial Intelligence by Steven K Roberts,
Symbolic Differentiation á la LISP by Ronald L Nicol,
Knowledge-Based Expert Systems Come of Age by Richard O Duda and John G Gaschnig,
The Atari Tutorial, Part 1: The Display List by Cris Crawford,
Natural-Language Processing, The Field in Perspective by Gary Hendrix and Earl Sacerdoti,
and The Emperor's Old Clothes" by Charles Antony Richard Hoare.

Need I say more. Oh, and in case you are wondering, the cover shows a picture of a small computer presumably using a tv camera to read that heaviest of literary classics, Tolstoy's War and Peace.

The Mobius Strip

“Chance has put in our way a most singular and whimsical problem, and its solution is its own reward.” Sherlock Holmes.

Mob Software: The Erotic Life of Code, An Essay in First Person by Richard P. Gabriel & Ron Goldman writes a new chapter in the continuing open-source software saga that began with The Cathedral and the Bazaar . Both are fascinating reads and highly recommend, but I want to remunerate on a bit of etymology relating to the essay. In it they quote the Oxford English dictionary definition of mob as, "A multitude or aggregation of persons regarded as not individually important."

They then deliver the central message: "...We know how to produce small portions of software using small development teams—up to 10 or so—but we don’t know how to make software any larger except by accident or by rough trial and error. ... The way out of this predicament is this simple: Set up a fairly clear architectural direction, produce a decent first cut at some of the functionality, let loose the source code, and then turn it over to a mob."

I was stuck by how apropos the word mob seemed in this context. I recalled reading in one of Neal Stephenson's Baroque Cycle books, probably The System of the World, that the origin of the word mob is a shortening form of "mobility" and was first used in a kind of play on words as the opposite of "nobility." A London aristocrat was publicly decrying the rise of a new class of interloping vagabonds who dared to come and go as they pleased, apprenticed to no one, earning their bread wherever they could find work in the new economy.

Sound familiar? It could be an precursor of the post-dot-com practice of programmers finding work via the web on whatever projects that interest them, and getting by, just fine thank you.

Programming as poetry

I just finished Scott Rosenberg's new book Dreaming in Code and it has inspired me to start this blog. There are many inspiring things in the book, but one of the concepts that really stood out was in the chapter titled "Engineers and Artists." It is Richard Gabriel's concept of "programming as literature." Gabriel is a Distinguished Engineer at Sun, and the core of his idea is that we should train developers the way creative writers, poets, or artists are trained - by studying the great works in their field. There is just one thing that has been holding us back from doing this, and that is that most of the great (or at least good) works of software are proprietary closed source.

Well, as you might have noticed, in the last few years the internet, search engines, and the Open Source movement have made the source to hundreds of programs available to anyone interested enough to seek them out. All we need to do to bring Richard's goal within our grasp is to list some examples of code that teaches good programming practices. That will be the overarching goal of this blog, to seek out new source archives, and to boldly code where no one had code before.

Rhyme of the Ancient Programmer

The following poem is one of the oldest examples
(although I'm sure there are older) that I have found
of poetry about software.

 Only LISP Can Make a Tree


I think that I shall never see
A matrix lovely as a tree.
Trees are fifty times as fun
As structures a la PL/I
(Which Dijkstra claims are too baroque).
And SNOBOL's strings just can't compare
With all the leaves a tree may bear.
And COMIT strings are just a joke.
Vectors, tuples too, are nice,
But haven't the impressive flair
Of trees to which a LISP is heir.
A LISPer's life is paradise!

Many people think that JOSS
And others, too, are strictly boss;
And there are many BASIC fans
Who think their favorite language spans
All that would a user please.
Compared to LISP they're all a loss,
For none of them gives all the ease
With which a LISP builds moby trees.

RPG is just a nurd
(As you no doubt have often heard);
The record layouts are absurd,
And numbers packed in decimal form
Will never fit a base-two word
Without a veritable storm
Of gross conversions fro and to
With them arithmetic to do.
And one must allocate the field
Correct arithmetic to yield,
And decimal places represent
Truncation loss to circumvent:
Thus RPG is second-rate.
In LISP one needn't allocate
(That boon alone is heaven-sent!)
The scheme is sheer simplicity:
A number's just another tree.
When numbers threaten overflow
LISP makes the number tree to grow,
Extending its significance
With classic treelike elegance.
A LISP can generate reports,
Create a file, do chains and sorts;
But one thing you will never see
Is moby trees in RPG.

One thing the average language lacks
Is programmed use of push-down stacks.
But LISP provides this feature free:
A stack - you guessed it - is a tree.
An empty stack is simply NIL.
In order, then, the stack to fill
A CONS will push things on the top;
To empty it, a CDR will
Behave exactly like a pop.
A simple CAR will get you back
The last thing you pushed on the stack;
An empty stack's detectable
By testing with the function NULL.
Thus even should a LISPer lose
With PROGs and GOs, RETURNs and DOs,
He need his mind not overtax
To implement recursive hacks:
He'll utilize this clever ruse
Of using trees as moby stacks.
Some claim this method is too slow
Because it uses CONS so much
And thus requires the GC touch;
It has one big advantage, though:
You needn't fear for overflow.
Since LISP allows its trees to grow,
Stacks can to any limits go.

COBOL input is a shame:
The implementors play a game
That no two versions are the same.
And rocky is the FORTRAN road
One's alpha input to decode:
The FORMAT statement is to blame,
But on the user falls the load.
And FOCAL input's just a farce;
But all LISP input comes pre-parsed!
(The input reader gets its fame
By getting storage for each node
From lists of free words scattered sparse.
It parses all the input strings
With aid of mystic mutterings;
From dots and strange parentheses,
From zeros, sevens, A's and Z's,
Constructs, with magic reckonings,
The pointers needed for its trees.
It builds the trees with complex code
With rubout processing bestowed;
When typing errors do forebode
The rubout makes recovery tame,
And losers then will oft exclaim
Their sanity to LISP is owed -
To help these losers is LISP's aim.)

The flow-control of APL
And OS data sets as well
Are best described as tortured hell.
For LISPers everything's a breeze;
They neatly output all their trees
With format-free parentheses
And see their program logic best
By how their lovely parens nest.
While others are by GOs possessed,
And WHILE-DO, CASE, and all the rest,
The LISPing hackers will prefer
With COND their programs to invest
And let their functions all recur
When searching trees in maddened quest.

Expanding records of fixed size
Will quickly programs paralyze.
Though ISAM claims to be so wise
In allocating overflow,
Its data handling is too slow
And finding it takes many tries.
But any fool can plainly see
Inherent flexibility
In data structured as a tree.
When all their efforts have gone sour
To swell fixed records, losers glower.
But list reclaimers hour by hour
By setting all the garbage free
Yield CONSequent capacity:
Thus trees indefinitely flower.
(And trees run on atomic power!)

To men of sensibility
The lesson here is plain to see:
Arrays are used by clods like me,
But only LISP can make a tree.


-- The Great Quux

(with apologies to Joyce Kilmer)


(C) Copyright 1973 Guy L. Steele Jr.  All rights reserved.