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 (2020)

358 pointsby goranmoominabout 3 years ago

26 comments

svatabout 3 years ago
I guess this was posted after someone saw this come up on HN yesterday: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31295427" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31295427</a><p>I&#x27;ve been planning (for 2+ years now so it probably won&#x27;t happen) writing a large blog post about this matter, which would be called “Tries, Packed Tries, and the Bentley–Knuth–McIlroy story”:<p>• Part 1 would introduce the trie data structure both abstractly (the tree structure) and concretely (how exactly to represent the children of a node), with the trade-offs: as a linked list (space-efficient, slow lookup), as an array (fast lookup, takes space), or as some more nontrivial tree structure itself (“yo dawg…”). Then we&#x27;d discuss the really cool idea of “packing” the array, as nicely described in Frank Liang&#x27;s thesis <a href="https:&#x2F;&#x2F;tug.org&#x2F;docs&#x2F;liang&#x2F;" rel="nofollow">https:&#x2F;&#x2F;tug.org&#x2F;docs&#x2F;liang&#x2F;</a> (also mentioned in TAOCP Exercise 6.3:4 and answer, which incidentally refers to the CACM Bentley–Knuth–McIlroy article that we&#x27;re talking about). We&#x27;d also illustrate how hyphenation is done in the TeX program using packed tries (maybe this can be a separate post).<p>• Part 2 would go into the Bentley–Knuth-McIlroy story:<p>• Part 2a (&quot;Before&quot;): Bentley&#x27;s thesis&#x2F;book on writing efficient programs, and the <i>Programming Pearls</i> column. Knuth writing TeX first for himself in SAIL in 1977–78. The instant interest and ports&#x2F;rewrites it led to. Knuth responding by rewriting TeX into its current form in 1980–82, and how the goals of portable software (thus Pascal, and its limitations! see BWK rant) and of eventually publishing it as a book led him to the idea of literate programming, which he still considers the most important outcome of his years into the TeX project. Meanwhile, at Bell Labs, McIlroy&#x27;s invention of Unix pipes, and the instant excitement of &quot;pipe day&quot;. (<i>“It was absorbed instantly into one&#x27;s outlook on programming. And by the end of the week secretaries were piping the output of NROFF into the printer”</i>) The Unix philosophy, and how it took a while to spread. How these three threads came together in 1986, when Bentley read Knuth&#x27;s TeX, wrote about LP in his <i>Pearls</i> column, and published one program of Knuth&#x27;s (the random-numbers one) and asked him to write another (the frequent words one).<p>• Part 2b (the program): How Knuth ingeniously combined the idea of packed tries with that of hashing with linear probing, to create the data structure especially for this problem (maybe we can call it a hash-packed trie?). Another look at his very nice idea&#x2F;program, presented differently (maybe some illustrations of how the data structure works), and some design choices he made.<p>• Part 2c (the review and later): How Bentley got McIlroy to review it, a close reading of the review: its actual content and points about LP and Knuth&#x27;s style, and finally the (first sentence and) last part where McIlroy used the review to advertise his own Unix philosophy and the short shell pipeline version. The further reactions to this, including Bentley&#x27;s remarks in the same column, and later articles and reactions like the &quot;prefabs&quot; comment (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22406070" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22406070</a>). The short-lived LP column in CACM that it spawned (<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>) and how it fizzled out, how it turns out everyone wants to do LP in their own system. How the story got bastardized over time (the misleading &quot;More shell less egg&quot; blog post for example, and some other examples of people misunderstanding the history entirely).<p>• Part 3 would compare the two approaches (even though they are not meant to be compared!), mention how at <a href="https:&#x2F;&#x2F;codegolf.stackexchange.com&#x2F;questions&#x2F;188133&#x2F;" rel="nofollow">https:&#x2F;&#x2F;codegolf.stackexchange.com&#x2F;questions&#x2F;188133&#x2F;</a> I simply translated Knuth&#x27;s program into C++ and beat the then-fastest Rust solution (since beaten again by translation from C++ back into Rust: still based on the trie idea though!), some words about cache misses and 32-bit “pointers” in a 64-bit world (and Knuth&#x27;s rant about it).<p>Something like that: it&#x27;s probably too long for me to ever get around to writing it (or for anyone to be interested in reading), though…
评论 #31306432 未加载
评论 #31305313 未加载
评论 #31320379 未加载
评论 #31307951 未加载
andi999about 3 years ago
Is there more discussion about the &#x27;framed&#x27; part? I mean how was the counter perceived. The whole &#x27;setup&#x27; looks like:<p>- show how to write a spreadsheet application<p>- here you go, couple of hundred pages it is though<p>- ahh, silly person, why not type &#x27;excel&#x27;<p>So what happened next? Everybody rolled eyes, or people said &#x27;yeah, typing excel is pure genious&#x27;?
评论 #31305104 未加载
评论 #31302166 未加载
评论 #31303770 未加载
tlarkworthyabout 3 years ago
I am super excited by <a href="https:&#x2F;&#x2F;observablehq.com" rel="nofollow">https:&#x2F;&#x2F;observablehq.com</a> which has made an out-of-the-box literate programming environment for Javascript zero configuration (like Knuth&#x27;s it has a non-linear execution order). Since switching to literate programming I have found myself adopting a documentation-driven-development methodology, where I ponder about the purpose of the notebook in the introduction, and because I reread it every time I open the notebook, the clarity of the software goes up, which also feedbacks into the ongoing development process too.<p>It takes a little while before habits change, but I think I have learnt more in the last year at age 40 than I did in my first year of undergraduate aged 19.<p>An aspect of Observable which is particularly compelling since Knuth is the fact that inter-notebook dependencies are hyperlinks, so these are not standalone literate programming artifacts, but they are a graph of explanation too. You can learn a lot by surfing notebook dependencies. Bundling code with documentation is such a win.<p>The other thing about Observable is the cells are reactive, so your documentation is not necessarily static either. You can provide animated interactive explanations too.<p>More info on the different types of content you can embed<p><a href="https:&#x2F;&#x2F;observablehq.com&#x2F;@observablehq&#x2F;cell-modes" rel="nofollow">https:&#x2F;&#x2F;observablehq.com&#x2F;@observablehq&#x2F;cell-modes</a><p>More info on the spreadsheet like execution ordering:<p><a href="https:&#x2F;&#x2F;observablehq.com&#x2F;@observablehq&#x2F;observables-not-javascript" rel="nofollow">https:&#x2F;&#x2F;observablehq.com&#x2F;@observablehq&#x2F;observables-not-javas...</a> More info on the literate programming support
评论 #31302911 未加载
评论 #31302383 未加载
评论 #31302190 未加载
rendallabout 3 years ago
When I first started in this industry, I thought it was essentially immune to fads. &quot;Does it work? Yes? Ship it!&quot; Seems so naïve. Whole paradigms rise and fall for arbitrary reasons: a viral blog post, or an open letter, or the tech stack of that cool startup. Perhaps this blog post will lead to the reformation of the literate programming approach.
评论 #31302062 未加载
评论 #31303451 未加载
moominabout 3 years ago
If you want to read a thoughtful and valid criticism of Knuth’s ideas, I recommend <a href="https:&#x2F;&#x2F;www.cs.tufts.edu&#x2F;~nr&#x2F;pubs&#x2F;lpsimp-abstract.html" rel="nofollow">https:&#x2F;&#x2F;www.cs.tufts.edu&#x2F;~nr&#x2F;pubs&#x2F;lpsimp-abstract.html</a> by Norman Ramsey. The observation that rang most true for me was: literate programming should be written in the style of a car manual, not a novel.
评论 #31308515 未加载
评论 #31302232 未加载
Semaphorabout 3 years ago
180 comments 2 years ago: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22406070" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=22406070</a>
pdpiabout 3 years ago
(2020)<p>It seems to me that both McIlroy’s original critique and this blog post miss the point by a mile. It’s completely meaningless to compare the relative merits of the two solutions, because Knuth’s ultimate goal isn’t to produce a solution.<p>Doing a presentation on literate programming has to deal with two more or less contradictory concerns — you need a sufficiently simple problem that your audience can follow along, but you need your solution to be complex enough that you can actually illustrate LP.<p>A sorted frequency table is a simple enough problem statement, a trie is a sufficiently elaborate solution that doesn’t feel <i>too</i> contrived while also being familiar enough that the audience can follow along. Knuth’s approach was pretty much the perfect way to hit both of those requirements!
评论 #31302422 未加载
评论 #31302111 未加载
评论 #31302438 未加载
评论 #31302287 未加载
评论 #31303395 未加载
评论 #31304265 未加载
评论 #31302089 未加载
scotty79about 3 years ago
McIlroy’s solution was to just use few programs Donald&#x27;s Knuth&#x27;s of the world previously wrote to hack together suboptimal solution to his current problem.<p>Ultimately his approach won and today &gt;90% of programming is just stitching together the code someone else wrote so it sorta works for your problem.<p>Much maligned here nodejs ecosystem is implementation of his approach to web development.
评论 #31303466 未加载
评论 #31306561 未加载
评论 #31303191 未加载
jzdziarskiabout 3 years ago
I don’t even understand what we’re comparing here. Is it lines of code? In that case, you must include all of the code from tr, sort, and any other shell commands used to perform the task at hand. By that standard, Knuth still wins by a long shot. Were this an actual coding contest (if such things exist anymore), one does not simply argue that instead of coding the solution in the given language, I’m going to just use five other people’s solutions and claim my trophy. Had the argument been who could most efficiently reuse all of the resources of an operating system to produce the laziest solution that will likely produce the highest number of obscure edge cases in the future, create unexpected dependencies, and likely scale the worst, then perhaps the shell script wins. But I think Knuth was trying to demonstrate quite the opposite - good coding praxis that can be maintainable, debuggable, and made to scale. I guess what I’m saying is that it’s difficult to see any comparison here, whatsoever, since the purposes were so markedly different. The shell script is not a solution any professional would ship in a product, and would only appeal to lazy one off tasks. Who would have been daft enough firstly, to not read Knuth’s paper, but secondly to think there is anything worth comparing in the first place? The script might be the quickest solution. Knuth’s code is the proper solution.
评论 #31303230 未加载
dalyabout 3 years ago
If you didn&#x27;t know what McIlroy&#x27;s program did would you be able to figure out what it was supposed to do?<p>I&#x27;d like to see the TeX program written in a shell script.
评论 #31303563 未加载
评论 #31303486 未加载
amirathiabout 3 years ago
Jupyter Notebook is THE modern literate programming environment.<p>It&#x27;s a shame that it&#x27;s only primarily used for Data Science experimentation &amp; teaching.
评论 #31302264 未加载
评论 #31302197 未加载
评论 #31305190 未加载
评论 #31303173 未加载
thread_idabout 3 years ago
It occurs to me that part of this debate could be expressed in more modern terms as Declarative vs Imperitive programming.<p>In firstclass languages a complex problem can be solved by chaining together functions and can be written in a single statement (this depends on the implmentation of functions and types that are returned). Somtime 2 or three statements.<p>Versus using core language statements and packages to implement conditional logic, control structures, and operations. Relying less on packages that extend the launguage. Having full control over the implementation.<p>Personally I prefer declarative and wrapping it with verbose inline documentation.<p>One downside to this is maintaining the build environment. Packages are versioned and fucntions change overtime (deprecated in favor of new implmentations that replace the old function). Somtimes Declaritive implementations must be refactored to support newer version of packages.<p>Impertive implementations tend to be more durable and have fewer dependencies.
lynguistabout 3 years ago
LP is in essence live coding, what we have now with Twitch and YouTube.<p>And it has its merits: you see how a problem is tackled.<p>I believe this should be obvious.
评论 #31303813 未加载
评论 #31305662 未加载
kkfxabout 3 years ago
The issue was simply a bad one, because we do not use computers as sport cars in a race, at least we shouldn&#x27;t, we use as daily driver. As a daily driver who constantly change and adapt to changed needs and desire.<p>So Unix classic McIlroy&#x27;s is good for quick run, daily driver who can&#x27;t really evolve much, at least not at a little price. Knuth on it&#x27;s side equally felled in the same trap on the opposite side of the spectrum.<p>The real outcome is that Unix model is wrong, and it&#x27;s a well-known things behind the Unix Hater&#x27;s Handbook simply when unix choose to through it&#x27;s principles in a bin making GUIs from the first CDE and beyond where no small programs nor composability via efficient IPCs is there. Sole IPCs available cut&#x2F;copy&#x2F;paste. The right choice was done before: with Smalltalk systems at Xerox, with Lisp-based systems after them: which means a <i>moderately</i> literate and discoverable environment where anything can be easy integrate in code so where shell-scripting is actually the same of system programming and the literate part, based on literate code, is just literate composition not much different then the classic human notes compositions from Mundaneum to ZettelKasten. That&#x27;s is. Unfortunately since NOBODY want to admit mistakes especially if they was made in the past and imply large areas of development nearly no one want to talk about those terms...
评论 #31303007 未加载
Animatsabout 3 years ago
<i>&quot;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;</i><p>That&#x27;s what computer science in the 1970s and the 1980s was all about. Clever algorithms. Especially at MIT. Read the classic HAKMEM from 1972.[1]<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;HAKMEM" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;HAKMEM</a>
评论 #31308943 未加载
richard_toddabout 3 years ago
Sometimes I do &quot;semi-literate&quot; programming where I don&#x27;t even bother with the commentary. I just use a tangler so I can write the code in the order I want to see it. I really think writing in &quot;human-order&quot; and tangling into &quot;compiler-order&quot; is the bigger benefit to the methodology. It stops you from (for example) writing a function just to break up the logic into manageable parts.
评论 #31306218 未加载
henningabout 3 years ago
McIlroy would have killed it here on Hacker News if it existed back then. &quot;Show HN: 6-line shell script beats 8-page Don Knuth program&quot;
评论 #31302118 未加载
评论 #31303771 未加载
victor9000about 3 years ago
LP sounds like a Jupyter Notebook
评论 #31302161 未加载
评论 #31302181 未加载
评论 #31302213 未加载
评论 #31302171 未加载
ChristopherDrumabout 3 years ago
This seems like as good a thread as any to point out that Inform, one of the largest literate programs to date, was recently published on GitHub. <a href="https:&#x2F;&#x2F;github.com&#x2F;ganelson&#x2F;inform" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ganelson&#x2F;inform</a>
jvandonselabout 3 years ago
What’s the runtime complexity of Knuth’s solution vs the script solution?
olliejabout 3 years ago
I always disliked these comparisons to &quot;shell&quot; scripting that invariably end up comparing a collection of C (or whatever) tools and claiming to have solved the problem in steel script.<p>It&#x27;s nonsense - the various shell scripting languages are more than capable of implementing those various tasks without simply shelling out to C, and so should be required to. Otherwise a C programmer has access to system() and start() and those support pipes even.
smclabout 3 years ago
Yeah the comparison between the shell script and the Pascal&#x2F;LP version is a little bit apples&#x2F;oranges. Maybe a nice counter to that would have been to make an LP version of the script itself. Here&#x27;s a quickly hacked together mashup of the Knuth&#x2F;McIlroy solutions:<p>Given some text input via stdin, we want to find the word that appears most often. The main body of the shell script is as follows - each section uses plain shell utilities and has been developed and tested with (blah blah, maybe mention the version of the utils we used in case GNU versions work but BSD don&#x27;t or something)<p><pre><code> &lt;&lt;makeLines&gt;&gt; | &lt;&lt;convertToLowerCase&gt;&gt; | &lt;&lt;sortAndCountLines&gt;&gt; | &lt;&lt;sortLinesByFrequency&gt;&gt; | &lt;&lt;takeFirst&gt;&gt; </code></pre> The first job is to isolate &quot;words&quot;, defined here as groups of lower case latin alphabet characters (sorry to our international friends out there!) using `tr`. Importantly anything hyphenated will be treated as a separate words (&quot;short-term&quot; will be &quot;short&quot; and &quot;term&quot;, for example), so modify the pattern if this isn&#x27;t what you need.<p><pre><code> &lt;&lt;makeLines&gt;&gt; = tr -cs A-Za-z &#x27;\n&#x27; </code></pre> Next we&#x27;ll make everything in the input lower-case:<p><pre><code> &lt;&lt;convertToLowerCase&gt;&gt; = tr A-Z a-z </code></pre> The next step is to sort the lines so exact words are next to each other, then pipe that into `uniq -c` to get counts for each adjacent line. This is a fairly common pattern so I&#x27;ve bunched these guys together.<p><pre><code> &lt;&lt;sortAlphabeticallyAndCount&gt;&gt; = sort | uniq -c </code></pre> Since we&#x27;re interested in the <i>most</i> frequent we&#x27;re sorting descending (-r aka --reverse. IMPORTANT: not -R aka --random-sort) and numerically (-n)<p><pre><code> &lt;&lt;sortNumerically&gt;&gt; = sort -rn </code></pre> And finally we can take the first line and print it. NOTE: I didn&#x27;t use `head -n 1` here because blah stupid reason whatever<p><pre><code> &lt;&lt;takeFirst&gt;&gt; = sed ${1}q </code></pre> (fin)<p>This is the first time I&#x27;d ever written anything approaching LP (I just copied the style in the article) so I just quickly dashed it out with placeholder comments, though I&#x27;d maybe include a worked example of the program in action too showing the output at each step. Now <i>obviously</i> it&#x27;s longer than the little shell snippet that was posted, but even though it is a relatively tiny problem to apply LP to, you can see that there is still some value to it - I&#x27;ve been able to make it clear that only the latin alphabet is considered, I&#x27;ve highlighted a potential oopsie in case someone inexperienced in tries to re-use it (-r&#x2F;-R), I was able to state that there&#x27;s an alternative approach to the final step and give a reason why I chose my way.
评论 #31307368 未加载
gnufxabout 3 years ago
I haven&#x27;t gone back and read the original after all these years to check the specification, but it&#x27;s perhaps worth noting that at least the McIlroy solution is only valid in the C locale. At least these days you can use character classes. In my experience locales regularly bite people -- even en_GB ones.
pplonski86about 3 years ago
The literate programming is very under rated in Jupyter Notebook. It is mainly used for experiments. I hope that in the future there will be more applications in notebook for example in automation. Can you imagine notebooks replacing services like zapier?
评论 #31302458 未加载
pkruminsabout 3 years ago
I illustrated this epic story: <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>
riksucksabout 3 years ago
I didn&#x27;t even know such a thing like literate programming existed. I wonder if IPython notebooks count as literate programming?
评论 #31303632 未加载