Objects Can Be Written, Inspected, And Changed in Context

David West describes objects as actors on the computer stage, and even the meta-acting of programmers picking up the CRC card representing an object and role-playing its part in the system, explaining what data they're using and what messages they're sending to the other objects. Objects are fundamentally a live, interactive way of thinking about software, so they would be best supported by a live, interactive way of turning thought into software.

The Smalltalk environments, including modern ones such as Pharo and Amber—https://www.amber-lang.net/, demonstrate that such tools are possible. Pharo in particular features novel additions to the developer experience, one of the bullet points on the project's About page (https://pharo.org/about) tells us that "yes, we code in the debugger."

Distributing the software that is made with such an environment, currently, can be suboptimal. With Pharo, you either export specific classes into a package that somebody else who already has Pharo set up can use, or you write the state of your whole Pharo environment to an image file, and give the Pharo VM and the image file to the person who will use your software. Amber works like this too, but in the background is using the popular Bower package manager for JavaScript and its image contains just a few classes that implement JavaScript functions. Additionally, many JavaScript developers do not distribute their software in the conventional sense, as it is either served as needed to the browser or run by the developers themselves in a Node.js service.

Such live interaction is not confined to the Smalltalk world. I am writing this section of the book using the GNU Emacs—https://www.gnu.org/software/emacs/ text editor, which is really an Emacs Lisp interpreter with a dynamic text-centric user interface. At any time, I can type some Emacs Lisp in and evaluate it, including defining new functions or redefining existing functions. For example, given a paragraph containing the following:

(defun words () (interactive) (shell-command (concat "wc -w " buffer-file-name)))

I can move my cursor to the end of the paragraph, run the Emacs Lisp eval-last-sexp function, and then have a new words function that returns 1909, the number of words (at the time of writing) in this part of the manuscript. If it didn't do that, if I had accidentally counted characters instead of words, I could edit the function, re-evaluate it, and carry on using the fixed version. There's no need to quit Emacs while I re-build it, because I'm editing the code in the same environment that it runs in.