The ~20KLOC of Xerox PARC was the entire system, not just the kernel, and included, among other things:
- 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]
[1] http://objective.st
[2] http://www.vpri.org
[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...
[7] https://github.com/damelang/nile
- 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]
[1] http://objective.st
[2] http://www.vpri.org
[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...
[7] https://github.com/damelang/nile