As far as I’m concerned, OO is a mental model for how to handle any noun. Linux is a good example for OOP, in that, “Everything is a file.” Linux does this amazingly well; even interfaces that read data from USB ports are “files.”
However, this comes with some limitations. Kernel threads are not very accessible. If you tried to set up a single operating system over multiple computers, you would need some very severe modifications to Linux, and the implementation would likely have many sharp corners to snag on. (Where is this file? What hardware “owns/runs” it? How does Computer 2’s hardware take over, or modify a value currently in Computer 1’s CPU? Etc. As a side note, last I checked, the most common method of distributed computation with Linux is to install an OS on each computer, and have them report to a master or scheduling computer. Which, while functional, is reliant on separate components functioning on their own, independently of the scheduler.)
I’m stepping well out of my wheelhouse to give a contrasting example. Please be gentle with corrections. Kubernetes, designed to handle multiple pieces of hardware, is written decoratively declaratively without OOP, I believe. Each piece of hardware becomes a node run by a control plane, which is much the same thing as an OS, but lighter, with less capabilities and independence. (?)
This is not to say you can’t do the same thing with a custom Linux distro, but using an entirely OO pattern will create sharper corners.
Each paradigm has its own strengths and use-cases; and each their own weaknesses and limitations.
Please forgive the meandering reply.
As far as I’m concerned, OO is a mental model for how to handle any noun. Linux is a good example for OOP, in that, “Everything is a file.” Linux does this amazingly well; even interfaces that read data from USB ports are “files.”
However, this comes with some limitations. Kernel threads are not very accessible. If you tried to set up a single operating system over multiple computers, you would need some very severe modifications to Linux, and the implementation would likely have many sharp corners to snag on. (Where is this file? What hardware “owns/runs” it? How does Computer 2’s hardware take over, or modify a value currently in Computer 1’s CPU? Etc. As a side note, last I checked, the most common method of distributed computation with Linux is to install an OS on each computer, and have them report to a master or scheduling computer. Which, while functional, is reliant on separate components functioning on their own, independently of the scheduler.)
I’m stepping well out of my wheelhouse to give a contrasting example. Please be gentle with corrections. Kubernetes, designed to handle multiple pieces of hardware, is written
decorativelydeclaratively without OOP, I believe. Each piece of hardware becomes a node run by a control plane, which is much the same thing as an OS, but lighter, with less capabilities and independence. (?)This is not to say you can’t do the same thing with a custom Linux distro, but using an entirely OO pattern will create sharper corners.
Each paradigm has its own strengths and use-cases; and each their own weaknesses and limitations.