While I can't speak for Knuth, I have been reflecting on the fact that developing with a modern LLM seems to be an evolution of the concept of Literate Programming that Knuth has long been a proponent of.
What is the rationale behind the assertion that Knuth would be so fundamentally opposed to the use of LLMs in development?
In literate programming you meticulously write code (as usual) but present it to a human reader as an essay: as a web of code chunks connected together in a well-defined manner with plenty of informal comments describing your thinking process and the "story" of the program. You write your program but also structure it for other humans to read and to understand.
LLM software development tends to abandon human understanding. It tends to abandon tight abstractions that manage complexity.
Have you ever tried literate programming?
In literate programming you do not write the code then present it to a human reader. You describe your goal, assess various ideas and justify the chosen plan (and oftentimes change your mind in the process), and only after, once the plan is clear, you start to write any code.
Thus the similarity with using LLM.
Working with LLMs is quicker though, not only because you do not write the code but you don't care much about the style of the prose. On the other hand, the code has to be reviewed, debugged and polished. So, Ymmv.
> In literate programming you do not write the code then present it to a human reader. You describe your goal, assess various ideas and justify the chosen plan (and oftentimes change your mind in the process), and only after, once the plan is clear, you start to write any code.
This is not literate programming. The main idea behind literate programming is to explain to a human what you want a computer to do. Code and literate explanations are developed side by side. You certainly don't change your mind in the process (lol).
> Working with LLMs is quicker though
Yes, because you neither invest time into understanding the problem nor conveying your understanding to other humans, which is the whole point of literate programming.
But don't take my word, just read the original.[1]
The irony is that if we had been writing literate programs instead of "normal" programs, from 1984 to 2026, then LLMs may actually have been much better at programming in 2026, than they turned out to be. Literate programs entwine the program code with prose-explanations of that code, while also cross-referencing all dependent code of each chunk. In some sense they make fancy IDEs and editors and LSPs unnecessary, because it is all there in the PDF. They also separate the code from the presentation of the code, meaning that you don't really have to worry about the small layout-details of your code. They even have aspects of version control (Knuth advocates keeping old code inside the literate program, and explaining why you thought it would work and why it does not, and what you replaced it with).
LLMs do not bring us closer to literate programming any more than version-control-systems or IDEs or code-comments do. All of these support-technologies exist because the software industry simply couldn't be disciplined enough to learn how to program in the literate style. And it is hard to want to follow this discipline when 95% of the code that you write, is going to be thrown away, or is otherwise built on a shaky foundation.
Another "problem" with literate programming is that it does not scale by number of contributors. It really is designed for a lone programmer who is setting out to solve an interesting yet difficult problem, and who then needs to explain that solution to colleagues, instead of trying to sell it in the marketplace.
And even if literate programming _did_ scale by number of contributors, very few contributors are good at both programming _and_ writing (even the plain academic writing of computer scientists). In fact Bentley told Knuth (in the 80s) that, "2% of people are good at programming, and 2% of people are good at writing -- literate programming requires a person to be good at both" (so only about 0.04% of the adult population would be capable of doing it).
By the way, Knuth said in a book (Coders at Work, I believe): "If I can program it, then I can understand it." The literate paradigm is about understanding. If you do not program it, and if _you_ do not explain the _choices_ that _you_ made during the programming, then you are not understanding it -- you are just making a computer do _something_, that may or may not be the thing that you want (which is fine, most people use computers in this way: but that makes you a user and not a programmer). When LLMs write large amounts of code for you, you are not programming. And when LLMs explain code for you, you are not programming. You are struggling to not drown in a constantly churning code-base that is being modified a dozen times per day by a bunch of people, some of whom you do not know, many of whom are checked out and are trying to get through their day, and all of whom know that it does not matter because they will hop jobs in one or two or three years, and all their bad decisions become someone else's problem.
Just because LLMs can translate one string of tokens into a different string of tokens, while you are programming does not make them "literate". When I read a Knuthian literate program, I see, not a description of what the code does, but a description what it is supposed to do (and why that is interesting), and how a person reasoned his/her way to a solution, blind-alleys and all. The writer of the literate program anticipates the next question, before I even have it, and anticipates what might be confusing, and phrases it in a few ways.
As the creator of the Axiom math software said: the goal of Literate Programming, is to be able to hire an engineer, give him a 500 page book that contains the entire literate program, send him on a 2 week vacation to Hawaii, and have him come back with whole program in his head. If anything LLMs are making this _less_ of a possibility.
In an industry dominated by deadline-obsessed pseudo-programmers creating for a demo-obsessed audience of pseudo-customers, we cannot possibly create software in a high-quality literate style (no, not even with LLMs, even if they got 10x better _and_ 10x cheaper).
Lamport (of Paxos, Byzantine Generals, Bakery Algo, TLA+), made LaTeX and TLA+, with the intent that they be used together, in the same way that CWEB literate programs are. All of these tools (CWEB, TeX, LaTeX, TLA+), are meant to encourage clear and precise thinking at the level of _code_ and the level of _intent_. This is what makes literate programs (and TLA+ specs) conceptually crisp and easily communicable. Just look at the TLA+ spec for OpenRTOS. Their real time OS is a fraction of the size that it would have been if they had implemented it in the industry-standard way, and it has the nice property of being correct.
Literate Programming, by design, is for creating something that _lasts_, and that has value when executed on the machine and in the mind. LLMs (which are being slowly co-opted by the Agile consulting crowd), are (currently) for the exact opposite: they are for creating something that is going to be worthless after the demo.
I'm only discovering Literate Programming today, but you seem very familiar so I might as well ask: what is the fundamental difference with abundant comments? Is it the linearity of it? I mean documentation type comments at the top of routines or at "checkpoints".
I'm particularly intrigued by your mention of keeping old code around. This is something I haven't found a solution for using git yet; I don't want to pollute the monorepo with "routine_old()"s but, at the same time, I'd like to keep track of why things changed (could be a benchmark).
A good way to think about it is {Program} = {set of functional graphs} X {set of dataflow pipelines}. Think cartesian product of DAG/Fan-In/Fan-Out/DFDs/etc. Usually we write the code and explain the local pieces using comments. The intention in the system-as-a-whole is lost. LP reverses that by saying don't think code; think essay explaining all the interactions in the system-as-a-whole with code embedded in as necessary to implement the intention. That is why it uses terms like "tangle", "weave" etc. to drive home the point that the program is a "meshed network".
To study actual examples of LP see the book C Interfaces and Implementations: Techniques for Creating Reusable Software by David Hanson - https://drh.github.io/cii/
> LLMs do not bring us closer to literate programming...
Without saying that I agree with the person you're responding to, and without claiming to really know what he was saying, I'll say what I think he was suggesting: That a human could do the literate part of literate programming, and the LLM could do the computing part. When (inevitably) the LLM doesn't write bug-free code snippets, the human revises the literate part, followed by the LLM revising the code part.
And of course there would be a version control part of this, too, wherein both the changes to the literate part and the changes to the code parts are there side-by-side, as documentation of how the program evolved.
This is meta so sorry about not actually responding, but thank you for a very well written comment. In this time of slop and rage it's really refreshing to see someone take the time to write (long form for a comment) about something they are clearly knowledgeable and passionate about.
I interpret this comment as talking about prioritization across a broader org. A senior engineer should be able to prioritize inside of their team and adjacent teams. But there is a reason why there are levels of engineer beyond senior - beyond just increased technical judgement, there is increased influence in orgs spanning hundreds or even thousands of engineers.
There is always opportunity for growth in this dimension. For example even the CEO has to build the right skills to convince the board of their priorities.
The article seems to focus too much on the consumer side of the bandwidth equation. I think the real win for Netflix is the aggregate egress bandwidth savings from their DCs. If Netflix can halve their bandwidth (as the article seems to claim) without any appreciable loss in quality, they've just saved substantially in the infrastructure and peering contracts needed to deliver their content. I have no idea how much money Netflix currently spends on bandwidth/CDN, but I'd guess it's certainly in the 100s of millions. I can imagine that Amazon and Apple would be very interested in emulating those savings.
While this is a good idea to prevent folks from brute-forcing their way into your machine, the article is talking about DDoS attacks. If you have 150G pointed at your network the issue isn't going to be your servers. It's going to be congestion at your network links. Your SSH settings and Fail2Ban won't help at all in this case. You'll need something like CloudFlare's DDoS protection to identify and block DDoS requests from ever reaching your network.
EDIT: Oops, just saw that the article does talk about SSH brute-forcing. Your point is quite valid.
Was this in the past week? Because just a few days ago I was experiencing a similar problem. I attempted to access https://rememberthemilk.com and chrome complained about the SSL cert, as I was receiving the cert for their CDN and not for rememberthemilk itself. I couldn't find anyone that could reproduce the issue, but it occurred consistently on my computer regardless of browser. It resolved itself 20 min after I first noticed it, but I'm still really curious as to why it happened in the first place.
Usually the CDN will have a single certificate which then has multiple SAN entries. What can happen depending on the size of the CDN is it can take a long time for the SSL to be added to the SAN entries on all the edge servers. So if a site just starts moving to a CDN they sometimes jump the gun and instead of waiting for all the edge servers to have the SSL they just change DNS records.
You then have a scenario where the DNS is waiting to propagate and the SSL is still propagating around the CDN. Hence you get soem users without a problem, some with and it eventually all clears itself up.
A large part of this is that the Second Amendment to the US Constitution explicitly protects people's right to bear arms. This has led to gun-ownership being an important topic to many American citizens, initially by people using to utilize guns (ranch rifles, etc) and then by collectors and other hobbyists.
As for your second question, the difficultly of obtaining a gun in the US varies largely by state. However, it generally is not exceedingly difficult. As an example, here is how purchasing a firearm works in California:
If you don't mind me asking, what country did you move too that has better personal rights? I know that Canada and most of the EU have a worse track record than the US when it comes to this.
IMHO moving out of the US just avoids the problem, instead of solving it. We need to put more support behind advocacy groups like the EFF who's mission statement is to fight against the infringement of personal rights.
You know that Canada (and the EU) has a worse track record... Can you provide a link to support this rather bold assertion? I am fairly familiar with Canadian law and strongly disagree with your statement.
I have had to deal with Human Rights Commissions in two provinces over the course of 10 years and have never seen anything like what is referenced: HRCs do not have the capacity to access email and documents without the owner of such being informed. Your argument is just an attempt at changing the topic at hand. The orginal comment ended with "when it comes to this" thus referencing warrantless access to email and such.
At least Canada is not involved in wars of aggression and is a relatively peaceful nation (in comparison to the US). The point is not where we are now that is of concern, it's when the shit hits the fan, which will inevitably happen. When this happens, first thing out of the window is personal rights.
Canada is an an interesting choice, until you read some history and realize that every fascist state eventually turns its wars of aggression toward its closest neighbors. The odds that America will turn fascist on its own people, act on continuous wars of aggression globally, but never attack Canada - is roughly zero. It's a matter of time, unless the fascist state creep is rolled back and quickly.
It's a message board comment that says if you believe the US is on its way to being a fascist state, read a history book sometime on exactly how fascist countries operate.
I wouldn't expect it in the next decade. However, if you cycle forward the progression of laws and behavior represented by the last 10 to 15 years, then it seems likely that at a minimum the US will begin to intrude on Canadian sovereignty either through direct or indirect coercion.
Fascist countries don't tend to be very tolerant of their friendly neighbors.
MySQL, though written in C++, reads more like C with classes. Even then, a large portion of the code is procedural instead of OO. They are slowly moving towards an OO style, but it will take a while before a reasonable percentage of the code base has been re-written.
How is this "beyond astonishing"? 27 years is minuscule on in a geologic time scale. Climate trends are measured in hundreds and thousands of years, if not more.
What is the rationale behind the assertion that Knuth would be so fundamentally opposed to the use of LLMs in development?