OO as the idea of late bound, dynamically dispatched objects that receive messages, retain state, maintain access and location transparency and optionally delegate to other objects... that's not really controversial, but also rarely done. Nevertheless, most great research operating systems have been object-oriented, and this is no coincidence.
This is the most controversial part of it. I've got no problems with classes, objects, imperative methods, dynamic dispatch and all that - these are just semantic building blocks, sometimes useful.
What is really damaging is this very notion of representing the real world problems in their infinitely diverse complexity as something so primitive and narrow as communicating objects.
They're not primitive and narrow, that's the point. They're blobs of state that can masquerade under any interface - files, devices, windows or whatnot, all while having a common primacy so they are easily introspected, cloned and extended. In the Spring OS, for instance, you have the ability to compose or create entirely new names from existing primitives like environment variables, sockets, files, etc. by operations equivalent to set manipulation.
> that can masquerade under any interface - files, devices, windows or whatnot
Why are you sledgehammering all these entities into this primitive and narrow way of thinking in the first place?
They are different. And in order for different entities to have some common properties you don't have to think of them as a hierarchical relation of communicating objects.
Treat them too differently without any uniformity, and you get a hodge-podge system of names that can barely interact.
An object here is just a blob of state that enforces a primal uniformity. Files still look, walk and quack like files, they're just represented under a common construct underneath which is immensely useful for the programmer and irrelevant to the end user.
OO is not the only robust way of representing uniform interfaces. OO preachers must stop claiming ownership of the concepts that existed long before OO, and are much better represented outside of thr OO blindfolded way of thinking.
I'm not an OO preacher, I'm just making the observation that most research systems designed for uniformity were object-oriented. Otherwise when it comes to languages, I currently mostly use ones based on functions and pattern matching.
You can't really speak of the "OO blindfolded way of thinking" when all you do is contradict without any substance.
Unix is fairly uniform, and not object-oriented. Plan9 is even more uniform and still not object-oriented. Lisp machines did not feature too much of an OO neither, and yet had a very unified interface to all the OS entities.
Other than that, OS research is nearly dead anyway, nothing interesting happens, besides probably Singularity, which is also not very OO - it does not play well alongside with static analysis anyway.
Compared to Windows, maybe, but in the grand scheme of things it is not. Hence so many research systems like Amoeba, Spring, Sprite, SPIN and even GNU Hurd that tried to create a general overarching metaphor across Unix's not-quite-uniformity.
Plan9 is even more uniform and still not object-oriented.
9P is a transport-agnostic object protocol for representing resources as synthetic file systems. The trick many have with Plan 9 is that they import their prior knowledge of what a "file" is, but in reality Plan 9's concept of a file is quite different from other systems. This is right down to the Plan 9 kernel being a multiplexer for I/O over 9P.
Either way, my point is the "object" metaphor isn't really all that specific. Personally I'd love to see work on functional operating systems, but other than the boring House system, I don't think there's been that many.
> Either way, my point is the "object" metaphor isn't really all that specific
I still don't see how Plan9 is built on "objects".
> functional operating systems
I doubt functional metaphors are of any use in this domain.
My point is that the abstraction continuum is far more diverse and deep than something as stupid as communicating objects or reducing lambda terms. My bet is on a linguistic abstraction, which covers interface unification as well as many other things.
OO as the idea of late bound, dynamically dispatched objects that receive messages, retain state, maintain access and location transparency and optionally delegate to other objects... that's not really controversial, but also rarely done. Nevertheless, most great research operating systems have been object-oriented, and this is no coincidence.