Someone Predicted It in 1978: Natural Language Programming Is Foolish

Dijkstra's old essay warns: the vagueness of natural language programming persists, and the difficulty shifts to verification.
The article discusses the current wave of large-model-driven natural language programming, prompted by the renewed popularity on Hacker News of Dijkstra's 1978 essay *On the Foolishness of "Natural Language Programming." Dijkstra's core argument: natural language evolved for vague human communication, while programs require precise, unambiguous, mechanically executable instructions; treating natural language as a programming language misunderstands the nature of programming; the difficulty lies in formalizing vague intentions into precise logic, not in typing syntax. Commenters see the current narrative as highly isomorphic to Dijkstra's critique: generating code is easier, but correctness still depends on precise expression of requirements, with complexity shifting from syntax to verification. The article draws three insights: don't market natural language input as "no precise thinking needed"; verification capability is a stronger moat than generation quality; and the boundary between natural and formal language must be respected.

Today, with AI coding assistants springing up everywhere, "writing code in natural language" is being packaged as a revolution. But back in 1978, computer science pioneer Edsger W. Dijkstra wrote a short essay titled On the Foolishness of "Natural Language Programming" (EWD667), pouring cold water on the idea that "if machines can understand human language, they can program." This old essay recently sparked renewed heated discussion on Hacker News, garnering 335 upvotes and 224 comments. The reason it can still hit a nerve nearly half a century later is that the current wave of large-model-driven "natural language programming" is precisely reenacting the cognitive trap Dijkstra warned about back then.
What Exactly Was Dijkstra Arguing Against
The core argument of EWD667 is not complicated: natural language evolved for vague, ambiguous, context-dependent human communication, whereas programs require precise, unambiguous, mechanically executable instructions. Conflating the two amounts to assuming that "the vagueness of human language" can be eliminated by some kind of magic—and Dijkstra believed this assumption itself is a misunderstanding of the nature of programming.
His target of criticism was not the act of "describing requirements in natural language"—that has always been part of everyday software engineering. What he opposed was using natural language itself as a programming language, i.e., the belief that as long as you express things naturally enough, machines can correctly understand and generate programs. In Dijkstra's view, the difficulty of programming lies not in the syntax of typing code, but in formalizing vague intentions into precise logical structures—and this formalization process is precisely where the core value of programming lies.
EWD numbers are a numbering system Edsger W. Dijkstra used for his Technical Notes starting in the 1960s, with the prefix "EWD" taken from the abbreviation of his full name. These notes were not formally published papers, but rather ideas, lecture notes, and short commentaries he jotted down casually, totaling over 1,300 pieces and covering algorithms, programming methodology, educational philosophy, and even the social impact of computer science. EWD667 is one of them, written in 1978 and only a few pages long. Because Dijkstra habitually photocopied his manuscripts and distributed them to colleagues, the EWD series circulated through informal academic channels, and were later archived and digitized at institutions including his alma mater, the University of Twente in the Netherlands. These short essays are often sharply worded with strong viewpoints, and EWD667 is one of the most frequently cited pieces among them.
Fifty Years Later, the Same Debate in New Packaging
In the Hacker News comment section, many developers pointed out that the current narrative of "programming in natural language" is highly isomorphic to what Dijkstra criticized. Large models can turn your sentence into runnable code, but whether the code is correct and whether it does what you actually want still depends on whether you can express the requirements precisely—which is precisely what natural language is worst at.
One commenter's summary is quite representative: natural language programming lowers the barrier to entry, but shifts the complexity to the "verification" stage. You no longer need to learn syntax, but you need to more carefully review every line of code AI generates, because vague instructions produce results that seem reasonable but are actually wrong. This echoes Dijkstra's view: the difficulty of programming has never been about syntax, but about precision of thought.
Other commenters held different views. They argued that in Dijkstra's era, machines' ability to understand natural language was virtually zero, whereas today's large models can handle ambiguity and context to a considerable extent. This camp believes that EWD667's critique targeted "treating natural language as a substitute," whereas the more realistic approach today is "natural language as interface, formal verification as safeguard"—the two are not mutually exclusive.
Formal verification refers to techniques that use mathematical methods to prove that a program satisfies some specification, such as model checking, theorem proving, and Hoare logic. Its core idea is: rather than relying on test sampling, exhaustively or deductively prove that a program satisfies expected properties under all legal inputs. The commenter's proposal of "natural language as interface, formal verification as safeguard" means having large models translate natural language instructions into code, then using formal tools (such as SMT solvers, type systems, contract checking) to verify whether the generated results satisfy invariants. The limitation of this approach is that the formal specification itself still needs to be expressed precisely, and automatically converting vague natural language instructions into formal specifications is itself an unsolved problem. Therefore, it is more like postponing rather than eliminating the "formalization" step that Dijkstra emphasized.
The Real Implications for AI Coding Tools
This dialogue spanning nearly half a century has several practical implications for those building AI coding tools today.
First, don't market "natural language input" as "no need for precise thinking." The more powerful the tool, the more users need the ability to break down intentions into verifiable steps. Dijkstra's warning translates into a product design question today: how to help users discover that their instructions are vague, rather than pretending the vagueness doesn't exist.
Second, the value of the verification stage is rising, not falling. When the cost of generating code approaches zero, the cost of reviewing and understanding code becomes the bottleneck. Capabilities built around "letting users efficiently verify AI output" have a stronger moat than simply improving generation quality.
Third, the boundary between natural language and formal language needs to be respected. Requirements discussions can use natural language, but key logic, interface contracts, and invariants still need precise forms of expression. Tools that conflate the two will ultimately pass the risks brought by vagueness onto users.
Conclusion
EWD667 is only a few pages long, yet it can still spark over two hundred comments nearly fifty years later—which itself shows the problem has not been solved. Natural language programming is not a new topic, and Dijkstra's "foolishness" verdict is not meant to deny technological progress, but to remind us: the form of language determines the boundaries of thought, and the precision requirements of programming will not disappear just because the interface becomes more "natural." For AI coding tools, the real opportunity is not to make programming look simpler, but to help users build a reliable bridge between the vagueness of natural language and the precision of programs.
One-line Summary
Dijkstra's old essay warns: the vagueness of natural language programming persists, and the difficulty shifts to verification.
Paragraph Summary
Drawing on the renewed popularity on Hacker News of Dijkstra's 1978 essay On the Foolishness of "Natural Language Programming," the article discusses the current wave of large-model-driven natural language programming. Dijkstra's core argument is: natural language evolved for vague human communication, whereas programs require precise, unambiguous, mechanically executable instructions; treating natural language as a programming language is a misunderstanding of the nature of programming; the difficulty of programming lies in formalizing vague intentions into precise logic, not in typing syntax. Commenters believe the current narrative is highly isomorphic to Dijkstra's critique: generating code has become easier, but correctness still depends on the precision of requirement expression, with complexity shifting from syntax to verification. The article accordingly offers three insights: natural language input should not be marketed as "requiring no precise thinking"; verification capability has a stronger moat than generation quality; and the boundary between natural language and formal language must be respected.
Related articles

OpenAI Partners with Shield: How the Astra Agent Revolutionizes IT Troubleshooting
OpenAI and Shield launch the Astra agent, which autonomously logs into computers and legacy systems to fix IT issues in real time, 35-40% faster than traditional models, with humans involved only when judgment is needed.

iPhone Duo Battery Life Tested: One Charge a Day Is Unavoidable, and the Large Screen Is the Culprit
iPhone Duo battery test: heavy use needs at least one charge a day, and about 30% remains after 6.5 hours of screen-on time. How often the large screen is unfolded is key; a MagSafe battery pack helps, and long-term degradation is also worth watching.

Kimi K3.1 Pro Open-Sourced: 2.8 Trillion Parameters Close In on Opus
Moonshot releases the open-source MoE model Kimi K3.1 Pro, with 2.8T total parameters and 104B activated, trailing Opus 5.5 by under 1 point on Terminal Bench 4.0.