The motivation for this column is a sentence from Robert Floyd's Turing Award lecture, "The Paradigms of Programming:" "I believe that the best chance we have to improve the general practice of programming is to attend to our paradigms." Programming paradigms--the broad approaches to problem solving, the sets of unwritten rules accepted by communities of programmers, the model problems that condition our thinking about a problem well before we get to the point of selecting an appropriate algorithm--can enslave or liberate our thinking about our craft.
The column's premise is that by exploring alternative paradigms, we can free ourselves from the mental chains of the widely accepted and unquestioned paradigms. That means more questioning than answering, and it means looking at some futuristic approaches to software development. This exploration of the not-yet-but-soon-to-be-practical is fraught with difficulties: finding the substance under the hype in writings on artificial intelligence, for example, is one of the model problems of the technical writer's paradigm.
A particularly lurid example of AI hype crossed my desk recently in the form of a press release for a new book. You will no doubt forgive me if I don't embarrass the author/publisher by naming the work, particularly since, having burdened the brief book with an 11-word, 6-buzzword title, he has already named it more than adequately. The book purports to explain thinking and artificial intelligence, lay out a new cognitive model, and completely solve the problem of the management of complexity. Here are some samples of the release's claims: "Next, the author re-examines the nature of reality itself ... explains how the human brain works ... a computer can be made to 'think' and create 'new' thoughts ... by Christmas [you will be able to] experience your own 'thinking computer.' "
Nowhere in the press material is the book connected with any other work on AI or thinking, except for dropping the names of Francis Bacon, Rene Descartes, and George Boole.
A lot of the promotional materials for expert system implementations are almost this bad. That's why I've not done much on expert systems so far. But the intended scope of this column includes expert systems and is even broader than that; I want to examine the paradigmatic approach itself. For example, it's not out of order here to discuss what programmers have to teach writers about HyperText. Writers need to expand their paradigms, too.
A recent article on the promise of HyperText claimed that, with the advent of HyperCard and other tools for flexible organization of text, the author faces a trade-off between reader control and author control of the structure of the material. Some links between elements of a work must be followed sequentially if the reader is to follow the argument or the story line. Other links may be followed in any order without penalty. Traditional hard-copy writing stands at one end of the spectrum of control and the electronic version of William Burroughs-style cut-and-randomly-paste organization stands at the other end, with the reader wielding the scissors and paste bottle. The problem is to pick the right point on the spectrum for your particular subject matter. Yeah, identifying the problem is always useful, but the writer of the piece I was reading didn't seem to have a clue to the solution. I think programmers have all the clues.
The HyperTextual author needs to deal with many of the issues that programmers have to deal with in writing structured or object-oriented code. Modules need to be defined at the right level. Each should serve one purpose. The logical structure should be mapped out explicitly and the actual structure should mirror it. Connections not in the logical structure should not appear in the actual structure. Some components may need to be nested within others.
These principles, familiar to programmers, can actually be applied to writing when one is not tied to the linearity of the page, but no one is really doing it yet, and no one knows what kind of writing will result when writers work this way. It seems clear that it won't much affect traditional forms, since they are, well, traditional forms. Telling a story is a sequential process by definition. It will remain a sequential process, and people will continue to tell stories. Explaining how to perform a complicated function may or may not be entirely sequential, but its sequential aspects will continue to be dealt with sequentially. Reference books do not need to be presented sequentially and are the most obvious beneficiaries of nonsequential writing. But new forms will emerge as well.
It looks to me like it's neither intrinsically hard nor easy to write this way, any more than writing a reference book is intrinsically harder or easier than writing a novel. It's just a different paradigm for writers, and I'm betting that writers who also happen to be programmers will get it right first.
I must admit that I worked through that little exercise in programmer back-patting to soften you up for a new look at the point-and-shoot paradigm of programming.
If you're like most sensitive software developers, your reaction to a point-and-shoot icon-based programming language is probably something like Scott Watson's.
At the MacWorld Expo in Boston this summer, several developers, including Macintosh system-software developer Andy Herzfeld and Scott Watson, the author of Red Ryder, sat on a panel and fielded questions from the audience. A typical question was: What are you working on right now? Andy Herzfeld fielded that one, saying that he couldn't really talk about the new hardware that he and Burrell Smith were working on, but that he had found it necessary to write a new language to support that effort, a completely wordless language that uses no keyboard. He does all his programming these days, he said, with a mouse, by pointing at icons.
Scott Watson twitched convulsively.
It was a magnificently expressive act of communication, and it brought down the house. In one gesture, he got across his abject horror at the very idea of a nonverbal programming language and communicated it nonverbally so effectively that he broke up the audience. I'm a pretty good writer and I told the story as well as I could, but you probably didn't fall on the floor laughing, right? You really had to see it.
End of anecdote. The argument against picture languages is more than anecdotal. George Morrow has been explaining for some time why iconic languages like Chinese lack the expressive power of character-based languages like English, and how this applies to programming. For purposes of argument I am going to simplify Morrow's position probably beyond the point where he would like to be associated with it today. What I will be presenting is a fairly common attitude toward iconic languages, the attitude touched when Scott Watson twitched, and an attitude that George Morrow has in the past pretty explicitly espoused. I'll call it Simple Morrow.
Here it is: Pictures are a poor and an imprecise tool for communicating abstract ideas. Pictures are static, they have no obvious rules of combination comparable to the rules for combining words in character-based natural and programming languages, and a picture vocabulary requires many more elementary symbols than the 26 letters of the Roman alphabet or the 256 characters of 8-bit ASCII. If pictures are a good basis for a language, why are there no purely iconic languages today? Hieroglyphics never changed and died out, while Chinese has evolved into a partly-phonetic, partly-symbolic menace to communication. Icons are for people who can't read.
In an excellent new magazine called Language Technology, I recently came across a strong counter proposal. The article "Will Your Grandchildren Speak Chinese?" reports on a word processing/translating system that allows a user to type Pinyin (Roman character text) Mandarin Chinese and converts it to Hanzi ideographs faster than one can type the same text in English. The author, who is chairperson of the Machine Translation Committee of the New York Circle of Translators, wraps up the piece by speculating that Chinese could replace English as the world's common language, precisely because Chinese is a better language than English for writing computer programs. You might want to read that sentence again. He asks, "Could it be that the developers of computer languages have been struggling to reinvent Chinese?"
The piece was not very technical and its premise not, I think, very defensible; but what I think is interesting is that an intelligent person, looking at the issues and the evidence, could put forth such an argument. I think that he can do so because icons are more complex than Simple Morrow thinks.
Are iconic programming languages a bad idea? And if they do have merit, are they only of value to people who already read an iconic language like Chinese?
There are at least three levels of abstraction possible when using iconic or visual encoding. Pictures look like what they represent, abstract symbols bear some analogical relationship to their referents, and arbitrary signs need have no relationship to what they represent.
If both icons and strings of characters are used arbitrarily, their relative information content is a simple mathematical issue. How many pixels make up an icon, and how many bits per pixel? How long can the string be? It seems that some concepts, such as the existence operator, require such arbitrary representation from either an iconic or a character-based language.
The mapping from strings of characters to concepts in a programming language or a natural language is at the lowest level entirely arbitrary. That would seem to suggest that adding some meaningfulness to the mapping when possible, as Chinese does by retaining some representational ideographs, could only increase the communicative ability of the language. That a programming language that uses visual information when it's useful but allows for combining icons into new icons and permits the arbitrary association of icons with concepts--that such a language would be more expressive and easier to use than a character-based language. And that may be the case for those used to thinking in Chinese.
Chinese gets a bad rap from Simple Morrow. I can't read Chinese, but I understand that it is a very expressive language, with a combination of abstract symbols and arbitrary signs combined according to rules as powerful as the grammar of English. It supports subtle philosophical discussions, deep and beautiful poetry, and may even permit the representation of programming concepts. Its biggest drawback seems to be not the expressive power of its symbols or the difficulty of reading them, but the difficulty of producing them. They require a very big keyboard. And there seem to be solutions to that problem, from using a characterbased front end (which is not exactly an admission of the superiority representational power of character-based languages) to Andy Herzfeld's keyboardless approach.
Herzfeld is evidence that at least one native speaker of a character-based language has found a reason to use, even to create, an iconic language. But it does seem clear that we character types need at least to be able to use something like our natural language for things like naming variables. The Roman alphabet is too powerful a tool not to use. Some icons, of course, include text. Perhaps the ideal approach is a model in which every entity has both a character-string name and visual attributes, each of which might be inherited in full or part from its class. Then you could program using icons or text or a mixture of the two.
What Will You Get Mom for Christmas?
What Can Programmers Teach Writers about HyperText?
What Makes Scott Watson Twitch?
Will Your Grandchildren Speak Chinese?
How Long Is a Piece of String?