While reading Christopher Alexander’s amazing essay “A City is Not a Tree” I was reminded of a page in one of my old notebooks. On that page I had taken some notes on some amazing computer science (and related) dissertations that might form the basis for a personal program design gestalt.1
In this post I’ll mention each paper that I wrote and provide a little context for my choice and add a little motivation.
“The Definition and Implementation of a Computer Programming Language Based on Constraints” By Guy Steele
“ACTORS: A Model of Concurrent Computation in Distributed Systems” by Gul Agha
This was perhaps the work that built on the previous 14 years of Actor theory and formalized it into a practical and workable model of computation.
“Portable and high-level access to the stack with Continuation Marks” by John Clements
This is a generalization of continuations to provide a way to store tagged marks in each continuation frame. This is a bit nuanced, but I learned a lot about “classic” continuations by seeing this contrasting approach.
“Programming Memory-Constrained Networked Embedded Systems” by Adam Dunkels
I read this a long time ago most because I was interested in the idea that someone had developed a fairly modern operating system and TCP stack on the classic Commodore 64. While this was not the progenitor of the “Internet of Things” meme, it went well with (at the time) my exposure to the beginnings of IoT as a stand-alone movement, stemming from what was the seeds of sensor network simulation techniques.
“Procedures as a representation for data in a computer program for understanding natural language”
One of my summer projects in college2 was to pick a famous paper and implement the system described therein. My choice (with some prompting from my professor) was a “Blocks World” program that, given an abstract representation of stacked colored blocks, took English-language commands to manipulate the blocks. The program was written in XLISP and while it did understand a limited subset of English, the language that it understood was more Zork-like than anything else. For a grad school project I further built on that codebase by wiring in CLIPS and allowing the specification of a goal state, after which the program would solve the required steps to reach that goal.
Speaking of CLIPS…
“On the efficient implementation of production systems” by Charles Forgy
My undergrad and graduate focus was on expert systems design and development3 so needless to say this paper was kinda the whizz for me.
“Fexprs as the basis of Lisp function application; or, $vau: the ultimate abstraction” by John Shutt
It was long into my life as a Lisp adherent that I learned about fexprs, which have a long history in LISP. Simply put (nearly to the point of libel) fexprs are functions that do not evaluate their arguments. For a long time fexprs were a dead branch of the Lisp family lineage, but Shutt’s paper gives them the thorough and respectful treatment that they deserve.
“[Behavioral Software Contracts
A topic for another day… but Alexander’s work is as good a summary as any I suppose.↩︎
My college had a summer program for its computer science department where students could work full-time with a local tech company and also work on a summer-long project. I learned a tremendous amount during this time and am still influenced by those lessons even today.↩︎
A decidedly unfashionable branch of Ai these days… though I’ve often found that most systems that I consult for could use an expert system or have a “ad-hoc, informally-specified, bug-ridden, slow implementation of” an expert system embedded within. Even in the face of the fact that I rarely do active expert systems development, the processes of expert system design still influence the way that I do greenfield systems development.↩︎