Breaking Silos by Gilad Bracha Experiment: AI assisted summary edited by me to pique your interest (let me know what you think): • Modern applications are siloed and have difficulty cooperating with each other. • This was not always the case, exemplified by the Apple Newton, a mobile device released nearly 30 years ago. • Apps on the Newton were written in NewtonScript, a prototype-based language. • Newton applications had a flexible top-level view, enabling app compositionality where entire apps could be nested within others. • Objects in NewtonScript (called frames) inherited properties from both their prototype and their parent, facilitating UI use. • This inheritance allowed an app to function as a widget inside another app, enabling dynamic interaction between nested and enclosing apps. • Apps on the Newton persisted their data in object stores called soups, which were accessible by multiple apps. • The concept of co-designing language and UI existed earlier, exemplified by the Boxer system from the 1980s. • Another example of compositionality is Morphic, a graphics system developed in Self and later adapted for Squeak and Lively Kernel, focusing on graphical structure rather than application logic. • Inspired by Morphic, the idea of an app store with composable apps was proposed about twenty years ago. • These apps would live-update, synchronize automatically, and be local-first, a concept predating Apple's app store. • Newspeak language derived partly from this effort. • A practical example of app composition is in travel, where a button for weather lookup could be embedded into an itinerary and dynamically interact with surrounding widgets to display relevant weather information.

Similar problem statement: Ideal OS Also Microsoft OLE comes to mind.

See also the work that Jef Raskin was prevented from doing at Apple that ended up in the doomed Canon Cat system (cf his book 'The Humane Interface')

@Mariano Guerra The summary looks good. How much did you edit it?

removed a couple items and trailing sentences that didn't add much

At the risk of a party foul -- did you mean 'pique' not 'pick'?

@Kartik Agaram probably, not sure about the correct spelling 😄

Yeah just trying to understand what you meant..

should I fix it and make your comment stale? 😛

In my opinion this is the wrong way going about breaking silos. What we need is a separation of data and apps. If data is always examinable (an open binary format), you can have different apps accessing the same data, transforming it and pass to other apps. (Unix philosophy). This data can be live too and versioned. Apps would need to be stateless. Unfortunatly that goes against companies interests, so we can't have nice things. Just look at places where we don't have silos. Like image manipulation, some 3d, email.. and of course text.. there we have a strong standardization of data formats.

Bracha's Newspeak is part of the Smalltalk family. In Smalltalk, there is no data. There are only objects, and the only way to access objects is by "sending messages", which just means calling methods. Put differently: there's no data, only APIs. Data representation/format is alway an implementation detail. This view has its good and bad sides, of course. The main disadvantage is the violation of the Rule of Least Power, because the least-power-notation in this framing is a Turing-complete programming language. One consequence is that interoperability requires agreement on the programming language rather than just on a few data formats.

> "take the hardest and most profound thing you need to do, make it great, and then build every easier thing out of it" -- https://worrydream.com/EarlyHistoryOfSmalltalk Sounds like a philosophical difference with the Rule of Least Power 😂

And that's why smalltalk or object oriented programming in general are a terrible idea. I think they work great in the small to abstract away the insides of say a string. Unfortunatly that was so successfull, that we just ran with it. Now we have input fields, inside boxes and panes inside windows, inside apps, inside companies. And all of this defaults having no access to the data.

That's not what happens in Smalltalk systems. There's a single memory space in which all objects live. No app boundaries. Tying things together into something new is straightforward. With modern UIs, such as Glamorous Toolkit, that's true even for GUI elements. The problem is, of course, that all this harmonious co-existence works only for code written not only in Smalltalk, but in the same Smalltalk variant (there are many). It's the 1970s idea of a single ideal computing system that everyone will adopt because it's "best" that hasn't worked out. And once you need interoperability between systems designed with different priorities, you need weak coupling and the Rule of Least Power (which also has advantages inside something like a Smalltalk image, but that's a different story).

The real issue is encapsulation. The authority of ones data is at the mercy of the object or the app.

The owner of the data is also supposed to be the owner of the object/class. In the Smalltalk philosophy, generic data structures are always an implementation detail. There's always a class specificallly for your application data, and that's a class you own.

Cross-app interoperability is also strong in Android. At least on paper. It relies on sharing objects ("binder objects"), cross-app function calls ("intents") and even embedding foreign 2d surfaces. All of that while maintaining full process separation. I find it very interesting (kind of tragic) that despite the platform solving all of the technical issues, in practice, barely any app makes use of them. Possibly other systems mentioned in this thread suffered the same fate. The only example where cross-app interop actually caught on (that I know) is the POSIX command line ecosystem. My theory is that having the best interop system isn't worth much unless it's also easier and more convenient to use (vs isolated apps).