This has been posted a number of times on HN, I'll just point to the must recent one that spawned a fairly large number of comments (which in turn has links to various other previous discussions courtesy of dang):
And that’s why I love pipelines. McIlroy’s solution and explanation are succinct and clear, and the solution itself easily and readily expandable and repurposable. Bravo.
It is elegant, and easy to understand and modify. But it's less efficient and significantly slower than even a naïve python or perl script since it sorts a lot more than it needs to.
Which... is kind of the point of the Knuth solution here. It was a pedagogical exercise. As much to show how literate programs can be presented as it was to "solve" the stated problem.
Edit: It occurs to me you could be referring to the pipeline version. Which, yeah, I don't think that really changes my post. :D. The final paragraph would be changed to the point of the Milroy's code is to get the answer, not to have a library function that is expected to be used again and again on input.
Yes, I was talking about the pipeline version. Last time this came up, I tried a simple perl script[1] and it was quite a lot faster than the pipeline. Even without using a heap to further limit the sorting.
I think it will be faster than python or perl, because the actual work is done by optimized c-code.
However if you want to extend the program from a toy to something that can handle words like "won't" "c-code" "a.i." or "naïve" then it will be quite difficult to do so.
I tried a perl script versus the shell pipeline, see my other comments in the thread. It's significantly faster, because using sort and uniq -c is a pretty high effort way to count words, especially for big lists. Your words seem to work fine with it, it's just splitting on whitespace.
Ah, yeah. Googling around a bit suggests some disagreement on whether that's true or not. It appeared in a documentary, then was disputed by others afterwards.
I think most of us are used to seeing literate programming in old articles, often by Knuth himself. One excellent, modern and practical example of literate programming can be found in Physically Based Rendering, by Pharr, Jakob and Humphreys. It's not just the industry-standard overview of rendering theory and contemporary techniques in a big ol' hardcover book, it's also the source for an advanced ray tracer incorporating these techniques. And written in modern C++, not ancient Pascal.
18 comments
[ 3.8 ms ] story [ 58.0 ms ] threadhttps://news.ycombinator.com/item?id=30017311
That said https://www.amazon.com/Exercises-Programming-Style-Cristina-... is a good sized book that is nothing but takes on this program from different styles. It is amusing how far you can take that.
Which... is kind of the point of the Knuth solution here. It was a pedagogical exercise. As much to show how literate programs can be presented as it was to "solve" the stated problem.
Edit: It occurs to me you could be referring to the pipeline version. Which, yeah, I don't think that really changes my post. :D. The final paragraph would be changed to the point of the Milroy's code is to get the answer, not to have a library function that is expected to be used again and again on input.
[1] https://news.ycombinator.com/item?id=30038415
However if you want to extend the program from a toy to something that can handle words like "won't" "c-code" "a.i." or "naïve" then it will be quite difficult to do so.
But it's a "nonce": to be used once, on a small desktop machine (for low-integer values of once). That's not really a good objection.
cf. "Programming Pearls: A literate program" https://dl.acm.org/doi/10.1145/5948.315654
Aside: I received a masterclass from Gradmaster McIlroy, in context of this selfsame shell pipeline: https://www.evalapply.org/posts/shell-aint-a-bad-place-to-fp...
I was floating in the air all week :D
(edit: typo)
The 3rd edition can be read online here: https://www.pbr-book.org/