What about Acme's architecture?
> Acme is about 8,000 lines of code in Alef, a concurrent object-oriented language syntactically similar to C [Alef]. Acme’s structure is a set of communicating processes in a single address space. One subset of the processes drives the display and user interface, maintaining the windows; other processes forward mouse and keyboard activity and implement the file server interface for external programs. The language and design worked out well; as explained elsewhere [Pike89, Gans93, Reppy93], user interfaces built with concurrent systems can avoid the clumsy top-level event loop typical of traditional interactive systems.
That does not sound like Unix philosophy. Communicating processes in a single address space application. On Plan 9. Written by Rob Pike at Bell Labs.
We've seen companies like SUN, IBM, HP, DEC/Compaq/whatever they are called now/..., etc. earning zillions on big fat applications. Big fat GUI applications and big fat server applications.
From any Oracle DB, to any Java application, to basically every desktop application - none follows the so-called 'UNIX philosophy'. Thus tools like GNU Emacs have zillions of similar applications under UNIX and GNU Emacs is nothing special at all.
Plan 9 is more Unix than Unix. First, Acme is no longer written in Alef, but in C (on Plan 9) or Limbo (for Inferno). Second, I don't think you understand how Acme works; try reading the Acme paper or watching Russ Cox's introductory screencast.
I would argue that the original developers of Unix over at Bell Labs were horrified at X and the "monolithic" applications that were being developed for Unix.
So much so that they wrote an entirely new operating system, Plan 9 that pushed composability to a new level and also included its own windowing system called 8½ (which was rewritten later as Rio).
Rob Pike had this to say about 8½ [2]:
> The entire system, including the default program that runs in the window — the equivalent of xterm pasting between windows — is well under 90 kilobytes of text on a Motorola 68020 processor, about half the size of the operating system kernel that supports it and a tenth the size of the X server without xterm... The small size of 8½ does not reflect reduced functionality: 8½ provides service roughly equivalent to the X window system. 8½’s clients may of course be as complex as they choose, although the tendency to mimic 8½’s design and the clean programming interface means they are not nearly as bloated as X.
[1] https://en.wikipedia.org/wiki/Unix_philosophy [2] http://doc.cat-v.org/plan_9/4th_edition/papers/812/