People use C not because they like it, but because its the lingua franca [1]. As long as The Unix Programming Environment [2] remains dominant, The C Programming Language [3] will too.

1. https://humprog.org/~stephen/research/papers/kell17some-prep...

2. https://amazon.com/dp/013937681X

3. https://amazon.com/dp/0131103628

"On the criteria to be used in decomposing systems into modules" (1972) - because the core principles of modularity haven't changed [https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria...]

"The Mythical Man Month" (1975) - because human nature hasn't changed [https://www.amazon.com/Mythical-Man-Month-Software-Engineeri...]

"The History of Fortran I, II, and III" (1979) - because this historical piece by the author of the first high level language brings home the core principles of language design [https://archive.org/details/history-of-fortran]

"The Unix Programming Environment" (1984) - because the core basics of the command line haven't changed [https://www.amazon.com/Unix-Programming-Environment-Prentice...]

"Reflections on Trusting Trust" (1984) - because the basic concepts of software security haven't changed [https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...]

"The Rise of Worse is Better" (1991) - because many of the tradeoffs to be made when designing systems haven't changed [https://www.jwz.org/doc/worse-is-better.html]

"The Art of Doing Science and Engineering: Learning to learn" (1996) - because the core principles that drive innovation haven't changed [https://www.youtube.com/playlist?list=PL2FF649D0C4407B30] [https://www.amazon.com/Art-Doing-Science-Engineering-Learnin...]

"xv6" (an x86 version of Lion's Commentary, 1996) - because core OS concepts haven't changed [https://pdos.csail.mit.edu/6.828/2011/xv6/xv6-rev6.pdf] [https://pdos.csail.mit.edu/6.828/2014/xv6/book-rev8.pdf]

I found it very interesting for being one of the very few books that deals with code as a formal system.

You don't need to understand the code; you don't need to step through the code. You follow the steps for "extract method" and you go from a working state to another working state with no worries.

The individual refactorings are more-or-less interesting, but as others have said, they're somewhat commonplace now.

Two books that every programmer should read: Software Tools[1] and The Elements of Programming Style[2] by Kernighan and Plauger. Bonus: The Unix Programming Environment[3] by Kernighan and Pike.

[1] https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan...

[2] https://www.amazon.com/Elements-Programming-Style-2nd/dp/007...

[3] https://www.amazon.com/Unix-Programming-Environment-Prentice...

If you consider C to be language-agnostic, here are some gems. These are personal favorites as much for their excellent writing as for their content.

The Unix Programming Environment was published in 1984. I read it over 20 years later and was astonished at how well it had aged. For a technical book from the 80's, it is amazingly lucid and well-written. It pre-dates modern unix, so things have changed but much that goes unstated in newer books (for brevity) is explicit in UPE. (Plus, the history itself is illuminating.) It gave me a much deeper understanding of how programs actually run over computer hardware. Examples in C are old-school and take a bit of close reading but oh so rewarding. https://www.amazon.com/Unix-Programming-Environment-Prentice...

Mastering Algorithms in C. Another fantastically well-written book that shows (with practical examples) how to implement common algorithms. This is just such a great book! https://www.amazon.com/Mastering-Algorithms-Techniques-Sorti...

Also:

Code (Petzold). This one is truly language-agnostic. Others have mentioned it already. Can't recommend enough if you're iffy on the internals of computers and programming. https://www.amazon.com/Code-Language-Computer-Hardware-Softw...

Write Great Code (Volumes I and II). Randall Hyde's books are fantastic explications of the underlying computer operations. Examples are in assembly or pseudo-code but easy to understand. https://www.amazon.com/Write-Great-Code-Understanding-Machin...

I remember The Unix Programming Environment by Kernighan and Pike as an excellent introduction to Unix shells and general Unix programming. IIRC, throughout the chapters, it has you build some kind of interactive command line music organizer, which really demonstrates how much you can get done with a few simple shell scripts.

Amazon link:

https://www.amazon.com/Unix-Programming-Environment-Prentice...

I find that to be the issue. You are considering it just RAW text when it is actually formatted text that has been parsable for years with common unix command line tools. It not being in the format you consider a structured object does not mean it's not a object or even parsable. If you are using ad hoc regex I suspect you are not using all the tools available to you.

I feel like Kernighan and Pike do a much better job of explaining than I could ever.

https://www.amazon.com/Unix-Programming-Environment-Prentice...

Reposting an earlier comment of mine https://news.ycombinator.com/item?id=6530180 with context https://news.ycombinator.com/item?id=6526412 :

> pjmlp 211 days ago | link | parent | flag

> Nice article, but it fails to explain the experience using Smalltalk environment really is. Smalltalk, like Lisp Machines, was originally a blend of GUI operating system, development environment and the first real IDE.

> agumonkey 211 days ago | link

> It's funny. Unix was also meant as an IDE (persistency, logic, machine and user interfaces). It seems they all were trying to reach the same goal in their own way. -----

> 2 points by leoc 210 days ago | link

> The fact that dc was originally intended as basically the Unix system's bignums library http://www.catb.org/esr/writings/taoup/html/ch08s02.html#id2.... helped to open my eyes to this. I think you could talk about this idea of Unix as "big Unix" and the narrower understanding of Unix programming, dominated by the C APIs, as "little Unix". Little Unix took over the world, while big Unix collapsed under its own weight due to things like portability/versioning hell, robustness problems due to faulty tools and text-parsing errors, performance issues and so on. (Partly this was a success catastrophe, of course, for example in how the popularity of Unix resulted in a profusion of different Unix userlands with varying interfaces and bugs.) Also little Unix was more comprehensible from, and more portable to and from, the world of PC (MS-DOS/Windows/Mac) application development, where the environment is more or less the kernel's/OS vendor's APIs. The fact that clearly many more people have bought or read K&R http://www.amazon.com/dp/0131103628/ (with its very little-Unix perspective) than /The Unix Programming Environment/ http://www.amazon.com/dp/013937681X reflects this divergence, and also surely helped to create it.

It is actively harmful to teach students that software architecture is something that somehow arises from diagrams or that those kinds of silly pictures capture anything important about it. Powerful architectures come out of powerful ideas that in turn come from accumulated hard work of many people in different disciplines. One can learn much more from walking through the actual source code of some classic projects and from trying to understand the ideas that make them tick:

https://github.com/onetrueawk/awk - UNIX philosophy of small tools, DSLs, CS theory: state machines / regular expressions, Thompson algorithm ...

https://github.com/mirrors/emacs - Both a program and a VM for a programming language, hooks, before/after/around advices, modes, asynchronous processing with callbacks, ... Worth to think of challenges of designing interactive programs for extensibility.

https://github.com/rails/rails - Metaprogramming DSLs for creating powerful libraries, again a lesson in hooks (before_save etc.), advices (around_filter etc.), ...

https://github.com/git/git - The distributed paradigm, lots of CS theory again: hashing for ensuring consistency, DAGs everywhere, ... By the way, the sentence "yet the underlying git magic sometimes resulted in frustration with the students" is hilarious in the context of a "software architecture" course.

One of computer algebra systems - the idea of a http://en.wikipedia.org/wiki/Canonical_form

One of computer graphics engines - Linear algebra

...

There are loads of things one can learn from those projects by studying the source in some depth, but I can't think of any valuable things one could learn by just drawing pictures of the modules and connecting them with arrows. There are also several great books that explore real software design issues and not that kind of pretentious BS, they all come from acknowledged all-time master software "architects", yet all of them almost never find diagrams or "viewpoints" useful for saying the things they want to say, and they all walk you through real issues in real programs:

http://www.amazon.com/Programming-Addison-Wesley-Professiona...

http://www.amazon.com/Paradigms-Artificial-Intelligence-Prog...

http://www.amazon.com/Structure-Interpretation-Computer-Prog...

http://www.amazon.com/Unix-Programming-Environment-Prentice-...

http://www.amazon.com/Programming-Environment-Addison-Wesley...

To me, the kind of approach pictured in the post, seems like copying methods from electrical or civil engineering to appear more "serious", without giving due consideration to whether they really are helpful for anything for real-world software engineering or not. The "software engineering" class which taught those kind of diagram-drawing was about the only university class I did not ever get any use from, in fact I had enough industry experience by the point I took it that it just looked silly.

The fact that dc was originally intended as basically the Unix system's bignums library http://www.catb.org/esr/writings/taoup/html/ch08s02.html#id2... helped to open my eyes to this. I think you could talk about this idea of Unix as "big Unix" and the narrower understanding of Unix programming, dominated by the C APIs, as "little Unix".

Little Unix took over the world, while big Unix collapsed under its own weight due to things like portability/versioning hell, robustness problems due to faulty tools and text-parsing errors, performance issues and so on. (Partly this was a success catastrophe, of course, for example in how the popularity of Unix resulted in a profusion of different Unix userlands with varying interfaces and bugs.) Also little Unix was more comprehensible from, and more portable to and from, the world of PC (MS-DOS/Windows/Mac) application development, where the environment is more or less the kernel's/OS vendor's APIs. The fact that clearly many more people have bought or read K&R http://www.amazon.com/dp/0131103628/ (with its very little-Unix perspective) than /The Unix Programming Environment/ http://www.amazon.com/dp/013937681X reflects this divergence, and also surely helped to create it.