9 ms·

I'm glad to see this here, for two reasons: (1) In general it's nice when people return to the primary sources rather than second-hand accounts, and (2) this pa

by svat 7y ago

I'm glad to see this here, for two reasons: (1) In general it's nice when people return to the primary sources rather than second-hand accounts, and (2) this particular topic is of interest to me; here are a couple of previous comments that were somewhat well-received on HN: https://news.ycombinator.com/item?id=22221592 https://news.ycombinator.com/item?id=22221592 https://news.ycombinator.com/item?id=18699718 https://news.ycombinator.com/item?id=18699718 For further context you can look at past and future issues of Bentley's column (and its spinoff); a list of them I collected here: https://shreevatsa.net/post/programming-pearls/ https://shreevatsa.net/post/programming-pearls/ I guess it's a long-standing tradition in literary reviews for reviewers to push their own ideas, rather than confining themselves solely to reviewing the work in question. That is what happened here. Knuth had written a program that he had been asked to write, to demonstrate the programming discipline. But McIlroy, as the inventor of Unix pipes and a representative of the Unix philosophy (at that time not well-known outside the few Unix strongholds: Bell Labs, Berkeley, etc), decided to point out (in addition to a good review of the program itself) the Unix idea that such special-purpose programs shouldn't be written in the first place; instead one must first accumulate a bunch of useful programs (such as those provided by Unix), with ways of composing them (such as Unix pipes). A while later, John Gilbert described this episode this way: > Architecture may be a better metaphor than writing for an endeavor that closely mixes art, science, craft, and engineering. “Put up a house on a creek near a waterfall,” we say, and look at what each artisan does: The artist, Frank Lloyd Wright (or Don Knuth), designs Fallingwater, a building beautiful within its setting, comfortable as a dwelling, audacious in technique, and masterful in execution. Doug McIlroy, consummate engineer, disdains to practice architecture at all on such a pedestrian task; he hauls in the pieces of a prefabricated house and has the roof up that afternoon. (After all, his firm makes the best prefabs in the business.) There are other points (not mentioned in this article), e.g. the fact that someone had to have written those Unix programs in the first place and writing them with literate programming can lead to better results, and the fact that Knuth's idea of using a trie (though not a packed/hash trie; that's no longer needed) still seems fastest: https://codegolf.stackexchange.com/questions/188133/bentleys-coding-challenge-k-most-frequent-words https://codegolf.stackexchange.com/questions/188133/bentleys... (please someone prove me wrong; I'd love to learn!) Knuth gladly included McIlroy's review verbatim when he reprinted this paper in his collection Literate Programming. BTW here's an 1989 interview of McIlroy https://www.princeton.edu/~hos/mike/transcripts/mcilroy.htm https://www.princeton.edu/~hos/mike/transcripts/mcilroy.htm where he looks back and calls Knuth's WEB “a beautiful idea” and “Really elegant”, and his review “a little unfair”, though of course he reiterates his main point.

carterehsmith 7y ago
I wonder if the two solutions were ever compared on some kind of test case corpus - like encyclopaedia, or something similar. I am talking about execution time, memory use and so on. Given Knuth's background, it may well be that he was looking for the (computationally) optimal solution, wherein the bash script was more about writing it quickly using existing tools.
- svat 7y ago
  That's a good question! 1. Note that these were not quite "two solutions" as one might think from the phrase, but rather a commissioned program, and a review of it (which also happened to contain an alternative approach). 2. I did actually end up comparing them on a test corpus just last month -- kind of linked to it twice in the comment but here it is again: https://codegolf.stackexchange.com/questions/188133/bentleys-coding-challenge-k-most-frequent-words https://codegolf.stackexchange.com/questions/188133/bentleys... -- a C++ translation of Knuth's program runs about 140 times faster on the largest case than the shell solution. 3. About "writing it quickly using existing tools": note that while the Unix commands -- tr, sort, uniq, sed -- are widely available today (even on Windows!), they were not so in 1986, unless you were in certain special circumstances such as having paid a lot of money for a Unix system. So McIlroy was pointing out that in their (Unix) world, this problem would be easier than it was outside, so his proposed solution was also sort of an advertisement for Unix, not just the Unix philosophy.
