If you thought that was entertaining, you'll get a kick out of reading the old UNIX Hater's Handbook.

http://www.vbcf.ac.at/fileadmin/user_upload/BioComp/training...

In particular, at least check out Page 36, showing an articulately hand-drawn Dennis Ritchie, in stoic defiance, blowing raspberries at UNIX critics through his thick-rimmed glasses. It's by far the high point of the book.

The nice part about the Unix Haters book is that the authors were actually familiar with their subject material :-).

The funny thing about gcr's comment is that I posted ESR's review of UNIX Hater's Handbook here before. He agreed with a good chunk of it while noting other stuff changed or was ranting. As for your comment, I came to C after using alternative, system languages that compiled faster, crashed less, and ran fast. After I figured out basics of C & read secure coding books, I said "F#$@ this!" It was an unnecessary and horrible development experience. So, I coded up a 4GL that let me develop in industrial BASIC that compiled to C apps with checks in to use their compilers and libraries. Macro'd out boilerplate. People thought my "C code" was fast and thorough but I never wrote in that garbage language except prototyping the tool. (Long gone so don't ask.) My application areas were OS-level stuff, games, AI, networked apps, and GUI apps. Shows how easy it would've been to ditch given I sucked at compiler design.

Eventually, I discovered how it was created, that most proponents claims weren't accurate depiction, and did this write-up. Glad you enjoyed that I kept it close to subject material from its inventors. Meanwhile, the C inventors went onto design, with Pike's help, a better language that solves most of C's problems while maintaining a Wirth-like level of safety and development. Pick up Go language if you want to know what that experience is like. Personally, I'm more for a subset of Modula-3 with Rust's dynamic safety, SPARK Ada's extensions for correctness, and macro's for DSL, productivity benefits. Or efficient functional one with similar properties.

Much of it is, because they had to squeeze big concepts like those from Multics into very small minicomputers. I don't know how much memory they had on their PDP-7, but for the original PDP-11 it would have been 64K each for data and instructions, with some of that almost certainly taken for the memory mapped hardware (one of the 11's innovations). The PDP-11/45 allowed a user program the same, with 8K taken from normal data space for the stack.

Unix may be fine by 1960s/1970s standards, but leaves a lot to be desired now, or probably since the 1980s. Unix has bad approaches to things like file locking (see VMS instead), the shells are a hot mess, and C causes a lot of problems. Even the Unix developers themselves went on to work on Plan 9.