,
17 tweets,
3 min read
Read on Twitter
Quick thought about OO and message passing. I should probably turn this into a blog post. What if the reason why the original UNIX and #plan9 teams at bell labs never really went OO with their base system was because they already had the best parts of it in a different form?
The UNIX philosophy is to build small tools that do one thing well. The tools themselves weren’t historically written in an OO language. But, a recent quite emerged from Alan Kay indicating that he felt that the best idea in OO was in fact the message passing, not the inheritance
polymorphism, etc. So, while the UNIX tools themselves didn’t use many of those concepts in their code they could pass messages to each other in the form of pipes, files, fifos, etc.
Message passing in this way became even easier with #plan9 because each process can easily set up a filesystem and others can easily mount, bind and send messages via files and the standard filesystem API’s.
So, if a UNIX/Plan9 tool became so complex that there was a need to do message passing, polymorphic or other OO concepts inside it then it may have been considered a bad smell suggesting that it needed to be refactored into separate tools using OS concepts to facilitate.
So, they perhaps never felt much of a burning need to make an OO language as part of the core system.
Meanwhile, consider how relatively difficult other OSes make message passing between program. Windows pipes have terrible problems with buffering and the command line was never a priority until very recently.
Unix and Linux systems don’t have per process namespaces. They have only recently added clunky per user filesystem mount capabilities.
You can use internet sockets to send messages, much like how modern web and micro service architectures work, but there’s quite alot of overhead in the trivial case. You need to allocate and side channel communicate available port number or risk collision. Interface binding.
In this environment, especially in the past, it seems understandable that programmers wanted to pull as much as possible into the same monolithic program so that interactions could be controlled more easily and efficiently. I can completely understand.
Programs became more monolithic and things started to explode. They needed to encapsulate and modularize inside the program itself. Dynamic libraries, classes, methods/message passing started showing up followed by polymorphism and threads. Also, languages that packed this all up
Threads are a great example of how this pressure coming from original lack of OS facilities actually put pressure back on them to support a new concept as a kind of band-aid solution. This is a topic for another time.
And so, programs got bigger and much more unwieldy putting pressure on languages and OSes so that they could support encapsulation and message passing within the monilithic program. This no doubt vastly improved the maintainability and platform independence.
But it also made the average program much more complicated and locked in to a specific language. Languages started duplicating things that were already available in certain OSes, but not in lowest common denominator: namespaces, processes and message passing.
In the worst cases there are actually virtual machines, like Java VM, which duplicate even more of what is in the OS.
The UNIX team quietly made it even easier to write programs in the UNIX way in #plan9. While the rest of the software world seems to have largely reinvented things including OO.
That’s it for now. I hope you enjoyed the ride, or at least it wasn’t scary and weird for you. :)
