OOP is a convenient tool for cutting your state into smaller, independent pieces. But that can only go as far as the pieces can be independent, what for most practical domains is not very much. It also does not bring any other big benefit bundled with it, what looks to me like the EDJ complaint is all about.
Hmm..."OO may be a decent way of managing complexity..." was what the parent said, I responded to the "complex baseline" assertion. And your assertion that it doesn't help is empirically invalidated on many counts.
First, the folks at Xerox PARC managed to implement "Personal Computing (networked)" in around 20KLOC of Smalltalk, including the OS, windowing system, IDE, networking, e-mail, messaging etc. Second, look at the sheer amount of functionality in something like Squeak.
> at least not as much as a powerful FP language.
Citation needed? Caper Jones Function Point Metric puts Smalltalk's language level at 20, Haskell at 8.5 (larger=better)
QNX kernel = 23 KLOC, C [1]
Plan9 kernel = 50 KLOC, C [2]
Squeak VM = 9 KLOC, Smalltalk [3] (Squeak is a Smalltalk)
For clarity, I'm a bit out of my depth here, and I'm assuming that the Squeak VM is a bit akin to a kernel. And surely one could find more authoritative references for it all.
[1] http://www.gelato.unsw.edu.au/IA64wiki/JamieLennox/QNXvL4?ac...
[2] https://news.ycombinator.com/item?id=879101
[3] https://books.google.com.au/books?id=FM-pCAAAQBAJ&pg=PA136&l...
- the kernel/OS
- the windowing GUI
- the programming language, compiler, libraries
- the visual IDE
- Networking
- E-Mail/Chat
- ...
I am not sure DTP/Word Processing was also included, it might have been a separate system.
Now I am a huge fan of QNX, used it and developed for it a bit in the 90s, but the version that fit on a floppy didn't cover anywhere near as much. Also, QNX is built on a message passing kernel...hmm...
You also left out Amiga Exec + Intuition, which is also amazingly compact and was built in C...but using OO concepts, which are implementable in C. For example, everything in the kernel is a List, and so specific concepts like ports effectively subclass List (with function tables etc.) See also: Objective-C.
Plan 9 is also very, very cool, and its "everything is a file" (no really, everything) is not that dissimilar to everything is an object. Part of my own work[1] is trying to find the common ground between these two approaches, with a good amount of success.
Anyway, the Plan 9 distribution is 1.5 million lines of code. The Acme text editor and cc compiler alone sum to 20KLOC. libdraw is another 5KLOC etc.
So Plan 9 is good, Smalltalk is arguably better, but I think we can (and have to) do better still, see VPRI[2].
Coming back to Brooks for a second: in NSB, he saw OO as one of the few hopes for tackling the problem, and in an OOPSLA panel 20 years later he opined that it had largely succeeded[3].
That said, I agree with your take that software tends to be much, much more complicated than it has any need or rights to be. I attribute much of this to architectural mismatch[4], particularly in the domain of UI-intensive systems[5]
For example, much of the complexity of UI programs can be removed by modeling them using high-level dataflow constraints[6], combined with compositional storage.
Dataflow also seems to be a very powerful reduction factor, Unix pipes/filters still rule (see Doug McIllroy's response to Bentley's challenge), and Dan Amelang's Nile/Gezira does a modern 2 1/2D compositing graphics subsystem in ~500 lines of dataflow code[7]
[3] https://www.researchgate.net/publication/221321794_No_silver...
[4] http://www.cs.cmu.edu/afs/cs.cmu.edu/project/able/www/paper_...
[5] http://dl.ifip.org/db/conf/ehci/ehci2007/Chatty07.pdf
[6] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...