The actual fundamental question is this: why is composability* so poor in our current languages/technologies?
I agree that this is a very interesting take on the problem. While I could speculate a lot on the actual "why"s of how our composability has regressed over the past decades, I don't think it'd wind up being productive :-)
What I'm personally more interested in is how we recapture the ideas of live-swapping code, of building systems that can talk to arbitrary other systems sans the stupidity of most of the "universal protocol" attempts that have been made in the past, and so on.
OK, fuck it, I'm gonna speculate a tiny bit. I think the proliferation of languages without clean ABIs (C++, cough) and the erosion of clean platform-level composablility features (like Unix espouses, and Windows doesn't) is a big part of the problem.
Ah! Unix espouses a text-level composability in the userspace. Windows espoused an object-level composability at the API level (multiple times, from Win32 to OLE to .NET/PowerShell). Both require that applications on both ends of the communication pipe adhere to protocols in order to exchange data, but the Windows protocols are more complex because they are more complete. That complexity came at the cost of integration being more difficult, resulting in lower adoption, undermining the whole process. But don't forget that Unix's userspace text-level composability is brittle! If both ends don't expect exactly the same things in exactly the same order, then you have to interpose a utility like sed or awk to transform them…
It gets complicated quite quickly.
Here's why I say that: if you're running Smalltalk, you're an end-to-end Smalltalk system. You can compose arbitrarily because the whole system is self-contained and pieces you get from other sources use the same basic mechanisms to interact with each other. Same goes for the Unix philosophy of textual communication via piping; if the entire platform believes in the compositional abstraction, it works great. If it doesn't, you get PowerShell.
Contrast that with my current workstation: I run programs and scripts written in PowerShell, Python, Ruby, C, C++, C#, and probably a handful more. Aside from the C ABI, there's no clean way for all those to interact, and the C ABI is not first-class in many of those languages.
This leads to attempts at a lingua franca of code, which usually wind up looking like SOAP or something equally obnoxious.
So ever being the stubborn pragmatist: how do we move on from this situation?
The protocols and abstractions necessary for composition must be built right into the operating system layer, to the point that the application silo is completely discarded. Really, such a system has only two applications, or application "modes": composition and presentation. The composer has the inherent ability to display and edit text, images, video, audio and a timeline and/or event graph for interactivity. All "applications" are then specifications for how to combine those elements, and instructions for de/serialization.
Yeah, the fix is to move the Smalltalk layer right into the OS.
Also, really good to see you again, Seyi!
Thanks! Good to see you, too, Mike!
(Sorry to everyone else for drifting so far afield of the topic!)