TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Donald Knuth was framed

632 pointsby akalinabout 5 years ago

31 comments

svatabout 5 years ago
I&#x27;m glad to see this here, for two reasons: (1) In general it&#x27;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:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22221592" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22221592</a><p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18699718" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18699718</a><p>For further context you can look at past and future issues of Bentley&#x27;s column (and its spinoff); a list of them I collected here: <a href="https:&#x2F;&#x2F;shreevatsa.net&#x2F;post&#x2F;programming-pearls&#x2F;" rel="nofollow">https:&#x2F;&#x2F;shreevatsa.net&#x2F;post&#x2F;programming-pearls&#x2F;</a><p>I guess it&#x27;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&#x27;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:<p>&gt; <i>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.)</i><p>There are other points (not mentioned in this article), e.g. the fact that <i>someone</i> 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&#x27;s idea of using a trie (though not a packed&#x2F;hash trie; that&#x27;s no longer needed) <i>still</i> seems fastest: <a href="https:&#x2F;&#x2F;codegolf.stackexchange.com&#x2F;questions&#x2F;188133&#x2F;bentleys-coding-challenge-k-most-frequent-words" rel="nofollow">https:&#x2F;&#x2F;codegolf.stackexchange.com&#x2F;questions&#x2F;188133&#x2F;bentleys...</a> (please someone prove me wrong; I&#x27;d love to learn!)<p>Knuth gladly included McIlroy&#x27;s review verbatim when he reprinted this paper in his collection <i>Literate Programming</i>. BTW here&#x27;s an 1989 interview of McIlroy <a href="https:&#x2F;&#x2F;www.princeton.edu&#x2F;~hos&#x2F;mike&#x2F;transcripts&#x2F;mcilroy.htm" rel="nofollow">https:&#x2F;&#x2F;www.princeton.edu&#x2F;~hos&#x2F;mike&#x2F;transcripts&#x2F;mcilroy.htm</a> where he looks back and calls Knuth&#x27;s WEB “a beautiful idea” and “Really elegant”, and his review “a little unfair”, though of course he reiterates <i>his</i> main point.
评论 #22409616 未加载
评论 #22410792 未加载
评论 #22409475 未加载
btillyabout 5 years ago
There are many, many ways to tell this story. However it resonates because it fits well with an ongoing dynamic. Which is that programmers naturally want to build perfect tools while the business need tends to be for a quick and dirty solution that can be assembled out of prebuilt pieces.<p>Except that this one is extreme. It is hard to find any programmer who builds a more perfect tool than Knuth. There isn&#x27;t a better known problem where the discrepancy between the perfect and the good is this dramatic. Therefore this became the poster child for this ongoing type of conflict retold by those who see themselves as on the side of the quick and dirty solution built out of preassembled pieces. Who, of course, slant the story to further fit their prejudices.<p>This kind of slanting is common. Take a famous WW II example where they were looking to improve bomber durability by putting more armor plate where the bombers were coming back hit. A wise statistician advised them that those were the spots that didn&#x27;t need armor, they should put it on where the bombers were hit and <i>didn&#x27;t</i> come back. Which, assuming that bombers were hit evenly everywhere, was all the places that they didn&#x27;t find holes.<p>The reasoning is perfect, and illustrates a key point of statistical wisdom. But the retelling of the story almost never admits that the advice didn&#x27;t really make a difference. The actual solution to the rate at which bombers were being destroyed was to drop chaff - strips of aluminum cut to half the length of the German radar - so that the radar systems got overwhelmed and the Germans couldn&#x27;t find the bombers.
评论 #22406499 未加载
评论 #22407829 未加载
评论 #22409757 未加载
评论 #22407139 未加载
评论 #22407008 未加载
评论 #22406548 未加载
评论 #22407838 未加载
bonytabout 5 years ago
Site is down, but it looks like archive.org got it.[1] But the entire page is blank, because javascript. It has a fallback, which has what looks like the article in a noscript tag.<p>Hastily converted to markdown with pandoc, and put up as a github gist: <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;tonyb486&#x2F;eec2f16b06eef4692dac6e56362cac50" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;tonyb486&#x2F;eec2f16b06eef4692dac6e56362...</a><p>[1]: <a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;*&#x2F;https:&#x2F;&#x2F;buttondown.email&#x2F;hillelwayne&#x2F;archive&#x2F;donald-knuth-was-framed&#x2F;" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;*&#x2F;https:&#x2F;&#x2F;buttondown.email&#x2F;hille...</a>
评论 #22406446 未加载
评论 #22408357 未加载
geofftabout 5 years ago
Something related that&#x27;s been on my mind recently: a lot of the advantage in building well-designed programs (documented, modular, built to be tested, free of smells, etc.) is less about getting the program right than about getting <i>future changes</i> right, either by someone else, or even yourself when you&#x27;ve forgotten how to do it. But future changes only matter <i>if you want to use the existing program as a starting point</i>.<p>McIlroy&#x27;s pipeline is a little bit hard to read, but I would bet that most people with moderate experience in building shell pipelines could rebuild something equivalent from scratch, even if they&#x27;d have trouble explaining how the current pipeline works. (Or people with experience in Python, Perl, etc. could throw together an equivalent script from scratch quickly.)<p>An implication is that, if you&#x27;re in a language where you can write a productive program to do a task from scratch within (say) 30 minutes, there&#x27;s a lot less of a reason to think about good programming design than if you&#x27;re in a language where doing that same task from scratch is likely to take you a day. In the second language, most of the value of writing documented and well-structured code is so that it takes you 30 minutes when someone asks you to modify it. But in the first language, you can throw away your code when you&#x27;re done with it and still solve the modified problem within 30 minutes.<p>Another possible implication: it&#x27;s better to build reusable components (libraries and utilities) than easily-modifiable code. Part of why McIlroy&#x27;s pipeline works so well is that tools like &quot;tr&quot; and &quot;uniq&quot; exist - and most of us will never have reason to modify the source code of those tools. We need to know what their interfaces are, but we don&#x27;t need to know their internals.
评论 #22408906 未加载
评论 #22409149 未加载
ColinWrightabout 5 years ago
It seems to have the &quot;HN Hug of Death&quot; ... here&#x27;s a snapshot summary from memory:<p>Knuth and McIlroy gave examples of a word count program. Knuth used Literate Programming and did it in 8 pages, McIlroy used shell utilities and did it in 8 lines.<p>This post goes back to the original paper and discovers that Knuth has been grossly misrepresented as to what he was trying to do, and what he achieved.<p><i>Edit</i><p>bonyt&#x27;s[0] comment[1] has links to copies of the content.<p>[0] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;user?id=bonyt" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;user?id=bonyt</a><p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22406365" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22406365</a>
评论 #22407035 未加载
评论 #22406322 未加载
smsm42about 5 years ago
I&#x27;m not sure how it&#x27;s a fair comparison between ready-made Unix tools and written-from-scratch solution. I mean it&#x27;s like somebody asked me to implement a C compiler, and when I produced a huge pile of source code would tell me &quot;Idiot, I can do all that by just typing &quot;gcc&quot;! Muah-hah-ha!&quot;
评论 #22409751 未加载
评论 #22410927 未加载
rstuart4133about 5 years ago
I was around when that encounter happened. I still recall my feelings when I read it.<p>I don&#x27;t recall feeling Knuth was framed.<p>Although McIlroy&#x27;s solution didn&#x27;t really address the question Knuth was asked, it was cute and demonstrated the power of this newfangled thing called &quot;Unix Philosophy&quot;, which at the time needed some oxygen. However the words McIlroy accompanied it with were simply unnecessary, almost childish. I recall cringing when I read them.<p>I do remember wondering if Bentley had done the right thing in publishing McIlroy&#x27;s raw comments, but decided the main attraction of his column was a refreshing honesty. He presented his pearls without any the usual breathless hype or artificial conflict a journalist might add to spice up interest. Having set up this experiment, it would not have been &quot;Programming Pearls&quot; if he didn&#x27;t report exactly what happened, as it happened.<p>Bentely&#x27;s style wasn&#x27;t to constrain or direct for a particular outcome he wanted. That meant McIlroy had lots of rope and McIlroy used it to hang himself, that was McIlroy&#x27;s problem.
personaabout 5 years ago
Title is a little (?) clickbait... Promoting a YOW talk: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ATobswwFwQA" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ATobswwFwQA</a><p>-- The other day I was talking with a friend about structured editing and literate programming came up. LP was one of Donald Knuth&#x27;s ideas, to structure programs as readable documents instead of just machine docs. He was interested in it, I was cautiously skeptical. We both knew the famous story about it: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Literate_programming" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Literate_programming</a><p>&quot;In 1986, Jon Bentley asked Knuth to demonstrate the concept of literate programming by writing a program in WEB. Knuth came up with an 8-pages long monolithic listing that was published together with a critique by Douglas McIlroy of Bell Labs. McIlroy praised intricacy of Knuth&#x27;s solution, his choice of a data structure (Frank M. Liang&#x27;s hash trie), but noted that more practical, much faster to implement, debug and modify solution of the problem takes only six lines of shell script by reusing standard Unix utilities. McIlroy concluded: &gt;&gt;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 Faberge egg—intricate, wonderfully worked, refined beyond all ordinary desires, a museum piece from the start.&quot;<p>The program was print out the top K most-used words in a text. (and so it goes on...) ---
评论 #22407942 未加载
paulrpottsabout 5 years ago
Good analysis. Didn&#x27;t Knuth famously say that his job was to get to the bottom of things, not to stay on top of things?<p>If I were writing a one-off program to do this once for a paid project, the shell script is absolutely the way I would go about it.<p>If I were writing it as a computer scientist, accustomed to teaching students how to find optimal solutions, something like the Knuth program is absolutely the way I would go about it (although in 2020, I would likely use C, not Pascal). I also would likely roll my own approach if I was writing it for the kind of target machine I work on now - a very small one (an embedded microcontroller). And Knuth made his bones when computers were (physically) huge but (in memory and speed) tiny.
kazinatorabout 5 years ago
The shell script uses utilities that are written in C, probably totaling way more lines of system programming language code than Knuth&#x27;s Pascal solution.<p>It&#x27;s a pretty unfair comparison, since the literate programming solution was not presented in order to show a code-golfed word histogram, but how to annotate code.<p>The has trie structure was included in it for that purpose, to show how you use literate programming to annotate such a thing.<p>&gt; <i>First of all, we found that Literate Programming as conceived by Knuth not just “text, code, text, code”. </i><p>Unfortunately, it&#x27;s something worse! It&#x27;s a system in which you chop up a program into arbitrary sections, and give these macro-like names. The sections are presented in some aribitrary order and hierarchically combined together using those macro-like names.<p>Like, say:<p><i>The program&#x27;s overall structure is to accept input, performs some processing and produce output:</i><p><pre><code> accept_input do_processing produce_output </code></pre> The divisions don&#x27;t follow function boundaries. A specific loop inside a specific function might have its own section, and the variable declarations above their own.<p>It&#x27;s basically horrible. You can&#x27;t see the code all in one piece at all when editing it. It won&#x27;t play with your existing tools. The generated result won&#x27;t even have proper indentation.<p>Web and CWeb are programs geared toward someone who is an academic, mainly interested in writing a paper that revolves around a small amount of code.<p>What you&#x27;re really writing is a paper, such that both the typeset paper (with nicely typeset code), and accompanying code pops out from the same source. The raison d&#x27;etre is that paper though.<p>You would be suicidal to use this to write an actual application that doesn&#x27;t need to be detailed in an academic paper.<p>Knuth did somewhat take it to those extremes, but working alone.<p>If we look at TeX, the bulk of it consists of a single tex.web file which is simultaneously not such a large volume of work (less than 25,000 lines of code of documentation and data, less than a 1024K megabyte) ... yet too large to be all in a single file.
评论 #22409822 未加载
评论 #22414979 未加载
briskyabout 5 years ago
I like the idea that code should look more and more like human language. I think that programming languages have gotten much more human-friendly nowadays and this trend will continue. I have created my own human-like programming language prototype to explore these ideas and have implemented TodoMVC with it: <a href="https:&#x2F;&#x2F;github.com&#x2F;tautvilas&#x2F;lingu&#x2F;blob&#x2F;master&#x2F;examples&#x2F;todomvc&#x2F;prog.lgu" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tautvilas&#x2F;lingu&#x2F;blob&#x2F;master&#x2F;examples&#x2F;todo...</a>
FabHKabout 5 years ago
Does anyone have any insight in the computational complexity of the two solutions?<p>The shell script sorts all the words (and then all the counts), so has complexity at least O(n log n) in the number of words.<p>It seems to me an optimal solution could be faster, and I wonder what Knuth implemented.
评论 #22420661 未加载
pkruminsabout 5 years ago
<p><pre><code> KNUTH vs MCILROY </code></pre> <a href="https:&#x2F;&#x2F;comic.browserling.com&#x2F;knuth-vs-mcilroy.png" rel="nofollow">https:&#x2F;&#x2F;comic.browserling.com&#x2F;knuth-vs-mcilroy.png</a><p><pre><code> WHO WILL WIN?!</code></pre>
aortegaabout 5 years ago
You cannot compare Knuth&#x27;s software with a script that use pre compiled tools that have thousands of lines.<p>If you want to compare both solutions, use the Kolmogorov complexity: compress both programs together with any tool&#x2F;compiler it uses and just then, compare both sizes. I bet Knuth&#x27;s solution has an order of magnitude less complexity.
ben509about 5 years ago
These days, though, you can have it both ways with a Jupyter notebook or something similar. It&#x27;s literate, in that you can keep thoughts and discussion in markdown cells, and you can neatly combine computations in computation cells.
lalalandlandabout 5 years ago
Unix shell scripting is an obtuse practice that is really hard to discover. That short shell script is built on hours of hard learned Unix experience that would probably be at least 8 pages long, if explained thorough.
shp0ngleabout 5 years ago
I will probably be downvoted for questioning the legends, but... I don&#x27;t think the poster child of Literate Programming - TeX itself - really has that readable source code.<p><a href="https:&#x2F;&#x2F;mirror-hk.koddos.net&#x2F;CTAN&#x2F;systems&#x2F;knuth&#x2F;dist&#x2F;tex&#x2F;tex.web" rel="nofollow">https:&#x2F;&#x2F;mirror-hk.koddos.net&#x2F;CTAN&#x2F;systems&#x2F;knuth&#x2F;dist&#x2F;tex&#x2F;tex...</a>
评论 #22411978 未加载
评论 #22411974 未加载
rswailabout 5 years ago
Maybe people should take into account that Knuth is a mathematician and computer <i>scientist</i>, not a software <i>engineer</i>.<p>His constraint is <i>correctness</i> under all circumstances, an engineering constraint is about <i>efficiency</i> which constrains correctness to a subset of the potential uses.<p>So from his perspective, the problem was something to be solved, not something to be implemented. As such, describing the problem and the solution is much more a literate requirement, being clear about it to the reader, than a computing requirement, being clear to the computer.<p>Personally, I think most software &quot;engineering&quot; is a crock, built on false assumptions and invalid data, subject to fads like &quot;Agile&quot; (or CMMI or SPICE or RUP or...).<p>The software industry would be better focussed on architecture, not the naive patterns of the GoF, but on fundamentals like types and data flows, Nouns vs Verbs and taking the science and making it practical for use in day to day development by incorporation into the tools used.
giancarlostoroabout 5 years ago
If anyone managed to catch it when it wasn&#x27;t down, care to share a screenshot of the article? I seem to be getting some Heroku error now.<p>&gt; An error occurred in the application and your page could not be served. If you are the application owner, check your logs for details. You can do this from the Heroku CLI with the command
评论 #22406527 未加载
dllthomasabout 5 years ago
I often recommend reading this essay. The conception of LP described (and embodied) is only tenuously related to modern systems claiming to be LP, and what&#x27;s presented is really interesting.<p>That said, I still find myself unsure how it translates into practice. Does anyone have experience working on a system described this way? In particular, I wonder what refactors feel like, and how general problems around stale documentation apply (or fail to).
dracodocabout 5 years ago
I program mainly in R and I always use RMarkdown. I write extensively about question definition, notes, reference, exploration, different directions in RMarkdown. In the end if I ever need to have a script version I have some utility function to pick code chunks and output as script.<p>This serve as a very good documentation and is much better than code comments.
mcvabout 5 years ago
Comparing Knuth&#x27;s LP demo to a 6 line shell script is comparing apples to oranges. There&#x27;s no language that&#x27;s going to be able to do that job in as few lines as that shell script, but that doesn&#x27;t mean all languages are useless. They&#x27;re both interesting demonstrations, but it&#x27;s a useless comparison.
jesse_mabout 5 years ago
I haven&#x27;t heard of the leo editor. I have used org mode in Emacs for little things. I also came across a reimplmentation of the tangling functionality: <a href="https:&#x2F;&#x2F;github.com&#x2F;thblt&#x2F;org-babel-tangle.py" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;thblt&#x2F;org-babel-tangle.py</a>
评论 #22410958 未加载
DSpinellisabout 5 years ago
The proposed example problem that would be difficult to solve on the Unix command line can be written as a pipeline of just nine commands. See <a href="https:&#x2F;&#x2F;www.spinellis.gr&#x2F;blog&#x2F;20200225&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.spinellis.gr&#x2F;blog&#x2F;20200225&#x2F;</a>
hzhou321about 5 years ago
&gt; Writing the code out-of-order is the whole point.<p>Yes!<p>MyDef, <a href="https:&#x2F;&#x2F;github.com&#x2F;hzhou&#x2F;MyDef" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;hzhou&#x2F;MyDef</a>, is such a system.
adoneseabout 5 years ago
It seems to be down.
评论 #22406230 未加载
kickabout 5 years ago
Site&#x27;s back up.
lincpaabout 5 years ago
Markdown Literary Programming that don&#x27;t break the syntax of any programming language<p><a href="https:&#x2F;&#x2F;github.com&#x2F;linpengcheng&#x2F;PurefunctionPipelineDataflow&#x2F;blob&#x2F;master&#x2F;doc&#x2F;markdown_literary_programming.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;linpengcheng&#x2F;PurefunctionPipelineDataflow...</a>
gameswithgoabout 5 years ago
The unix command solution is likely orders of mangnitude slower than what Knuth wrote, which given the computer power of the time should have seemed fairly relevant.
draw_downabout 5 years ago
I&#x27;ve seen similar defenses of Knuth over the years, but I&#x27;m still inclined to view this McIlroy&#x27;s way. I think focusing on the shell script is a canard, the point is he picked what seemed like the right tool for the job. Isn&#x27;t that what commenters are saying here all the time?<p>Anyway, perhaps I just suffer from a failure of imagination, but I can&#x27;t see why the &quot;Blah&quot;s interspersed with `foo`s and `bar`s is meant to be revelatory.
评论 #22409141 未加载
评论 #22408487 未加载
Myrmornisabout 5 years ago
&gt; The actual paper paints LP in a much better light than we thought it did....The actual content is effectively his stream-of-consciousness notes about what he’s doing. He discusses why he makes the choices he does and what he’s thinking about as primary concerns. It’s easy to skim or deep-dive the code.<p>Now imagine if these stream-of-consciousness comments getting in the way of the code were written by your colleagues, rather than Donald Knuth.
评论 #22407936 未加载