Found in 8 comments on Hacker News
chubot · 2021-04-03 · Original thread
Shouldn't scripts over 100 lines be rewritten in Python or Ruby?

tl;dr I think the main skill that is missing is being able to write a Python script that fits well within a shell script. The shell script often invokes tools written in other languages like C, Rust, JavaScript, etc. (most of which you didn't write)

Good book on this:

Online for free:

chubot · 2020-12-05 · Original thread
Turns out, nothing substantial had been published since the 1980s.

The best reference I've found on this is The Art of Unix Programming, which was published in 2003:

The book is also online for free:

Command Line Options:

User Interface Design Patterns:

Still it's nice to see this knowledge circulating!

Joel Spolsky's 2003 review of this book:

chubot · 2020-10-24 · Original thread
(author here) I do use Python. In fact I wrote something like 30K lines of Python for Oil.

The question isn't shell OR Python.

My shell scripts call Python scripts, many of white I wrote myself. That is working as intended.

They also call C programs, C++ programs and R programs. And put JavaScript programs in various places.


I guess this is a huge misconception about shell that I have to write a blog post about.

I'm often asked this about Oil [1]: Why do you want to write programs in shell?

That's not the idea of shell. The idea is that I write programs in Python, JavaScript, R, and C++ regularly, and about 10 different DSLs (SQL, HTML, etc.) And I work on systems written by others, consisting of even more languages.

I need a language to glue them together. A language to express build automation and describe deployed systems. Most big systems consist of more than one language.

Shell is the best language for that, but it's also old and crufty, with poor implementations.

When you program in shell, gcc, git, pip, npm, markdown, rsync, diff, perf, strace, etc. are part of your "standard library".


If you want some concrete examples, look in the Oil repo. There are dozens of shell scripts that invoke custom tools in Python, R, and C++.

For example, to generate this report on how much we speed up Python by translating it to C++:

The tables are manipulated by R code, and shell/Python/CommonMark generates the HTML.


Another example is that the release page is essentially a huge shell script:

This page and all the linked pages are generated by:


If you don't understand why shell should call Python and C, I recommend reading The Art of Unix Programming

devlife · 2019-02-11 · Original thread
The art of Unix Programming

My first reading of this book convinced me to move away from Windows. I usually read it at-least once a year.

W0lf · 2017-06-05 · Original thread
I've gathered all the book titles in this thread and created Amazon affiliate links (if you don't mind. Otherwise you still have all the titles together :-) )

A Pattern Language, Alexander and Ishikawa and Silverstein

Advanced Programming in the Unix Environment , Stevens

Algorithmics: the Spirit of Computing, Harel

Applied Crytography, Wiley

Clean Code, Martin

Clean Coder, Martin

Code Complete, McConnel

Code: The Hidden Language of Computer Hardware and Software, Petzold

Coders at Work, Seibel

Compilers: Principles, Techniques, & Tools, Aho

Computer Systems: A Programmer's Perspective, O'Hallaron and Bryant

Data Flow Analysis: Theory and Practice, Khedker

Dependency Injection in .NET, Seemann

Domain Driven Design, Evans

Fundamentals of Wireless Communication, Tse and Viswanath

Genetic Programming: An Intrduction, Banzhaf

Head First Design Patterns, O'Reilly

Implementing Domain-Driven Design, Vernon

Intrduction to Algorithms, CLRS

Introduction to General Systems Thinking, Weinberg

Joy of Clojure, Fogus and Houser

Let over Lambda, Hoyte

Operating Systems: Design and Implementation, Tanenbaum

Parsing Techniques, Grune and Jacobs

Peopleware: Productive Projects and Teams, DeMarco and Lister

Programming Pearls, Bentley

Software Process Design: Out of the Tar Pit, McGraw-Hill

Software Runaways, Glass

Sorting and Searching, Knuth

Structure and Interpretation of Computer Programs, Abelson and Sussman

The Art of Unit Testing, Manning

The Art of Unix Programming, ESR

The Design of Design: Essays from a Computer Scientist, Brooks

The Effective Engineer, Lau

The Elements of Style, Strunk and White

The Healthy Programmer, Kutner

The Linux Programming Interface, Kerrisk

The Mythical Man-Month, Brooks

The Practice of Programming, Kernighan and Pike

The Pragmatic Programmer, Hunt and Thomas

The Psychology of Computer Programming, Weinberg

Transaction Processing: Concepts and Techniques, Gray and Reuter

Types and Programming Languages, Pierce

Understanding MySQL Internals, Pachev

Working Effectively with Legacy Code, Feathers

Zen of graphics programming, Abrash

tapan_k · 2016-06-09 · Original thread
Here's one from the book The Art of UNIX Programming[0]: "The Unix philosophy is bottom-up and not top-down. It is pragmatic and grounded in experience."


DonHopkins · 2014-04-19 · Original thread

3.0 out of 5 stars Autohagiography with some programming tips, December 24, 2003 By A Customer

The writing style of this book tends to hurt the reading experience, as Raymond trumpets his own minor achievments in the free software community. The work feels like it needed one more rewrite before being released to the public: some related sources Raymond hadn't yet read at the time of writing, and some of his advice gets repetitive.

The exposition itself is not up to par with The Elements of Programming Style. Raymond tries to give a list of programming rules or principles to follow, but it reads more like a list of slogans that should be taken as axioms. While The Elements of Programming Style itself had a list of rules, the rules were well woven with each other, well defended, and they were used as a means of conveying a larger story. In Raymond's case, he relies upon the slogans in absence of such a story.

