19 ms·

Donald Knuth was framed

632 points by akalin 7y ago

kick 7y ago
Site's back up.
adonese 7y ago
It seems to be down.
- mark-r 7y ago
  For me too. It's a shame given the inflammatory title - I really want to know what it means.
  - Ari_Rahikkala 7y ago
    My guess is it's either about a picture of Donald Knuth, or Knuth's reward checks, being put in picture frames.
    - ColinWright 7y ago
      Neither.
      - Ari_Rahikkala 7y ago
        Aw. Well, it was worth a shot, that kind of mild homonym abuse is kind of direction that these sorts of titles usually tend to take. Fortunately the real story is more interesting.
draw_down 7y ago
I've seen similar defenses of Knuth over the years, but I'm still inclined to view this McIlroy'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't that what commenters are saying here all the time? Anyway, perhaps I just suffer from a failure of imagination, but I can't see why the "Blah"s interspersed with `foo`s and `bar`s is meant to be revelatory.
- CrazyStat 7y ago
  The job Knuth was asked to do was "write a piece illustrating literate programming." A six line shell script is not the right tool for that job.
- mhd 7y ago
  I think it's meant to promote looking at how a literate programming system is mangling program output. It's way more complicated and powerful than just "inverted comments" (like e.g. CoffeeScript did in recent memory). Composite parts of the final program can be presented out of order, sent to different output files, etc. For something slightly more modern than this sample program or TeX, there's "A Retargetable C Compiler: Design and Implementation", which presentes the code of lcc, a quite conformant C compiler (which, IIRC, still enjoys some popularity on Windows). Sadly the strengths of literate programming are rarely useful for mere mortal programmers -- we're not often entrenched in deriving algorithms and/or presenting something in a didactic manner.
giancarlostoro 7y ago
If anyone managed to catch it when it wasn't down, care to share a screenshot of the article? I seem to be getting some Heroku error now. > 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
- aWidebrant 7y ago
  Lightly edited: https://rentry.co/zq4r6 https://rentry.co/zq4r6
ColinWright 7y ago
It seems to have the "HN Hug of Death" ... here's a snapshot summary from memory: 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. 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. Edit bonyt's[0] comment[1] has links to copies of the content. [0] https://news.ycombinator.com/user?id=bonyt https://news.ycombinator.com/user?id=bonyt [1] https://news.ycombinator.com/item?id=22406365 https://news.ycombinator.com/item?id=22406365
- hprotagonist 7y ago
  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.
persona 7y ago
Title is a little (?) clickbait... Promoting a YOW talk: https://www.youtube.com/watch?v=ATobswwFwQA https://www.youtube.com/watch?v=ATobswwFwQA -- The other day I was talking with a friend about structured editing and literate programming came up. LP was one of Donald Knuth'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: https://en.wikipedia.org/wiki/Literate_programming https://en.wikipedia.org/wiki/Literate_programming "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's solution, his choice of a data structure (Frank M. Liang'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: >>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." The program was print out the top K most-used words in a text. (and so it goes on...) ---
- hwayne 7y ago
  To clarify, it was an email newsletter. The YOW! thing had just gotten published so I got that out of the way before diving into the meat of the newsletter post, which was about LP.
bonyt 7y 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. Hastily converted to markdown with pandoc, and put up as a github gist: https://gist.github.com/tonyb486/eec2f16b06eef4692dac6e56362cac50 https://gist.github.com/tonyb486/eec2f16b06eef4692dac6e56362... [1]: https://web.archive.org/web/*/https://buttondown.email/hillelwayne/archive/donald-knuth-was-framed/ https://web.archive.org/web/*/https://buttondown.email/hille...
- segfaultbuserr 7y ago
  > It looks like archive.org got it. But the entire page is blank, because JavaScript. The AJAXification of the web, even for trivial web pages, is defeating archive.org on multiple occasions, it's a huge threat to our history preservation. We cannot stop people from overusing AJAX, and we need to develop better archival tools.
  - DelightOne 7y ago
    I'm wondering.. is there a way to use the archive.org tools to download the website and later transfer it to my own database to not take up too much space in the archive? If thats not possible then the archive controller alone is in control of history.
  - rtkwe 7y ago
    > we need to develop better archival tools. That's the only real solution. Trying to redirect the whole ecosystem on to a more convenient path is doomed to fail unless your path is actually easier or better in some way.
    - marcosdumay 7y ago
      > unless your path is actually easier or better in some way Well, I would argue it is, in nearly every way. The largest drawback is that by avoiding pulling the content with JS you won't automatically deny service to people that are trying to avoid trackers... This site looks like a medium wannabe, so this is probably important to them.
