
More shell, less egg (2011) - tosh
http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/
======
dunkelheit
Knuth also reuses code by (oh, horror!) copy-pasting it. See e.g.
[http://www.informit.com/articles/article.aspx?p=1193856](http://www.informit.com/articles/article.aspx?p=1193856)
(search for "re-editable" code).

Another fun example: a common sentiment of distrusting comments and
documentation. The title of
[https://martinfowler.com/bliki/CodeAsDocumentation.html](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.

------
Quequau
This seems like a really lousy, not to mention old (2011), article.

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.

~~~
amouat
Or perhaps McIllroy fully understood that and wanted to make the point that
programming with higher-level abstractions makes software easier to document
and understand. It's hard to say without being able to read the original
article.

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. "

~~~
jfk13
Someone must ultimately have written those higher-level abstractions (such as
tr, sort, uniq, sed, etc.) in a lower-level language. In a literate form?
(Unlikely!)

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.

~~~
amouat
Sure. And having read (part of) the paper, the point was more about reuse than
abstraction (though they are obviously related concepts).

------
benmarten
More fish, less jupp.

