3 ms·

so a rebuttal/companion to http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/ http://www.leancrew.com/all-this/2011/12/more-shell-less-egg...

pdpi 7y ago
Pretty much, yes. The argument, in short, is that the problem Knuth is solving isn't "find K most common words", but rather "Use the K most common words problem as the basis to demonstrate how you use Literate Programming". Knuth actually tackles the latter, McIlroy's rebuttal is just the former, so doesn't actually serve as much of an argument about anything.
- lonelappde 7y ago
  There's nothing surprising or underhanded here, and never was. It was just too complimentary perspectives. McIrloy's paper shows the value of good hackery over engineering. Knuth was set back by the blogger's dilemma of trying to show a technique that maybe useful in general but isn't very useful in a very short program.
  - pdpi 7y ago
    I didn't mean to imply there was anything underhanded about McIlroy's critique. Just that that, because McIlroy's code isn't trying to solve the same problem, it shouldn't be taken as a rebuttal to Knuth's point, which is what, apparently, many people believe it to be.
    - projektfu 7y ago
      There's lots of interesting facets here. Doug's solution requires a working Unix system. You might not have that in the problem space. On the other hand, his solution shows that by assuming some nice things about your data, things which Pascal does not allow, you can do some useful things with terse programming. This is reminiscent of the array programming model of APL or J. I haven't written a solution but I'd be surprised if it is more than about 15 characters. In the shell case, the terse program is like a Chinese classic. Written in its own jargon requiring basically a prior understanding of the program to read it.
      - acqq 7y ago
        > In the shell case, the terse program is like a Chinese classic. Written in its own jargon requiring basically a prior understanding of the program to read it. However, if Knuth wanted to be terse, he could have been and write a Pascal program which uses his library routines without showing them ! -- in effect using Unix solution by Doug is equivalent to "not only you must use already pre-written libraries in order to be terse, they are even not the plain routines but they are instead packed as the whole executables, and to use these executables you have to use them on exactly this operating system, exactly using this specific shell, all that property of AT&T (at that time Linux didn't exist, and who had rights to use what wasn't clear, unless you've bought something expensive) just to be able to call these library routines. So it can't be considered a serious "critique." At that time, under these circumstances, it was just an unfair ad.
tzs 7y ago
From that:> I can’t help wondering, though, why he didn’t use head -${1} in the last line. It seems more natural than sed. Is it possible that head hadn’t been written yet? It's possible that it wasn't written yet. It's also possible that it did exist but he saw no reason to start using it, since "sed Nq" continued to work fine. Heck, it's even one less character to type than "head -N"! BTW, apparently "head -N" is considered to be obsolete syntax. The man page for GNU head doesn't even mention it. It just gives this: -c, --bytes=[-]K print the first K bytes of each file; with the leading '-', print all but the last K bytes of each file -n, --lines=[-]K print the first K lines instead of the first 10; with the leading '-', print all but the last K lines of each file -q, --quiet, --silent never print headers giving file names -v, --verbose always print headers giving file names --help display this help and exit --version output version information and exit The "info" documentation for GNU head does mention the "-N" form, and says it is an obsolete syntax supported for compatibility, and says if you must run on hosts that don't support the "-n N" form it is simpler to avoid "head" and use "sed Nq" instead. On my Mac, with BSD head, the man page gives only this form: head [-n count | -c bytes] [file ...] Like GNU head, it accepts the -N form.

pdpi 7y ago

Pretty much, yes. The argument, in short, is that the problem Knuth is solving isn't "find K most common words", but rather "Use the K most common words problem as the basis to demonstrate how you use Literate Programming". Knuth actually tackles the latter, McIlroy's rebuttal is just the former, so doesn't actually serve as much of an argument about anything.

lonelappde 7y ago
There's nothing surprising or underhanded here, and never was. It was just too complimentary perspectives. McIrloy's paper shows the value of good hackery over engineering. Knuth was set back by the blogger's dilemma of trying to show a technique that maybe useful in general but isn't very useful in a very short program.
- pdpi 7y ago
  I didn't mean to imply there was anything underhanded about McIlroy's critique. Just that that, because McIlroy's code isn't trying to solve the same problem, it shouldn't be taken as a rebuttal to Knuth's point, which is what, apparently, many people believe it to be.
  - projektfu 7y ago
    There's lots of interesting facets here. Doug's solution requires a working Unix system. You might not have that in the problem space. On the other hand, his solution shows that by assuming some nice things about your data, things which Pascal does not allow, you can do some useful things with terse programming. This is reminiscent of the array programming model of APL or J. I haven't written a solution but I'd be surprised if it is more than about 15 characters. In the shell case, the terse program is like a Chinese classic. Written in its own jargon requiring basically a prior understanding of the program to read it.
    - acqq 7y ago
      > In the shell case, the terse program is like a Chinese classic. Written in its own jargon requiring basically a prior understanding of the program to read it. However, if Knuth wanted to be terse, he could have been and write a Pascal program which uses his library routines without showing them ! -- in effect using Unix solution by Doug is equivalent to "not only you must use already pre-written libraries in order to be terse, they are even not the plain routines but they are instead packed as the whole executables, and to use these executables you have to use them on exactly this operating system, exactly using this specific shell, all that property of AT&T (at that time Linux didn't exist, and who had rights to use what wasn't clear, unless you've bought something expensive) just to be able to call these library routines. So it can't be considered a serious "critique." At that time, under these circumstances, it was just an unfair ad.

tzs 7y ago

From that:> I can’t help wondering, though, why he didn’t use head -${1} in the last line. It seems more natural than sed. Is it possible that head hadn’t been written yet? It's possible that it wasn't written yet. It's also possible that it did exist but he saw no reason to start using it, since "sed Nq" continued to work fine. Heck, it's even one less character to type than "head -N"! BTW, apparently "head -N" is considered to be obsolete syntax. The man page for GNU head doesn't even mention it. It just gives this: -c, --bytes=[-]K print the first K bytes of each file; with the leading '-', print all but the last K bytes of each file -n, --lines=[-]K print the first K lines instead of the first 10; with the leading '-', print all but the last K lines of each file -q, --quiet, --silent never print headers giving file names -v, --verbose always print headers giving file names --help display this help and exit --version output version information and exit The "info" documentation for GNU head does mention the "-N" form, and says it is an obsolete syntax supported for compatibility, and says if you must run on hosts that don't support the "-n N" form it is simpler to avoid "head" and use "sed Nq" instead. On my Mac, with BSD head, the man page gives only this form: head [-n count | -c bytes] [file ...] Like GNU head, it accepts the -N form.