btilly 7y 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. Except that this one is extreme. It is hard to find any programmer who builds a more perfect tool than Knuth. There isn'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. 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't need armor, they should put it on where the bombers were hit and didn't come back. Which, assuming that bombers were hit evenly everywhere, was all the places that they didn't find holes. 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'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't find the bombers.
- pdpi 7y ago
  > 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. Nope, this is nothing of the sort. It's just a case of two people solving two different (if related) problems, and everybody else trying to draw (by necessity, completely worthless) conclusions by comparing solutions to different problems. McIlroy solved the K most common words problem. Knuth used a from-the-ground-up solution to that problem as a way to illustrate how Literate Programming works. His solution was never meant to be as tiny as McIlroy's, it needed enough meat on it that LP actually did something non-trivial.
  - btilly 7y ago
    You missed my point. I was not saying that this story is a good example of that ongoing dynamic. But instead that there is such a dynamic in our industry, and the telling of the story resonates well with it.
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.
gameswithgo 7y 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.
lalalandland 7y 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.
smsm42 7y ago
I'm not sure how it's a fair comparison between ready-made Unix tools and written-from-scratch solution. I mean it's like somebody asked me to implement a C compiler, and when I produced a huge pile of source code would tell me "Idiot, I can do all that by just typing "gcc"! Muah-hah-ha!"
- dllthomas 7y ago
  In my second compiler design course, we were told we could use any language. I (jokingly) asked whether we could choose shell, and consider a C compiler a feature of the language. I was (in the same spirit) informed that it would be cheating.
  - smsm42 7y ago
    Some languages do include self-compilers as part of the runtime... So probably "any" wasn't meant really "any".
    - dllthomas 7y ago
      The target language was (a subset of) C, so access to a lisp compiler wasn't going to help in quite the same way.
- hobofan 7y ago
  It's a fair comparison in a real world context. If you were to solve the problem at your job, would you start writing the program from scratch, or would you use ready-made tools made for the job?
  - smsm42 7y ago
    It's not Knuth's job to write efficient word-sorting programs. That job is long done and now it's nobody's job (unless one can do better than existing tools, but that wasn't Knuth goal either). His job was to demonstrate how you do literate programming, which is completely different. If I needed to demo how to program certain algorithm so that I could explain it to students, I'd write one code, if I needed absolutely fastest possible tool, I'd write another code (probably in C or some asm even). Different tasks - different approaches.
Myrmornis 7y ago
> 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. Now imagine if these stream-of-consciousness comments getting in the way of the code were written by your colleagues, rather than Donald Knuth.
- Jtsummers 7y ago
  Like all documentation, in real systems it would be edited over time. You do develop documentation for your systems, right?
  - Myrmornis 7y ago
    My point is that people should be encouraged to keep code comments to a minimum, and always strive to first rewrite the code so that it is clear (well-chosen variable names, etc). LP does the opposite: it encourages verbosity, and tangential discussion.
    - Jtsummers 7y ago
      My point is that literate programming isn't about comments. Comments are asides, they aren't the core focus of what's being read, the code is. Literate programming is about documentation, which should be kept concise, but not necessarily minimal. As to whether this leads to tangents or not, that's up to the authors to determine how to organize. Appendices or rationale sections are a great way to separate the core focus from what others may see as extraneous.
      - Myrmornis 7y ago
        Yes, sorry, I did understand that that was your point. I just feel very strongly about the tendency, for people (especially new programmers) to be told that it's important to comment code heavily. Yes I've never seen a good solution for documentation in the teams I've worked in on larger systems/codebases. I'm not really a believer in documentation that evolves in a separate git repo (or god forbid, in Confluence) for the obvious reason that it gets even more stale than documentation that evolves in the same git repo. So that would put me in favour of your position here. But, how can documentation (with appendices or rationale sections) be interleaved with code without destroying the ability to read the code? I've tried RWeave in R a long time ago, and I've even collaborated and published on a literate programming tool, and I have always come back to the conclusion that I want to read code with the minimum of intervening prose. So my position is documentation should absolutely be written and maintained, it should be in the same git repo as the code, it should be in a separate file (not in comments or docstrings or automagically weaved sections using some special syntax), it should be written tersely and without much personality, and code reviewers should request documentation updates if a PR renders some documentation stale or requires new documentation. So I'm pro documentation, anti LP, and pro minimal code commenting.
geofft 7y ago
Something related that'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 future changes right, either by someone else, or even yourself when you've forgotten how to do it. But future changes only matter if you want to use the existing program as a starting point. McIlroy'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'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.) An implication is that, if you're in a language where you can write a productive program to do a task from scratch within (say) 30 minutes, there's a lot less of a reason to think about good programming design than if you'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're done with it and still solve the modified problem within 30 minutes. Another possible implication: it's better to build reusable components (libraries and utilities) than easily-modifiable code. Part of why McIlroy's pipeline works so well is that tools like "tr" and "uniq" 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't need to know their internals.
- jeffdavis 7y ago
  What you are describing may say more about the problem definition than the rate of change. If the software will only be used in certain limited situations, then you can make a bunch of assumptions and assemble the solution from spare parts. As long as your assumptions hold everything is fine. When the assumptions fail, someone will tell you, and you can rewrite it with the new assumptions in mind. But some software might be used in a lot of strange environments with strange inputs. A lot of effort needs to be spent trying to clarify and improve semantic and performance edge cases. Using libraries here is not necessarily helpful because sometimes you spend more time working around the edge cases in the library than you would just re-implementing it. I recently re-implemented a minheap even though there was already a library readily available, because the library assumed pointer-width types and I needed it to support longs. On my machine, a pointer and a long are the same length, but that's not guaranteed.
