Programmers Should Program

As computer professionals, programmers need to use a lot of software. For some programmers this can mean using many different kinds of software systems. For others, it may mean using one particular program (or suite of programs) very extensively.

Given that the core act of programming involves writing and modifying code, it is no surprise that programmers spend much of their time inside text editors¹ — including to the point where some superusers will say that they “live inside” their editors, doing all of their work there. This should not be surprising, as all software is code, and code is just text that does certain things when processed — or, interpreted² — in a certain way.

For most programmers, they program in one of two iterative modalities:

1. The “Write → Compile → Execute” Loop

In this modality, now common in both interpreted languages and in compiled languages, the programmer writes their code, feeds it into a compiler, then executes the result — testing it for correct functionality.

It’s a fine, acceptable way to program. There’s nothing inherently wrong with it, but this way of coding treats the result of one’s effort as fundamentally separate from the part of the machine the programmer is operating from. It’s akin to creating a mystical black box, an opaque piece of machinery that, while functional, is inscrutable.

I think programmers can aspire for a better way of programming a machine, and I am far from alone in that regard, which is ultimately what precipitated the invention of…

2. The “Read → Eval → Print” Loop

What if, from the moment you wrote a piece of code, its functions became available to use right away? In many scripting environments, this is completely possible. When executing the script interpreter, one can write new functions which are then immediately made available to the user. If, for example, you’re doing some math homework and need the quadratic formula, you can quickly write code for it and then immediately put it to use. The “REPL” (Read → Eval → Print Loop) is a fantastic addition to a programmer’s repertoire.

Unfortunately, problems begin to arise once one needs to fix errors in their code. Because REPLs usually live inside command line terminal emulators, once a line of code is entered, one cannot go back and edit it like in a text file; you need to enter your corrected code all over again. For all but the simplest pieces of code, this is a usability disaster!

Another Way?

About a year ago, I began to use an archaic text editor called Acme. It’s a product of an operating system called Plan 9 from Bell Labs, an experimental operating system that was intended to be the successor to UNIX. Due to political factors, the Plan didn’t exactly work out. Still, it’s interesting to see what ideas were being thrown around in the lab that birthed UNIX.

Acme is, in a sense, 9P’s main text editor and programming environment. The factor that makes it so interesting to me is its inclusion of a terminal emulator script called “Win,” which allows the user to execute any command line program from the editor itself. Because these command lines live inside of text editor windows, one can actually go backward in history and modify erroneous functions, sending them back to the REPL and thus increasing the pace of one’s iteration cycle.

Unfortunately, Acme leaves a lot to be desired:

1. It’s mouse-centric. It does not function without a mouse — and without an accurate mouse, it’s clunky and cumbersome. Worse, this requirement makes it somewhat hostile to users with repetitive strain injuries or whom simply lack the mobility to constantly use a pointing device.
2. While this is mainly due to it originally being programmed in the early 90s, there are many other accessibility problems with the application.
3. Acme is technically programmable, but only by the use of an interface it provides to the external system. This means one can’t write code within Acme to modify or extend its own internal environment. Any REPL experience one can get will only affect the interpreter that presents it, as opposed to the wider system.

Moving Forward

I want a programming environment that lets me quickly write code that can actually execute within said environment, with reasonably usable text editor facilities that allow me to execute code as I write it. I want the programming environment to change dynamically by me writing code, for my tools to be responsive to what I write by actually doing what I write. I want to smash together the interpreter, REPL, and text editor — all into one.

I’ve made good progress so far; I hope to reveal the fruits of my efforts soon.