I want to be charitable but I find the criticism here of Knuth of be quite childish. Was the point to solve the problem with as little work as possible? If that's the case, there's probably some plugin for your favorite text editor that already does this. So what? What was the point exactly? You could just have easily built a library function that does all of this and then write a Pascal program that calls the library in one line of code, state the library is not part of your solution, and say the solution is better than the one with UNIX utilities. So what? Is the point to illustrate that Knuth is unaware of elementary concepts such as code reuse, come on that is just sort of ridiculous.

If you had asked Knuth to solve this problem using any means in the whole world and do it within 10 minutes, I don't think he would have any trouble doing it.

And honestly, if the lesson is to teach us some really basic lesson of code reuse, not reinventing the wheel, or some such like that, I think this was a pretty convoluted way to deliver sort of a common sense lesson.

Against all conventional wisdom I actually think McIlroy was wrong.

In my experience writing reusable code, unless you're writing a library, is usually a waste of time. Must code, even when written with intent to be reusable -- isn't. Maintainability and readability almost always trump reusability. Refactoring fast the point where reuse is needed typically is the better approach.

McIlroys approach is the less common approach of library/framework writers while Knuth is the approach of app devs.

This is fascinating, and should be a source of reflection for anyone writing code for a living or being involved with programming on any serious level.

Additionally, I can't help but think that this essay (and others in this style) and subsequent reflections would make for a perfect seminar targeted towards final year CS students, as it merges perfectly academic reflection and real world engineering considerations, which is what many CS programs across the world sorely need.

I think I found a copy of the original Knuth/McIlroy paper itself: http://people.mokk.bme.hu/~kornai/AzkellHaskell/bentley_1986...

If the problem is simple enough to be solved by a shell script, then obviously literate programming is going to be overkill. Algorithmic problems such as data-structures are well suited for literate programming.

"Program specifically designed to demonstrate literate programming turns out to be a good demonstration of literate programming, not a good demonstration of library creation"

... can someone please point out what the problem is? I don't see it :-|

I haven't checked out the original paper, but the solution presented on the blog is a non-solution. It only works for ascii characters and words composed out of ascii. When you reuse someone elses code, you always get stuck with someone elses assumptions. In this case, that English is the only language and that the regular expression [A-Za-z] encompasses all possible letters in the world. The shell solution, built upon standard tools, can not be extended to work in an international context but a custom solution in Python (or even Pascal) quite concievably could.

Both the article's improved pipeline and Doug McIlroy's original have a bug. I've just written about it on +Ade Oshineye's post about the original article. https://plus.google.com/105037104815911535953/posts/KuXczyiw...

Doesn't Pascal have libraries for sorting? I find that hard to believe. So there must have been another reason why Knuth chose to implement everything from scratch. Probably to demonstrate programming techniques. You don't learn that much about algorithms by stringing together a couple of shell commands.

Maybe I am missing something here, but The python version is: O(N) sequential disk access O(NlogN) cpu O(N) RAM

The shell script is the same for disk and cpu, however, it is O(1) of RAM, and therefor can operate on input of size limited to disk, not RAM

I like that article very much, so I wanted to monitor the blog. However, I found neither an Atom feed nor an RSS feed. That's a pretty good way to turn off potential regular readers.

Inspired by reading this:

http://www.leancrew.com/all-this/2011/12/more-shell-less-egg...

Neither Knuth’s nor McIlroy’s solution handles Unicode, so they both suck.