nile

n 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