“I made up the term object-oriented, and I can tell you I did not have C++ in mind” - Alan Kay

The other day, I downloaded a new audiobook player from the F-Droid store. The player is minimal by design, which I like, but where I would have probably included ‘time played’ alongside ‘total time’ the designer has put a single value for ‘time remaining’. That got me thinking.

F-Droid is a mobile application marketplace which provides a means for Android devices to download free and open source software. Part of the promise of free and open source software is that you can make it your own. So, what would I need to do to make such a change?

First, I would need to download a local copy of the source code from Github using the Git CLI tool. Then I would need to open the project in a text editor.

Thereupon, the first thing I would notice is that the application is written in Kotlin which is a language that I do not really know but which is similar enough to Java that making a simple UI tweak would not present too much of a challenge. Then I would be faced with the mainly manual process of navigating the codebase to find the place or places where the code needs to change.

Thereafter, I would need to build an executable, which, depending on the libraries upon which the project relies could be anything from straightforward to painful. Finally, I would need to connect my mobile device to the PC and replace the existing application with my new build.

Simple, right?

Is there any alternative? As things stand, not really.

What would making a small UI tweak in a really free system look like?

First of all, one would probably enable an option to make the environment editable (as compelling as I find this way of thinking about computation, you probably wouldn’t want it switched on all of the time). Then you would send a message to the widget asking it about its display procedure. You would make the necessary changes right there in the environment and once those changes were confirmed the new behaviour would be immediately available. No additional tools, no edit-compile-run-debug cycle, just a sea of live objects that respond to messages.

What I have just described is the way in which the original object-oriented programming language, Smalltalk, actually worked.

Unlike conventional programming environments, which are file and text based, Smalltalk systems are conceptualised as a sea of live objects—and all of the computation happens by sending messages to those objects.

How come people in the 1970s had already figured out that this is how computers are supposed to work yet we don’t have mainstream implementations of this technology today?