Send More Paramedics

Notes on Interactive Computing Environments

Apr 3, 2019

In the pantheon of my personal favorite books on computing, Interactive Programming Environments by Barstow¹, Shrobe, and Sandewall places somewhere in the proverbial chancel.

The book covers a wide range of topics from Lisp Machines, Smalltalk, Pascal, OOP, UNIX, AI, and intelligent agents but the common thread is this:

Your programming environments should be an active partner in the act of creating systems.

This post contains notes on some of the points along this vector with some jumping-off points for further exploration and research.

Moore and Forth

Programming a Problem-Oriented Language by Charles Moore (PDF) is Chuck Moore’s thesis on Forth and its design and core philosophy. The genesis of the language stems from a simple premise:

I’ve written many programs over the years. I’ve tried to write good programs, and I’ve observed the manner in which I write them rather critically. My goal has been to decrease the effort required and increase the quality produced.

Moore’s motivations culminated in the Forth programming language, which in turn led to the term “problem-oriented-language.” The basic idea is that a programming language should facilitate the construction of programs by allowing you to build in layers, where each layer is a specialized language for building the layer above it. Certainly the book dives deeper into matters such as simplicity, YAGNI, bootstrapping, and the like, but the core idea of problem-orientation is the key take away.

Fundament

Moore’s work encourages the creation of the entire programming stack, but there are varying levels at which an interactive environment can evolve up from. For example, one of my attempts at the IPE idea built on the Java Virtual Machine and its included graphical interface APIs. The idea was to build a tool that I could explore Java APIs with in an interactive manner. However, to do that I had to build a total environment for building scratchpads for exploration.

I got it into a good place eventually, but the increased capabilities of the BlueJ environment convinced me to end development. Later I worked on various IPEs hosted on platforms varying from CLIPS, to Emacs, to Emacs in CLIPS, to JavaScript. I learned a lot along the way, but never felt that I had even scratched the surface of finding an environment that helped me to explore.

Work for the next 10 years

Any work in IPEs is likely to require a huge amount of effort and brain-power to crack. Indeed, you could expect to spend the next 10-years just gaining a deep understanding of the problem space and contributing to the rich landscape. Even after the 10-years are spent the expected likelihood is that any artifacts created along the way are likely to find little to no usage or to be obviated by something else entirely. Enormous amounts of effort went into systems such as Interlisp, Project Chandler, Backus’ FP ², the Data General Eclipse MV/8000, and Xanadu and every one of them are relegated to the dustbin of computing history. It’s difficult to start a project that most likely will merely provide footnotes to the next generation of proposed solutions.

So it goes.

Bootstrapping

Smalltalk is a great example of a system that evolved via bootstrapping new iterations using previous versions of itself. Alan Kay talks about this as the ideal for Smalltalk development for much of its early life in his famous OOPSLA 1997 talk. The whole talk is an amazing repository of wisdom that hasn’t yet been truly tapped for inspiration.

That said, while Smalltalk itself moved away from the meta-language bootstrapping model with the development of Smalltalk-80, the early principles are foundational. The seminal book Smalltalk-80: The Language and Its Implementation captures the gestalt of the early days by including the source code for a VM for the language described in the book using the language described in the book. The ideal outlined by early Smalltalk implementations (and Squeak) is an ideal that IPEs should strive for. That is, the purpose of an Interactive Programming Environment should not be to provide a solution, but instead to provide a set of ideas useful for exploring higher-level ideas better than those provided in the base environment.

Emacs

These days the closest thing that I have to a powerful IPE in my life is the Emacs text editor. In addition to my place for writing blog posts, Emacs is also my programming environment, idea scratchpad, TODO-list manager, a source control interface, and occasionally a game system. Emacs is extended with the Emacs Lisp programming language and provides a set of abstractions around working with text buffers. The act of extending Emacs is a bit of black magic, but at least one interesting manual for writing extensions has been written.

A total head-space

Douglas Englebart’s NLS was a total collaborative environment meant to enable its users to engage in “knowledge work.” The idea was to provide a repository for knowledge, tools for collaboration, idea capture, and discovery. However, NLS was not just a set of software tools, instead it was an environment that ensconced the knowledge worker.

From the now ubiquitous mouse to the chorded keyboard, the NLS workspace was designed as a phase-1 stage in moving towards human-machine co-evolution. Perhaps the ideal for IPEs is not just a software concern but instead a total headspace. There was a popular trend in software writing tools that promised immersive environments (see Writeroom and FocusWriter for examples), but they stopped at the screen. Perhaps something akin to Dan Price’s Hobbit home, a hideaway van, or perhaps Bruce Hauman‘s geodesic dome is a starting point for a truly immersive IPE… an IIPE so to speak.

Wood-workers build their own benches

My colleague Tim Ewald gave one of the best programming talks that I’ve ever seen called Programming With Hand Tools in which he outlines three reasons for using hand tools in construction:

1. (They’re) simple to the point of primitive
2. (They provide) great precision and control
3. (Allow) flexibility to make anything

He goes on to motivate these points in the talk, but if you’ve read to this point then you probably see how they relate to the idea of immersive interactive programming environments.

I’ll leave you with this quote:

The motivation, in the first place, is just filling a gap… It’s a contradiction. You have to really know what you’re missing. And in order to know what you’re missing, then you have to know what you have.

—Dominick Fernow

:F