Thus, the book ends up more like a list of random unrelated tips. Some very profound, like his writings on threads (which he acknowleges Mark M. Miller for his help). Others are very shallow and pointless in a book that supposes to call itself about "Art." Some of the pieces appear only to function to attack Windows, and sometimes the information about Windows is embarassingly inaccurate.

One final criticism is that Raymond does not understand object-oriented programming very well and misses the point in several cases. You just need to see the popularity of Python, Java, C# (Mono), OO Perl and C++ in the Linux world to see that Raymond is off base calling OO a failed experiment. In fact, with almost any matter of opinion in the book you can feel Raymond's bias and be hit in the face with misinformation or dull false dilemmas.

However, given this book's many flaws, I rate this 3 stars instead of 2 stars because it also has valuable information from the many contributors, some of them Gods in the Unix world. These contributors often even disagree with Raymond, or point out other interesting tidbits. For these tips alone, it is worth checking out this book, though I would not recommend you buy it.

To get the true Unix programming philosophy, I recommend Software Tools, by Kernighan and Plauger. It's somewhat dated, and I recommend the Ratfor version of it, but that single book has became very influencial as I grow as a Unix programmer.


One of the problems with this book is the overly partisan tone it takes - one gets the impression that absolutely nothing Microsoft has ever done is of value, but the other major desktop PC OSes (Apple, Linux) represent different forms of perfection. (At home, I run Mac OSX, RedHat Linux and Windows, and have a reasonable sense of their relative strengths and weaknesses.)

So, be warned: Art of Unix Programming paints a one sided picture. The author is a well-known figure in the open source community, one of its fiercest advocates, and one of Microsoft's most vocal critics, so it might seem to strange to wish for less anti-Microsoft spin from this source. After all, the Raymond brand certainly carries with it an obligatory expectation of Windows-bashing, doesn't it?

One of the only Windows design decision which Raymond doesn't condemn is the (now discontinued) .ini file format. Even the thorough-going support for object-orientation in Windows is given short-shrift: after explaining the many horrors of object-oriented programming (according to Raymond), Unix-programmers are praised as "tend[ing] to share an instinctive sense of these problems." This section ([...]) is particularly illustrative of the one-sided approach that Raymond takes.


His comments about the Windows registry were a bit distressing, though -- not because they're negative, which I consider fine. Rather, it was obvious he'd never used it (comments like "there's no API for it") and it was also clear that he hadn't even bothered to research why it existed and what problems it was intended to solve. The comments were typical of what I'd expect of a Slashdot troll, but not of a bright, respectable person like ESR. I've programmed on both platforms extensively and only comment on what I have first-hand experience and knowledge of; I'd expect him to do the no less, especially as an author.

It was also curious that several times he implied unit testing == XP == agile software development. For as tuned in as he seems to be to methodolgy work, missing the forest for a single leaf is a bit embarrassing.


Hate to be the one to burst the proverbial bubble..., March 13, 2004 By Bill Joy (Hamburg, DE)

...but ESR's theory and ideology is rediculously flawed with misappropriated valuations. This is, yet another advocacy campaign for gnu/Linux, mixed in with a UNIX context. Given the purpose of the book, it's a fair assessment to label the burdening bias as filler and firewood: filler for those who really just wanted an explanation of the single-purpose, POSIX illustrated, hows and whys of UNIX programming philosophy; and firewood for those who tend to buy into slanderous hype at the whim of suggestion.

Questions: What is the title of the book? What programmatic philosophies are portrayed? How many unices are open source? Of those, how many subscribe to the same opensource mentality as gnu/Linux? Answer: zilch. Question: Then what is the relevance of such topics to the objectives of the book, as depicted in the title? Answer: fudd-ala-mode.

Aside from these intertwined distractions, and a severe Napoleonic complex against anything new or different, ESR does adequately represent the real purpose of the book, and in those efforts place value in the read.


an interesting and often annoying read..., June 1, 2004 By A Customer

I suppose any book containing so many interesting quotes from so many UNIX luminaries cannot be overlooked. (I wonder if any of them would have co-authored this) It also happens to contain a great many topics that are well-worth writing about; My only wish is that someone less in awe with the contents of his own field of vision, and with greater depth and objectivity (not to mention humility) had the opportunity to write this book.

Quality of discussion is varied as expected; Raymond is not quite the UNIX expert he thinks he is. In places, Raymond's tone encourages one to throw the book at the nearest wall and go out just to get some fresh air; He is condescending, hectoring, lecturing, and sometimes just misleading. Alas, I will still recommend it as worth reading (check your local library) with a nice grain of salt; just enough friction for thought is provided in this edition.


programming book without any code, May 11, 2013 By davez (LA, CA, United States)

If you expect to see any code, you'll be disappointed. The author gives ample examples, but mostly preaching the Unix philosophy or religion, at many times repeating the similar points. 500 pages are a little long for a book of this kind. Having read other Unix books, I've heard many of the stories retold here, but still learned a few new things. It reenforces many notions of Unix.

This is a book that I would recommend to someone new to Unix, but it is not a book that I would keep. After 10 years, the computing landscape has changed with the rise of the mobile computing and cloud computing; the Unix has evolved to support smart phones and tablets, in which the user interface has become essential.

stiff · 2014-01-03 · Original thread
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: - UNIX philosophy of small tools, DSLs, CS theory: state machines / regular expressions, Thompson algorithm ... - 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. - Metaprogramming DSLs for creating powerful libraries, again a lesson in hooks (before_save etc.), advices (around_filter etc.), ... - 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

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:

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.

Fresh book recommendations delivered straight to your inbox every Thursday.