The Unix Binary wants to be a Smalltalk Method, Not an Object by @jdjakub. A bit lengthy, but has interesting insights.

@Stefan check out this amazing post.

I do recommend taking a look at "Android's App Architecture" since it seems to merge both models successfully. Distinct Unix processes can hold references and pass messages to individual objects within each other's memory. They even maintain proper reference counts for GC. And each app's state is fully serializable. Then there is Java's hot reload for live app updates. Users don't have access to those mechanisms only because nobody bothered to build a UI yet. But the smalltalk-style OO/Unix OS not only already exists but is the most popular one out there.

@Kartik Agaram Right, that one is interesting as well! But it misses a discussion of the reasons why these commitments are so widespread: (1) they create affordances in the form of readily usable tools and (2) they permit the large-scale coordination of development, and thus interoperable software. If you are willing to give up both of these, nothing prevents you from writing your own software system from scratch, starting with a UEFI boot loader. The only commitments that still constrain you is byte-structured memory and the processor's instruction set.

I’ve felt that Smalltalk’s greatest failing, was not allowing (AFAIK) for its own applications to have the kind of encapsulation that Unix binaries have. I can understand how this might have been a necessity of the limited memories of early machines, but it seems strange that this was never questioned (again, AFAIK) as memory sizes grew well beyond the limits that would prevent it.

I suppose that it was never questioned because the very idea of an encapsulated binary goes against the values of early and modern Smalltalkers. There is still the dream of a complete software system that its user can fully understand, even though that is less and less reasonable with the complexity of today's Smalltalk images.

I kinda agree with this article and I kinda disagree with it. The article doesn't address what I think is a very key issue - the transport mechanism for "message sending". Two Key Concepts in Programming

@Konrad Hinsen I think it could still be a complete and understandable system. I didn’t mean to imply that “binaries” were needed. Just encapsulation of processes by one means or another such that they can’t easily step on one another’s toes, as that makes for a fragile system.

@Steve Dekorte OK, formulated that way I agree!