I've always personally disliked McIlroy's oft-quoted conclusion (emph. mine):

> Knuth has shown us here how to program intelligibly, but not wisely. I buy the discipline. I do not buy the result. He has fashioned a sort of industrial-strength Fabergé egg—intricate, wonderfully worked, refined beyond all ordinary desires, a museum piece from the start.

Well, yes – absolutely.

If you read the initial column[1] pre-McIlroy's response, you'll see that Knuth is not presenting a word-counting solution, but instead the concept of literate programming and how intertwining code and prose can be better for the programmer. Knuth isn't trying to count words, he's trying to teach you a different way to develop, and he's doing it by showing an example that has been simplified so the average person can chew on it.

I'm not sure if the popular interpretation of "ivory tower Knuth versus tactical genius McIlroy" is a modern take or if that was how it was received when the column was published, but it feels very unfair to present it as such today.

[1]: https://doi.org/10.1145/5689.315644

I have seen it observed that while the tr/sort/uniq approach has practical value, that if the question is how would you implement the features that tr/sort/uniq provide simply invoking them is not much of an answer. I don't think Knuth was unaware that there were existing tools that could solve the problem, the whole point was to demonstrate his literate programming approach at some semi-reasonable scale on a problem everyone could recognize. It's kinda like how pretty much every interview-sized question has some sort of off-the-shelf solution somewhere, because anything that fits into an interview has been solved thousands of times over... but that's not the point of interviews.

In modern terms, it would be something like complaining that $LANGUAGE's web server implementation is a grotesque bloated mess (and therefore $LANGUAGE isn't very good) because in shell all I have to do is run "nginx". There is a true and useful sense in which that is true, but there is also a true and useful sense in which that is utterly missing the point.

Also interesting is that this problem is used as the example in the book "Exercises in Programming Style" by Cristina Videira Lopes. It shows this problem solved in 33 different programming styles, for example historical, function composition, data-centric etc.

I have written more about it here: https://henrikwarne.com/2018/03/13/exercises-in-programming-...

There is a new version of that book. Thanks for bringing it to my attention, looks great!

If you want to read the " ten-page Knuthian masterpiece": https://homepages.cwi.nl/~storm/teaching/reader/BentleyEtAl8...

I don't think it was linked from the article

Last summer I was looking for a program that would tell me which shell commands last used in a specific directory. Because I had been reading "The Unix Programming Environment" it quickly occurred to me that the program I was looking for could easily be made from several existing commands. Only after I wrote the small script did I find that the solution already existed except it was >1000 lines of code, 20 github contributors, and utilized a sqlite database.

My one line has less features, but I'll take it.

Could you please share the one-liner? Thanks!

Sorta. That incident is also famous for being easy to misrepresent.

That said, if you are new to that, Programmer Pearls is a great series. And literate programming is neat to at least know of.