If I may draw an arbitrary line in our use of computers, I’d suggest we either:
1. Attempt to use computers as an extension of our minds — that is, we want to model what’s in our head on the machine
2. Translate our ideas into something the computer can understand
As my friend Hani said, labelling, bucketing, or translating an idea always results in a nonzero loss of fidelity. Therefore, if we spend all of our time doing #2 above, then we’re never going to use general purpose programming as an extension of our minds without fidelity loss of the concepts and ideas we’re trying to nurture.
And make no mistake, that is what we want. Nurturing. We want to nurture our ideas, the things we have in our heads. This is a topic that most non-programmers don’t know even exists — it’s the same as a poet, or a musician, or a sculptor. Concepts and “software” isn’t best architected, it’s best refined continuously until it’s “good enough”.
The way this *should* work is that our tools should become extensions of our mind and body. An artists paintbrush, a poet’s pen, a musician’s piano. This allows us to behave and react at higher levels. The artist never concerns himself with the way the paintbrush is held, and the musician rarely concerns herself with the arch of her fingers on the keys. These things can be used in subtle ways by the expert to produce ever-finer-grained work, but the focus isn’t on that part of the tool, the focus is on the work.
When we write code, we’re still focusing on text. We type text into a file and then tell our interpreters or compilers to “try again”. So, we still have a similar process of iteration, but it’s a needlessly slow process, rife with delays and unnecessary latency. Most importantly, such hindrances prevent our systems from feeling like true extensions of ourselves.
Allowing a system to extend our mind might even have the secondary benefit of preventing the “house of cards” from falling when we’re interrupted. This is something every programmer is familiar with.
I’ve spent almost all of my professional life in state #2, that is, doing translation. It’s what most programmers do. Lately, I’ve become fascinated with the Smalltalk programming environment, mostly because I believe it was the last serious attempt to remove this translation step. It wasn’t perfect, but it was *much* better than any tool we have today. You still had to edit text, but every other hindrance was gone, so it allowed you to focus on nothing but objects in the system.
Editing live objects seems one of the most compelling ways to remove the “edit – save – recompile” cycle. Unfortunately, to accomplish this cuts deeply into the way most people write code. For example, the Smalltalk VM could snapshot itself (it was a primitive VM instruction). This allowed you to quickly send the state of “your world” elsewhere with zero fidelity loss. No current interpreters support this (Google’s DART sort of does). Snapshotting isn’t the lynchpin, but it’s a necessary consequence of live editing. No matter that it also removes the reliance on the concept of a “file”.
Instead of editing files that contain a representation of our objects (that are later interpreted), we could be directly interacting with our objects in memory.