svat 7y ago
Counterpoint[0]: Knuth really is a fan of writing monolithic (rather than "modular") programs from scratch, in a way that goes against all the experience of software engineering accumulated over decades, so that criticism is well-deserved. For example, his big programs TeX (1982) and METAFONT (1984) are each book-length and the source code of each is in a single large file amounting to about 20000+ lines of Pascal code. His programs do not contain much in the way of standard software-engineering practices like abstraction, modules (hiding implementation behind an interface), unit tests, libraries, etc. In fact, he has spoken out against unit tests and code reuse! [1] > the idea of immediate compilation and "unit tests" appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be "mocked up." ... > With the caveat that there’s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, [...] I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace. Moreover, his sympathies always lay with the "other" side of the "structured programming" revolution (he still liberally uses GOTOs, etc -- still coding like a 1950s/1960s machine code programmer), and in his 1974 paper "Structured Programming With Go To Statements", he approvingly quotes something that might horrify many software engineers today: > In this regard I would like to quote some observations made recently by Pierre-Arnoul de Marneffe: > In civil engineering design, it is presently a mandatory concept known as the "Shanley Design Criterion" to collect several functions into one part . . . If you make a cross-section of, for instance, the German V-2, you find external skin, structural rods, tank wall, etc. If you cut across the Saturn-B moon rocket, you find only an external skin which is at the same time a structural component and the tank wall. Rocketry engineers have used the "Shanley Principle" thoroughly when they use the fuel pressure inside the tank to improve the rigidity of the external skin! . . . People can argue that structured programs, even if they work correctly, will look like laboratory prototypes where you can discern all the individual components, but which are not daily usable. Building "integrated" products is an engineering principle as valuable as structuring the design process. > ... Engineering has two phases, structuring and integration: we ought not to forget either one... (This comment is slightly tongue-in-cheek, but hopefully provocative enough.) [0]: Hey it's been a couple of hours and there's no reply attacking my comment, guess I better do it myself. :-) [1]: http://www.informit.com/articles/article.aspx?p=1193856 http://www.informit.com/articles/article.aspx?p=1193856

by svat 7y ago

carterehsmith 7y ago

I wonder if the two solutions were ever compared on some kind of test case corpus - like encyclopaedia, or something similar. I am talking about execution time, memory use and so on. Given Knuth's background, it may well be that he was looking for the (computationally) optimal solution, wherein the bash script was more about writing it quickly using existing tools.

svat 7y ago
That's a good question! 1. Note that these were not quite "two solutions" as one might think from the phrase, but rather a commissioned program, and a review of it (which also happened to contain an alternative approach). 2. I did actually end up comparing them on a test corpus just last month -- kind of linked to it twice in the comment but here it is again: https://codegolf.stackexchange.com/questions/188133/bentleys-coding-challenge-k-most-frequent-words https://codegolf.stackexchange.com/questions/188133/bentleys... -- a C++ translation of Knuth's program runs about 140 times faster on the largest case than the shell solution. 3. About "writing it quickly using existing tools": note that while the Unix commands -- tr, sort, uniq, sed -- are widely available today (even on Windows!), they were not so in 1986, unless you were in certain special circumstances such as having paid a lot of money for a Unix system. So McIlroy was pointing out that in their (Unix) world, this problem would be easier than it was outside, so his proposed solution was also sort of an advertisement for Unix, not just the Unix philosophy.

svat 7y ago

Counterpoint[0]: Knuth really is a fan of writing monolithic (rather than "modular") programs from scratch, in a way that goes against all the experience of software engineering accumulated over decades, so that criticism is well-deserved. For example, his big programs TeX (1982) and METAFONT (1984) are each book-length and the source code of each is in a single large file amounting to about 20000+ lines of Pascal code. His programs do not contain much in the way of standard software-engineering practices like abstraction, modules (hiding implementation behind an interface), unit tests, libraries, etc. In fact, he has spoken out against unit tests and code reuse! [1] > the idea of immediate compilation and "unit tests" appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be "mocked up." ... > With the caveat that there’s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, [...] I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace. Moreover, his sympathies always lay with the "other" side of the "structured programming" revolution (he still liberally uses GOTOs, etc -- still coding like a 1950s/1960s machine code programmer), and in his 1974 paper "Structured Programming With Go To Statements", he approvingly quotes something that might horrify many software engineers today: > In this regard I would like to quote some observations made recently by Pierre-Arnoul de Marneffe: > In civil engineering design, it is presently a mandatory concept known as the "Shanley Design Criterion" to collect several functions into one part . . . If you make a cross-section of, for instance, the German V-2, you find external skin, structural rods, tank wall, etc. If you cut across the Saturn-B moon rocket, you find only an external skin which is at the same time a structural component and the tank wall. Rocketry engineers have used the "Shanley Principle" thoroughly when they use the fuel pressure inside the tank to improve the rigidity of the external skin! . . . People can argue that structured programs, even if they work correctly, will look like laboratory prototypes where you can discern all the individual components, but which are not daily usable. Building "integrated" products is an engineering principle as valuable as structuring the design process. > ... Engineering has two phases, structuring and integration: we ought not to forget either one... (This comment is slightly tongue-in-cheek, but hopefully provocative enough.) [0]: Hey it's been a couple of hours and there's no reply attacking my comment, guess I better do it myself. :-) [1]: http://www.informit.com/articles/article.aspx?p=1193856 http://www.informit.com/articles/article.aspx?p=1193856