FabHK 7y ago
Does anyone have any insight in the computational complexity of the two solutions? 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. It seems to me an optimal solution could be faster, and I wonder what Knuth implemented.
- terminaljunkid 7y ago
  If you consider hash table insertion as O(1) then it is O(n) I guess.
jesse_m 7y ago
I haven'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: https://github.com/thblt/org-babel-tangle.py https://github.com/thblt/org-babel-tangle.py
- dannyobrien 7y ago
  It's worth playing with: it's primarily designed for writing literate Python, and I greatly enjoyed working with it on a project as an experiment. I shuttle between neovim, emacs and leo, and dream of an editor that would somehow bring together all of their benefits. Oh, and maybe some smalltalk too!
kazinator 7y ago
The shell script uses utilities that are written in C, probably totaling way more lines of system programming language code than Knuth's Pascal solution. It'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. The has trie structure was included in it for that purpose, to show how you use literate programming to annotate such a thing. > First of all, we found that Literate Programming as conceived by Knuth not just “text, code, text, code”. Unfortunately, it's something worse! It'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. Like, say: The program's overall structure is to accept input, performs some processing and produce output: accept_input do_processing produce_output The divisions don't follow function boundaries. A specific loop inside a specific function might have its own section, and the variable declarations above their own. It's basically horrible. You can't see the code all in one piece at all when editing it. It won't play with your existing tools. The generated result won't even have proper indentation. 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. What you'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'etre is that paper though. You would be suicidal to use this to write an actual application that doesn't need to be detailed in an academic paper. Knuth did somewhat take it to those extremes, but working alone. 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.
- svat 7y ago
  I love this comment, and probably wouldn't even disagree with "It's basically horrible" :), but just to point out a few things: - "The generated result won't even have proper indentation." Actually, what you see in the typeset output generated by weave/cweave is what Knuth considers proper indentation, and he has written paeans multiple times to Myrtle Kellington (executive editor for ACM publications) who developed that style, etc. There are a lot of lines in WEAVE devoted to getting the indentation exactly so. I personally find it hard to read as well (as I imagine do most programmers), and both McIlroy in his review ("Second, small assignment statements are grouped several to the line with no particularly clear rationale. This convention saves space; but the groupings impose a false and distracting phrasing...") and Harold Thimbleby in his Cweb article mention these departures from what C (etc) programmers are used to. - "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." I would disagree: yes they are geared towards someone who is an academic -- specifically Knuth -- but from everything he's said, his love of LP is about the programs themselves, not papers about them. (Look at https://cs.stanford.edu/~knuth/programs.html https://cs.stanford.edu/~knuth/programs.html for some of his programs; he says he writes several programs a week and keeps most of them to himself; the ones published online before Sep 2017 I had typeset here: https://github.com/shreevatsa/knuth-literate-programs https://github.com/shreevatsa/knuth-literate-programs -- I ought to clean up and refresh that stuff.) - Finally, WEB arose out of certain specific constraints. After he had written the original version of TeX in SAIL for his personal use, it turned out there was widespread demand for it, and people at other places had started porting it into their local systems/languages (with risk of incompatible/irreproducible implementations). For this he decided to embark on a two-year rewrite into the language that was available at the most number of university computer systems: Pascal. This language had been designed primarily for teaching, and at this time there wasn't even a Pascal standard by that name -- every compiler did its own thing. So he was targeting the "common denominator" of Pascal compilers, which meant no separate compilation units to be linked in; everything had to be in a single file at least as seen by the compiler. (In fact his TeX78 in SAIL had been written as several separate files in a more conventional (to us) style.) And yeah, the fact that he had been requested to eventually publish the source code of TeX (which he did, Volume B of Computers and Typesetting) played a part. BTW the author/maintainer of Axiom (https://en.wikipedia.org/wiki/Axiom_(computer_algebra_system) https://en.wikipedia.org/wiki/Axiom_(computer_algebra_system...) has been writing it for years in a literate programming style, and whether that is insane/suicidal is beyond my ability to judge at the present. :-)
aortega 7y ago
You cannot compare Knuth's software with a script that use pre compiled tools that have thousands of lines. If you want to compare both solutions, use the Kolmogorov complexity: compress both programs together with any tool/compiler it uses and just then, compare both sizes. I bet Knuth's solution has an order of magnitude less complexity.
dracodoc 7y 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. This serve as a very good documentation and is much better than code comments.
brisky 7y 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: https://github.com/tautvilas/lingu/blob/master/examples/todomvc/prog.lgu https://github.com/tautvilas/lingu/blob/master/examples/todo...
ben509 7y ago
These days, though, you can have it both ways with a Jupyter notebook or something similar. It's literate, in that you can keep thoughts and discussion in markdown cells, and you can neatly combine computations in computation cells.
dllthomas 7y 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's presented is really interesting. 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).
hzhou321 7y ago
> Writing the code out-of-order is the whole point. Yes! MyDef, https://github.com/hzhou/MyDef https://github.com/hzhou/MyDef, is such a system.
pkrumins 7y ago
KNUTH vs MCILROY https://comic.browserling.com/knuth-vs-mcilroy.png https://comic.browserling.com/knuth-vs-mcilroy.png WHO WILL WIN?!
shp0ngle 7y ago
I will probably be downvoted for questioning the legends, but... I don't think the poster child of Literate Programming - TeX itself - really has that readable source code. https://mirror-hk.koddos.net/CTAN/systems/knuth/dist/tex/tex.web https://mirror-hk.koddos.net/CTAN/systems/knuth/dist/tex/tex...
- zimpenfish 7y ago
  I think the "source code" of TeX would be either the WEB files or the formatted output (ie "TeX: The Program") rather than the TeX output from WEB.
  - shp0ngle 7y ago
    This IS the web file, no? (and if not, where are the web files?)
    - zimpenfish 7y ago
      My apologies! I misread the file and thought it was the TeX output from the WEB. You are completely correct, that's the WEB file.
- svat 7y ago
  The .web file is not supposed to be read directly. You're supposed to read the "woven" version: https://texdoc.net/texmf-dist/doc/generic/knuth/tex/tex.pdf https://texdoc.net/texmf-dist/doc/generic/knuth/tex/tex.pdf
  - guitarbill 7y ago
    If you have to make changes to it, you'd have to read it directly, right?
    - svat 7y ago
      I think the idea is that if you want to make changes to an existing program, you get up from your desk, go look at your shelves and pull out the sheaf of paper for that program, read/study it, think about what changes are needed, write down the code changes, then go to the computer and type it up -- only in the last step you're looking at the .web file but only for mechanical transcription from paper to computer. (This is not a joke. Knuth still writes not just his papers/books but even his programs by hand on paper first. And this how TeX was written, according to the person other than Knuth who should know best: https://news.ycombinator.com/item?id=10172924 https://news.ycombinator.com/item?id=10172924)
lincpa 7y ago
Markdown Literary Programming that don't break the syntax of any programming language https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/markdown_literary_programming.md https://github.com/linpengcheng/PurefunctionPipelineDataflow...
rswail 7y ago
Maybe people should take into account that Knuth is a mathematician and computer scientist, not a software engineer. His constraint is correctness under all circumstances, an engineering constraint is about efficiency which constrains correctness to a subset of the potential uses. 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. Personally, I think most software "engineering" is a crock, built on false assumptions and invalid data, subject to fads like "Agile" (or CMMI or SPICE or RUP or...). 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.
mcv 7y ago
Comparing Knuth's LP demo to a 6 line shell script is comparing apples to oranges. There's no language that's going to be able to do that job in as few lines as that shell script, but that doesn't mean all languages are useless. They're both interesting demonstrations, but it's a useless comparison.
DSpinellis 7y 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 https://www.spinellis.gr/blog/20200225/ https://www.spinellis.gr/blog/20200225/
paulrpotts 7y ago
Good analysis. Didn't Knuth famously say that his job was to get to the bottom of things, not to stay on top of things? 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. 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.
rstuart4133 7y ago
I was around when that encounter happened. I still recall my feelings when I read it. I don't recall feeling Knuth was framed. Although McIlroy's solution didn't really address the question Knuth was asked, it was cute and demonstrated the power of this newfangled thing called "Unix Philosophy", 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. I do remember wondering if Bentley had done the right thing in publishing McIlroy'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 "Programming Pearls" if he didn't report exactly what happened, as it happened. Bentely's style wasn'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's problem.

632 points by akalin 7y ago

kick 7y ago

Site's back up.

adonese 7y ago

It seems to be down.

mark-r 7y ago
For me too. It's a shame given the inflammatory title - I really want to know what it means.
- Ari_Rahikkala 7y ago
  My guess is it's either about a picture of Donald Knuth, or Knuth's reward checks, being put in picture frames.
  - ColinWright 7y ago
    Neither.
    - Ari_Rahikkala 7y ago
      Aw. Well, it was worth a shot, that kind of mild homonym abuse is kind of direction that these sorts of titles usually tend to take. Fortunately the real story is more interesting.

draw_down 7y ago

I've seen similar defenses of Knuth over the years, but I'm still inclined to view this McIlroy'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't that what commenters are saying here all the time? Anyway, perhaps I just suffer from a failure of imagination, but I can't see why the "Blah"s interspersed with `foo`s and `bar`s is meant to be revelatory.

CrazyStat 7y ago
The job Knuth was asked to do was "write a piece illustrating literate programming." A six line shell script is not the right tool for that job.
mhd 7y ago
I think it's meant to promote looking at how a literate programming system is mangling program output. It's way more complicated and powerful than just "inverted comments" (like e.g. CoffeeScript did in recent memory). Composite parts of the final program can be presented out of order, sent to different output files, etc. For something slightly more modern than this sample program or TeX, there's "A Retargetable C Compiler: Design and Implementation", which presentes the code of lcc, a quite conformant C compiler (which, IIRC, still enjoys some popularity on Windows). Sadly the strengths of literate programming are rarely useful for mere mortal programmers -- we're not often entrenched in deriving algorithms and/or presenting something in a didactic manner.

giancarlostoro 7y ago

If anyone managed to catch it when it wasn't down, care to share a screenshot of the article? I seem to be getting some Heroku error now. > 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

aWidebrant 7y ago
Lightly edited: https://rentry.co/zq4r6 https://rentry.co/zq4r6

ColinWright 7y ago

It seems to have the "HN Hug of Death" ... here's a snapshot summary from memory: 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. 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. Edit bonyt's[0] comment[1] has links to copies of the content. [0] https://news.ycombinator.com/user?id=bonyt https://news.ycombinator.com/user?id=bonyt [1] https://news.ycombinator.com/item?id=22406365 https://news.ycombinator.com/item?id=22406365

hprotagonist 7y ago
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.

persona 7y ago

Title is a little (?) clickbait... Promoting a YOW talk: https://www.youtube.com/watch?v=ATobswwFwQA https://www.youtube.com/watch?v=ATobswwFwQA -- The other day I was talking with a friend about structured editing and literate programming came up. LP was one of Donald Knuth'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: https://en.wikipedia.org/wiki/Literate_programming https://en.wikipedia.org/wiki/Literate_programming "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's solution, his choice of a data structure (Frank M. Liang'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: >>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." The program was print out the top K most-used words in a text. (and so it goes on...) ---

hwayne 7y ago
To clarify, it was an email newsletter. The YOW! thing had just gotten published so I got that out of the way before diving into the meat of the newsletter post, which was about LP.

bonyt 7y 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. Hastily converted to markdown with pandoc, and put up as a github gist: https://gist.github.com/tonyb486/eec2f16b06eef4692dac6e56362cac50 https://gist.github.com/tonyb486/eec2f16b06eef4692dac6e56362... [1]: https://web.archive.org/web/*/https://buttondown.email/hillelwayne/archive/donald-knuth-was-framed/ https://web.archive.org/web/*/https://buttondown.email/hille...

segfaultbuserr 7y ago
> It looks like archive.org got it. But the entire page is blank, because JavaScript. The AJAXification of the web, even for trivial web pages, is defeating archive.org on multiple occasions, it's a huge threat to our history preservation. We cannot stop people from overusing AJAX, and we need to develop better archival tools.
- DelightOne 7y ago
  I'm wondering.. is there a way to use the archive.org tools to download the website and later transfer it to my own database to not take up too much space in the archive? If thats not possible then the archive controller alone is in control of history.
- rtkwe 7y ago
  > we need to develop better archival tools. That's the only real solution. Trying to redirect the whole ecosystem on to a more convenient path is doomed to fail unless your path is actually easier or better in some way.
  - marcosdumay 7y ago
    > unless your path is actually easier or better in some way Well, I would argue it is, in nearly every way. The largest drawback is that by avoiding pulling the content with JS you won't automatically deny service to people that are trying to avoid trackers... This site looks like a medium wannabe, so this is probably important to them.

btilly 7y 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. Except that this one is extreme. It is hard to find any programmer who builds a more perfect tool than Knuth. There isn'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. 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't need armor, they should put it on where the bombers were hit and didn't come back. Which, assuming that bombers were hit evenly everywhere, was all the places that they didn't find holes. 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'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't find the bombers.

pdpi 7y ago
> 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. Nope, this is nothing of the sort. It's just a case of two people solving two different (if related) problems, and everybody else trying to draw (by necessity, completely worthless) conclusions by comparing solutions to different problems. McIlroy solved the K most common words problem. Knuth used a from-the-ground-up solution to that problem as a way to illustrate how Literate Programming works. His solution was never meant to be as tiny as McIlroy's, it needed enough meat on it that LP actually did something non-trivial.
- btilly 7y ago
  You missed my point. I was not saying that this story is a good example of that ongoing dynamic. But instead that there is such a dynamic in our industry, and the telling of the story resonates well with it.

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.

gameswithgo 7y 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.

lalalandland 7y 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.

smsm42 7y ago

I'm not sure how it's a fair comparison between ready-made Unix tools and written-from-scratch solution. I mean it's like somebody asked me to implement a C compiler, and when I produced a huge pile of source code would tell me "Idiot, I can do all that by just typing "gcc"! Muah-hah-ha!"

dllthomas 7y ago
In my second compiler design course, we were told we could use any language. I (jokingly) asked whether we could choose shell, and consider a C compiler a feature of the language. I was (in the same spirit) informed that it would be cheating.
- smsm42 7y ago
  Some languages do include self-compilers as part of the runtime... So probably "any" wasn't meant really "any".
  - dllthomas 7y ago
    The target language was (a subset of) C, so access to a lisp compiler wasn't going to help in quite the same way.
hobofan 7y ago
It's a fair comparison in a real world context. If you were to solve the problem at your job, would you start writing the program from scratch, or would you use ready-made tools made for the job?
- smsm42 7y ago
  It's not Knuth's job to write efficient word-sorting programs. That job is long done and now it's nobody's job (unless one can do better than existing tools, but that wasn't Knuth goal either). His job was to demonstrate how you do literate programming, which is completely different. If I needed to demo how to program certain algorithm so that I could explain it to students, I'd write one code, if I needed absolutely fastest possible tool, I'd write another code (probably in C or some asm even). Different tasks - different approaches.

Myrmornis 7y ago

> 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. Now imagine if these stream-of-consciousness comments getting in the way of the code were written by your colleagues, rather than Donald Knuth.

Jtsummers 7y ago
Like all documentation, in real systems it would be edited over time. You do develop documentation for your systems, right?
- Myrmornis 7y ago
  My point is that people should be encouraged to keep code comments to a minimum, and always strive to first rewrite the code so that it is clear (well-chosen variable names, etc). LP does the opposite: it encourages verbosity, and tangential discussion.
  - Jtsummers 7y ago
    My point is that literate programming isn't about comments. Comments are asides, they aren't the core focus of what's being read, the code is. Literate programming is about documentation, which should be kept concise, but not necessarily minimal. As to whether this leads to tangents or not, that's up to the authors to determine how to organize. Appendices or rationale sections are a great way to separate the core focus from what others may see as extraneous.
    - Myrmornis 7y ago
      Yes, sorry, I did understand that that was your point. I just feel very strongly about the tendency, for people (especially new programmers) to be told that it's important to comment code heavily. Yes I've never seen a good solution for documentation in the teams I've worked in on larger systems/codebases. I'm not really a believer in documentation that evolves in a separate git repo (or god forbid, in Confluence) for the obvious reason that it gets even more stale than documentation that evolves in the same git repo. So that would put me in favour of your position here. But, how can documentation (with appendices or rationale sections) be interleaved with code without destroying the ability to read the code? I've tried RWeave in R a long time ago, and I've even collaborated and published on a literate programming tool, and I have always come back to the conclusion that I want to read code with the minimum of intervening prose. So my position is documentation should absolutely be written and maintained, it should be in the same git repo as the code, it should be in a separate file (not in comments or docstrings or automagically weaved sections using some special syntax), it should be written tersely and without much personality, and code reviewers should request documentation updates if a PR renders some documentation stale or requires new documentation. So I'm pro documentation, anti LP, and pro minimal code commenting.

geofft 7y ago

Something related that'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 future changes right, either by someone else, or even yourself when you've forgotten how to do it. But future changes only matter if you want to use the existing program as a starting point. McIlroy'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'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.) An implication is that, if you're in a language where you can write a productive program to do a task from scratch within (say) 30 minutes, there's a lot less of a reason to think about good programming design than if you'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're done with it and still solve the modified problem within 30 minutes. Another possible implication: it's better to build reusable components (libraries and utilities) than easily-modifiable code. Part of why McIlroy's pipeline works so well is that tools like "tr" and "uniq" 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't need to know their internals.

jeffdavis 7y ago
What you are describing may say more about the problem definition than the rate of change. If the software will only be used in certain limited situations, then you can make a bunch of assumptions and assemble the solution from spare parts. As long as your assumptions hold everything is fine. When the assumptions fail, someone will tell you, and you can rewrite it with the new assumptions in mind. But some software might be used in a lot of strange environments with strange inputs. A lot of effort needs to be spent trying to clarify and improve semantic and performance edge cases. Using libraries here is not necessarily helpful because sometimes you spend more time working around the edge cases in the library than you would just re-implementing it. I recently re-implemented a minheap even though there was already a library readily available, because the library assumed pointer-width types and I needed it to support longs. On my machine, a pointer and a long are the same length, but that's not guaranteed.

FabHK 7y ago

Does anyone have any insight in the computational complexity of the two solutions? 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. It seems to me an optimal solution could be faster, and I wonder what Knuth implemented.

terminaljunkid 7y ago
If you consider hash table insertion as O(1) then it is O(n) I guess.

jesse_m 7y ago

I haven'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: https://github.com/thblt/org-babel-tangle.py https://github.com/thblt/org-babel-tangle.py

dannyobrien 7y ago
It's worth playing with: it's primarily designed for writing literate Python, and I greatly enjoyed working with it on a project as an experiment. I shuttle between neovim, emacs and leo, and dream of an editor that would somehow bring together all of their benefits. Oh, and maybe some smalltalk too!

kazinator 7y ago

The shell script uses utilities that are written in C, probably totaling way more lines of system programming language code than Knuth's Pascal solution. It'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. The has trie structure was included in it for that purpose, to show how you use literate programming to annotate such a thing. > First of all, we found that Literate Programming as conceived by Knuth not just “text, code, text, code”. Unfortunately, it's something worse! It'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. Like, say: The program's overall structure is to accept input, performs some processing and produce output: accept_input do_processing produce_output The divisions don't follow function boundaries. A specific loop inside a specific function might have its own section, and the variable declarations above their own. It's basically horrible. You can't see the code all in one piece at all when editing it. It won't play with your existing tools. The generated result won't even have proper indentation. 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. What you'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'etre is that paper though. You would be suicidal to use this to write an actual application that doesn't need to be detailed in an academic paper. Knuth did somewhat take it to those extremes, but working alone. 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.

svat 7y ago
I love this comment, and probably wouldn't even disagree with "It's basically horrible" :), but just to point out a few things: - "The generated result won't even have proper indentation." Actually, what you see in the typeset output generated by weave/cweave is what Knuth considers proper indentation, and he has written paeans multiple times to Myrtle Kellington (executive editor for ACM publications) who developed that style, etc. There are a lot of lines in WEAVE devoted to getting the indentation exactly so. I personally find it hard to read as well (as I imagine do most programmers), and both McIlroy in his review ("Second, small assignment statements are grouped several to the line with no particularly clear rationale. This convention saves space; but the groupings impose a false and distracting phrasing...") and Harold Thimbleby in his Cweb article mention these departures from what C (etc) programmers are used to. - "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." I would disagree: yes they are geared towards someone who is an academic -- specifically Knuth -- but from everything he's said, his love of LP is about the programs themselves, not papers about them. (Look at https://cs.stanford.edu/~knuth/programs.html https://cs.stanford.edu/~knuth/programs.html for some of his programs; he says he writes several programs a week and keeps most of them to himself; the ones published online before Sep 2017 I had typeset here: https://github.com/shreevatsa/knuth-literate-programs https://github.com/shreevatsa/knuth-literate-programs -- I ought to clean up and refresh that stuff.) - Finally, WEB arose out of certain specific constraints. After he had written the original version of TeX in SAIL for his personal use, it turned out there was widespread demand for it, and people at other places had started porting it into their local systems/languages (with risk of incompatible/irreproducible implementations). For this he decided to embark on a two-year rewrite into the language that was available at the most number of university computer systems: Pascal. This language had been designed primarily for teaching, and at this time there wasn't even a Pascal standard by that name -- every compiler did its own thing. So he was targeting the "common denominator" of Pascal compilers, which meant no separate compilation units to be linked in; everything had to be in a single file at least as seen by the compiler. (In fact his TeX78 in SAIL had been written as several separate files in a more conventional (to us) style.) And yeah, the fact that he had been requested to eventually publish the source code of TeX (which he did, Volume B of Computers and Typesetting) played a part. BTW the author/maintainer of Axiom (https://en.wikipedia.org/wiki/Axiom_(computer_algebra_system) https://en.wikipedia.org/wiki/Axiom_(computer_algebra_system...) has been writing it for years in a literate programming style, and whether that is insane/suicidal is beyond my ability to judge at the present. :-)

aortega 7y ago

You cannot compare Knuth's software with a script that use pre compiled tools that have thousands of lines. If you want to compare both solutions, use the Kolmogorov complexity: compress both programs together with any tool/compiler it uses and just then, compare both sizes. I bet Knuth's solution has an order of magnitude less complexity.

dracodoc 7y 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. This serve as a very good documentation and is much better than code comments.

brisky 7y 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: https://github.com/tautvilas/lingu/blob/master/examples/todomvc/prog.lgu https://github.com/tautvilas/lingu/blob/master/examples/todo...

ben509 7y ago

These days, though, you can have it both ways with a Jupyter notebook or something similar. It's literate, in that you can keep thoughts and discussion in markdown cells, and you can neatly combine computations in computation cells.

dllthomas 7y 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's presented is really interesting. 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).

hzhou321 7y ago

> Writing the code out-of-order is the whole point. Yes! MyDef, https://github.com/hzhou/MyDef https://github.com/hzhou/MyDef, is such a system.

pkrumins 7y ago

KNUTH vs MCILROY https://comic.browserling.com/knuth-vs-mcilroy.png https://comic.browserling.com/knuth-vs-mcilroy.png WHO WILL WIN?!

shp0ngle 7y ago

I will probably be downvoted for questioning the legends, but... I don't think the poster child of Literate Programming - TeX itself - really has that readable source code. https://mirror-hk.koddos.net/CTAN/systems/knuth/dist/tex/tex.web https://mirror-hk.koddos.net/CTAN/systems/knuth/dist/tex/tex...

zimpenfish 7y ago
I think the "source code" of TeX would be either the WEB files or the formatted output (ie "TeX: The Program") rather than the TeX output from WEB.
- shp0ngle 7y ago
  This IS the web file, no? (and if not, where are the web files?)
  - zimpenfish 7y ago
    My apologies! I misread the file and thought it was the TeX output from the WEB. You are completely correct, that's the WEB file.
svat 7y ago
The .web file is not supposed to be read directly. You're supposed to read the "woven" version: https://texdoc.net/texmf-dist/doc/generic/knuth/tex/tex.pdf https://texdoc.net/texmf-dist/doc/generic/knuth/tex/tex.pdf
- guitarbill 7y ago
  If you have to make changes to it, you'd have to read it directly, right?
  - svat 7y ago
    I think the idea is that if you want to make changes to an existing program, you get up from your desk, go look at your shelves and pull out the sheaf of paper for that program, read/study it, think about what changes are needed, write down the code changes, then go to the computer and type it up -- only in the last step you're looking at the .web file but only for mechanical transcription from paper to computer. (This is not a joke. Knuth still writes not just his papers/books but even his programs by hand on paper first. And this how TeX was written, according to the person other than Knuth who should know best: https://news.ycombinator.com/item?id=10172924 https://news.ycombinator.com/item?id=10172924)

lincpa 7y ago

Markdown Literary Programming that don't break the syntax of any programming language https://github.com/linpengcheng/PurefunctionPipelineDataflow/blob/master/doc/markdown_literary_programming.md https://github.com/linpengcheng/PurefunctionPipelineDataflow...

rswail 7y ago

Maybe people should take into account that Knuth is a mathematician and computer scientist, not a software engineer. His constraint is correctness under all circumstances, an engineering constraint is about efficiency which constrains correctness to a subset of the potential uses. 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. Personally, I think most software "engineering" is a crock, built on false assumptions and invalid data, subject to fads like "Agile" (or CMMI or SPICE or RUP or...). 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.

mcv 7y ago

Comparing Knuth's LP demo to a 6 line shell script is comparing apples to oranges. There's no language that's going to be able to do that job in as few lines as that shell script, but that doesn't mean all languages are useless. They're both interesting demonstrations, but it's a useless comparison.

DSpinellis 7y 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 https://www.spinellis.gr/blog/20200225/ https://www.spinellis.gr/blog/20200225/

paulrpotts 7y ago

Good analysis. Didn't Knuth famously say that his job was to get to the bottom of things, not to stay on top of things? 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. 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.

rstuart4133 7y ago

I was around when that encounter happened. I still recall my feelings when I read it. I don't recall feeling Knuth was framed. Although McIlroy's solution didn't really address the question Knuth was asked, it was cute and demonstrated the power of this newfangled thing called "Unix Philosophy", 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. I do remember wondering if Bentley had done the right thing in publishing McIlroy'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 "Programming Pearls" if he didn't report exactly what happened, as it happened. Bentely's style wasn'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's problem.