About Kent Pitman, keep in mind that he is not talking about the process that led from many Lisp dialects to the original “Common Lisp: The Lanaguage”. Rather, he’s talking about what happened later, when CLTL was being turned into an official ANSI specification. The two processes were vastly different. The former was informal, orchestrated by Guy Steele, and very pleasant. The latter was run according to official ANSI and X3 rules, and was very painful and unpleasant, at least as far as I was concerned.

It’s too bad people don’t know about all the fine researchers and developers who were at Xerox PARC in its heyday. Mark Miller, above, mentioned Dan Ingalls, Larry Tesler, and Adele Goldberg. Yes, L. Peter Deutsch did work there. He was one of the most brilliant people in the software world. He had a lot to do with the invention of time-sharing, Lisp, JIT compilers, and so much more. Gregor did indeed work at PARC. And then there’s Danny Bobrow, Johan DeKleer, Larry Masinter, Alice Harley, Bob Taylor, Butler Lampson, Chuck Thacker, Bob Metcalfe, Brian Williams, Lucy Suchman, Rick Cattell, John Warnock, Charles Geschke… So much of the computing environment/infrastructure/ecosystem that we all take for granted today emerged from the work of these people!

Oh, and I think Teitelman was joking when he said “seven”, like he was just throwing a number out there to get under Dijkstra’s skin.

Okay, but if we’re going to just stick to what can be proven, then should there be no such things as operating systems?

I understand what you’re saying, but context matters. If you watch Kay’s 1997 speech “The Computer Revolution Hasn’t Happened Yet”, you can see the incident I’m talking about. He gives some of the context for his theory of computing. He talked about an essay Dijkstra wrote called “On the fact that the Atlantic has two sides”. He talked about how in his classes CS is based on classical mathematics, and that his program is recognized by royalty. Kay wrote a response paper called, “On the fact that most of the software is written on one side of the Atlantic”. He said, “Computers form a new kind of math. They don’t really fit well into classical math,” implying that Dijkstra was missing the point, and lacking in vision. To back up his point he said that Euler wrote many volumes filled with proofs, and speculations about what might be true, many of which turned out to be true. On later inspection, however, most of his proofs were found to be flawed, and he said that many Ph.D’s have been granted on the basis of students finding flaws in Eulers proofs, but thinking that his speculations were true, and finding proofs that actually work to prove Euler correct. He said, “So debugging actually goes on in mathematics as well.”

Kay has long advocated for late-binding, self-reflective systems, because this enables debugging, and even changing the design while the program is “alive”. You can repair the flaw and continue execution where a thread halted, or change the design while the program is running without halting anything. The point is the program and/or the system doesn’t have to stop. This is how Erlang works. A bug doesn’t bring the system down. So bugs become “tolerable” because they’re less disruptive.

A key difference I think between Dijkstra and Kay is Dijkstra saw CS as purely a form of math (based on classical math, that is), whereas Kay sees CS as a fusion of math and science. In science we come up with hypotheses and test them. Science is a philosophy of discovery. So we don’t know what’s true ahead of time, and most hypotheses don’t pan out. I think Kay sees programming as a process of experimentation. Just as in science, you work with real things, see how they respond to experiments, and then you learn something about them. You can then build on this knowledge.

I’m not sure if Dijkstra would agree on this, but a key thing Kay has said for years is, “We haven’t figured out what computing is yet.” Dijkstra liked to stick to what could be proven. Kay, like Euler I guess, likes to speculate on “what might be true” and hopes that a good proof will come along later.

Dijkstra, however, was right in what he said: programs should be bug-free, and to get there you should prove it mathematically. But he came from a theoretical background (he graduated a ‘theoretical physicist’), and the industry didn’t see (and still doesn’t) the problem with tolerable bugs and incremental software releases. You can see that by the reaction people got when Teitelman said “Seven” bugs were tolerable. Seven bugs in a big program are tolerable by everyone’s standard.

Poor Pitman, bad luck every time.

>> Teitelman said that we’ve got to strive to separate the business process from the code.

This is what I think he meant:

That’s sort of the dynamic corollary to not hard coding your data base connection string and stuff like that. Make everything data driven that you can. Have every setting you can think of be set from a configuration file. What’s left after that? There’s the pain of having to recompile and redeploy your binaries for every little change. It’s the same sort of problem those guys at the DSM workshop were trying to deal with when they were emphasizing their “declarative and interpretative approaches” to coding. It’s the same problem that Lisp solved long ago, as demonstrated when they debugged running code on a satellite zillions of miles away.

“Late binding self-reflexive” systems are more maleable at run-time… and let you get away with “hard coding” even less than you would otherwise….

Three: Dan Ingalls, Larry Tesler, Adele Goldberg. That’s just the Learning Research Group. That’s where my main focus was when I learned about their work. I forget, but did Peter Deutsch work there?

The part about Dijkstra (that’s how his name was spelled) was hilarious! I have a good idea about what was going on. I read a few of Dijkstra’s speeches. He believed that all programs should be proved correct mathematically before they were implemented on a computer, thereby removing all bugs before implementation. He even said that in his freshman classes they would devise their own simple programming language that they would use on the chalkboard and on paper. The programs they wrote in it would just be exercises for mathematic proof. And he made sure the language didn’t exist on any of the computers at the school so that students “would not be tempted to test their programs”. He was totally against testing programs. He saw CS as purely a mathematical discipline (I think), and he wanted the discipline to only focus on programming that could be proved mathematically, to even get away from artifacts like operating systems, because they could not be proved correct, and disciplines like software engineering which he thought was a sham (actually I think his opinion about the latter has had validity). So the idea of writing a program before it was proven, thereby permitting bugs, was terrible practice to him.

Apparently Alan Kay and Dijkstra had a long feud. In one of his speeches from 1997 I talk about in one of my posts Kay just rips Dijkstra up one side and down the other. Kay, and it sounds like Teitleman, and Dijkstra just came from two completely opposite schools of thought as far as what should be studied in CS, and to a lesser extent what programming was.

I vaguely remember reading about the Durado in Kay’s “The Early History of Smalltalk”. It was a model that Xerox made in the 70s.

Teitelman said that we’ve got to strive to separate the business process from the code.

Huh. It would be interesting to hear more of what he really meant by this. Perhaps he was talking more about the philosophy of human-computer symbiosis, that computers should be tools for helping people understand complexity and work together more effectively, not automate what people already do.

I can tell you that the “dark rumors about computing nightmares caused by DWIM” had grounding in fact. We tried, VERY hard, to keep DWIM in Lyric and make it work in the combined IL/CL environment, but were defeated ultimately by Teitelman’s impenetrable DWIM code.

Larry Masinter (PARC Interlisp wizard, creator of Masterscope) couldn’t do it, and ultimately settled for reducing DWIM’s scope to simple spelling correction and package guessing.