More shell, less egg (2011)
leancrew.com
leancrew.com
Another fun example: a common sentiment of distrusting comments and documentation. The title of https://martinfowler.com/bliki/CodeAsDocumentation.html reads as an antithesis to literate programming. Of course the reality is that most (but not all) code is so mundane that if it needs additional comments, it means that it was not properly written!
What the article and these examples highlight is the difference between a research scientist and an industrial programmer. The former's job is to produce optimal algorithms, the latter's job is to produce working solutions. And to be fair to the former, producing a working solution is often not possible until proper algorithm is devised.
The function of Knuth’s expository pascal program is not to sort input data, much less to demonstrate "the best" way to go about doing so. Rather it's wholly intended to show all the important details of his "literate programming" proposal.
Loudly proclaiming that there's a "better" method of sorting input data using common Unix binaries and shell scripting is to proclaim loudly that you've nearly entirely missed the point of the proposal.
I found it fascinating anyway.
EDIT: And of course you can find the article on-line fairly easily. Some quotes from the review:
"the paper eloquently attests that the discipline of simultaneously writing and describing a program pays off handsomely."
"Knuth’s purpose was to illustrate WEB. Nevertheless, it is instructive to consider the program at face value as a solution to a problem. A first engineering question to ask is: how often is one likely to have to do this exact task’? Not at all often, I contend. It is plausible, though, that similar, but not identical, problems might arise. A wise engineering solution would produce-or better, exploit-reusable parts. "
Of course it's generally easier to document and understand software built using (appropriate) higher-level abstractions. Just like most of us find it easier to write and maintain {C++,Java,Python,JS,Lisp,...} software than to do everything in machine code.
But whatever level we're programming at, there is arguably a place for a literate programming approach to improve exposition.
Indeed, I've seen *nix shell scripts that are large and complex enough that a literate programming style would be a huge benefit in attempting to understand them.