Room 101


Gilad Bracha's blog. A place to be (re)educated in Newspeak

April 1st, 2024

Breaking Silos

Modern applications are siloed. It's difficult to get them to cooperate with each other. It was not always thus.  Consider the Apple Newton, a mobile device released almost 30 years ago.  Apps were written in NewtonScript, a language designed for the Newton platform. NewtonScript was a prototype based language, in some ways similar to Javascript, but much nicer.

Why nicer? For starters, it was designed; not even Javascript's creator claims it was designed. Rather, it was the result of a frenzied scramble under insane scheduling demands - and it shows. Despite decades of heroic efforts, you can't fix the unfixable.

Unlike some other systems, was nothing special about the top level view of a Newton application. This enabled app compositionality: an entire app could be nested in another.

Objects (known as frames in NewtonScript) inherited from both their prototype and their parent. Frames that represented on-screen views had the enclosing view as their parent.  Indeed, the parent inheritance feature of the language was there precisely to facilitate its use in the UI.

Combined, these two points meant that you could take an app A (or a part of it), and use it as a widget inside another app B, and now that instance of A had access to properties of the surrounding app, B. You could design your app to seek out information from its dynamic environment; and of course, the surrounding view could also query its nested views. 

In addition, apps persisted their data in object stores known as soups. These were not per-application, but accessible to multiple apps. 

The idea of co-designing language and UI (especially the idea of leveraging shared notions of scope and compositionality)  existed even earlier, in Boxer, an elegant system created in the 1980s. Boxer literally unified UI with program construction and visualization/debugging. 

Another manifestation of compositionality is Morphic, the graphics system first developed in Self, and later adapted for use by Squeak and by Lively Kernel. Morphic however is focused at a lower level, that of graphical structure as opposed to application logic. 

Some twenty years ago, the ability to interactively embed any widget (including "top-level" ones like windows) inside any other, as in Morphic, inspired me and my colleague Yaron Kashai to propose an app store where apps would be composable.

Apps would also live-update and automatically synchronize (in other words, they'd always be local-first) - all well before Apple popularized the concept of an app store;  but those are separate matters which I've described elsewhere. Newspeak derived, in part, from that effort.

 


The poster child example for app composition is travel. The above image is an example, taken  from a PowerPoint presentation of ours from early 2005. The idea is that you define a button that looks up the weather (using the weather service(s) of your choice) and the user can drag it into their itinerary. When pressed, the button looks up the location and date from the surrounding widgets and displays the result. 

The leadership of my erstwhile employer, Sun Microsystems, had no interest in this idea, as it did not fit with the concept of a thin client, to which they were wedded at the time. In contrast, VCs said it was a platform play, and someone like Sun Micro should do this.  Eventually, we started the Newspeak project with the long term goal of building something like this, but the project lost funding in the crash of 2008. Sic transit gloria mundi.

Alas, none of these systems really caught on. The mainstream, as usual, adopted inferior schemes.
Variants of these ideas echo in the current Newspeak system. The Hopscotch UI framework incorporated a notion of communication up the widget parent chain independent of the language. Ampleforth documents compose via transclusion, and utilize object scope for evaluation of general purpose code.

The age of silos is finally coming to an end, with the advent of artificial intelligence.

Artificial intelligence is the solution to the lack of natural intelligence that has plagued our industry (and our species as a whole).

AI has the ability to bridge between distinct apps, without relying on any notion of shared API or programming system. Of course, this comes at a price. It is far more computationally expensive to have an AI figure out how to use a variety of APIs and sites to share information, then to run widgets inherently designed for such sharing in the first place.  Security is also a major concern.
That said, it avoids the need for humans to produce and, especially, adopt a platform and APIs to facilitate sharing and coordination.

The effects on our digital ecosystem are likely to be very substantial. I recently co-authored a post on the F5 blog drawing attention to these issues, so I won't belabor them here. 

All this overlaps with my earlier post on the the impact of AI on programming.  Ideally, the coming one-stop shop for digital interaction should be controllable and programmable, live, by its users and not by corporate interests. A live, local-first AI-assisted computational medium. Whether people have the sense or taste to make that choice is an open question. History says no, but I have to believe in something better.