More shell, less egg (2011)
leancrew.com
leancrew.com
• Hillel Wayne, "Donald Knuth Was Framed": https://buttondown.email/hillelwayne/archive/donald-knuth-wa...
• me, various comments, including https://news.ycombinator.com/item?id=22407313 in the comments on that post, linking to older/other comments.
This story comes up from time to time and I hate it. Knuth was asked to illustrate literate programming style, and he did so. The request was not "show us how to find the most frequently occurring words in a file." McIlroy's response would be fine for the latter and utterly useless for the former (and actual) request.
Donald Knuth was framed - https://news.ycombinator.com/item?id=22406070 - Feb 2020 (180 comments)
More shell, less egg (And Then McIlroy Said Unto Knuth) - https://news.ycombinator.com/item?id=15701452 - Nov 2017 (2 comments)
More shell, less egg (2011) - https://news.ycombinator.com/item?id=15265000 - Sept 2017 (7 comments)
More shell, less egg (2011) - https://news.ycombinator.com/item?id=10081539 - Aug 2015 (28 comments)
More shell, less egg (2011, on McIlroy and Knuth) - https://news.ycombinator.com/item?id=7381900 - March 2014 (3 comments)
Knuth and the Unix Way - https://news.ycombinator.com/item?id=3329668 - Dec 2011 (62 comments)
This short bit of (golfed/terse) Perl seems to be 2-3x faster for the inputs I tested. Though it's also 2x more "code", despite golfing and skipping best practice strict/warnings. And both are wasting some time sorting the whole list versus a partial heap sort or similar.
#!/usr/bin/perl
$l=shift(@ARGV)||1;
while (<>) {
for (split) {
$c{lc($_)}++;
}
}
for (sort { $c{$b} <=> $c{$a} } (keys %c)) {
print "$c{$_} $_\n";
last if ++$i == $l;
}I remember that cdrecord has explict advice on raising pipe buffer size to avoid an underun (that will render a CD unusable). Perhaps pipe tuning here might also impact performance.
I don't know if dash will increase performance in this particular case.
$ rpm -qi dash | tail -3
DASH is a POSIX-compliant implementation of /bin/sh that aims to be as small as
possible. It does this without sacrificing speed where possible. In fact, it is
significantly faster than bash (the GNU Bourne-Again SHell) for most tasks.I don't think the shell used matters, as most of the cpu time is in the sorting.
$c{lc $_}++ for map split(), <ARGV>;
Also, if you have List::UtilsBy handy (which I basically always do),
rev_nsort_by { $c{$_} } keys %c
(I have not executed any of this code, I'm just musing here, so no warranty express or implied ;)
Very occasionally their opinion may be backed by an actual counterargument, but this is quite rare, and even then the counterarguments tend to be of varying quality.
Rarely is there an actual "evisceration" at play (a term I would have otherwise reserved for someone pointing out basic logical flaws in an argument, which cause it to collapse as completely invalid).
I've seen this kind of language used as clickbait more than anything else so many times by now, that by this point whenever I hear "X destroys Y", my knee jerk reaction is that, despite the usually present controversy surrounding the kind of opinions that attract this kind of reaponses, for Y to merit such a vacuous attack in the first place means they're probably right.
Neither was said.
> And then he calmly and clearly eviscerated the very foundation of Knuth’s program.
How did he "eviscerate" it? Did he have an objective metric where it scored low despite promises? Did he show it kills babies?
No. He just wrote a different one which in his opinion was better.
The author is simply exaggerating for effect.
One thing that I'd love to hear more people talk about is how to apply shell-style composition to settings where it's not so obvious, or how to create new programs that lend themselves well to this programming style.
It's really bad when you have to write those 10 pages over and over again due to insufficient tooling available.
• Bentley, J., & Knuth, D. (1986). Programming pearls: Literate Programming. Communications of the ACM, 29(5), 384–369. doi:10.1145/5689.315644 = https://www.cs.tufts.edu/~nr/cs257/archive/don-knuth/pearls-...
• Bentley, J., Knuth, D., & McIlroy, D. (1986). Programming pearls: A Literate Program. Communications of the ACM, 29(6), 471–483. doi:10.1145/5948.315654 = https://www.cs.tufts.edu/~nr/cs257/archive/don-knuth/pearls-...
It has been reprinted (along with the review) in Knuth's books Literate Programming (https://cs.stanford.edu/~knuth/lp.html), one of the volumes of his collected papers (https://cs.stanford.edu/~knuth/selected.html).
Of course this post here ("More shell, less egg") is highly misleading, one which I'll post a separate top-level comment.