Dijkstra Was Right — and Anthropic Is Betting He Was Half-Wrong

A 1978 essay by Edsger Dijkstra, 'The Foolishness of Natural Language Programming,' resurfaced on Hacker News this week with 206 points and 119 comments, and its timing against the current wave of LLM-assisted coding could hardly have been more pointed. Dijkstra's argument was not that natural language interfaces were technically impossible — it was that the ambiguity inherent in natural language is a defect, not a feature, when specifying computational behavior. Formal notations are powerful precisely because they strip that ambiguity away; when you say 'sort the list,' the word carries unstated assumptions about stability, ordering direction, and data types that the speaker may or may not intend. Getting precise computational behavior from imprecise specification was, in Dijkstra's framing, a category error.

The HN community's dominant response was not that Dijkstra was wrong but that LLMs may have hidden his problem rather than solved it. When a model misinterprets a natural language specification, the resulting code can look entirely plausible while doing something subtly incorrect — and the user has lost the forcing function that precision requirements once provided. The reply drawing the most upvotes argued that Dijkstra's real concern was about skill atrophy: if you can describe behavior in English and receive working code, you lose the habit of reasoning with the exactness that debugging and formal verification require.

Anthropic published research this week arguing that LLMs are making formal software verification feasible at scale — which sits in almost direct tension with Dijkstra's critique. Formal verification, the mathematical discipline of proving that software satisfies its specification, has historically been confined to the most critical systems — aerospace firmware, cryptographic protocols, hardware designs — because the human cost of writing proofs was prohibitive. Anthropic's claim is that LLMs can generate verification conditions, suggest proof tactics, and fill in routine lemmas at a speed that dramatically reduces that cost. The 212-comment HN thread was skeptical but genuinely engaged.

Skeptics raised the hallucination concern: an LLM generating invalid proof steps. The counterargument, which several commenters found persuasive, is that formal verification frameworks do not accept invalid proofs — a wrong step produces a failed attempt, not a false certification. The more searching challenge was about specification rather than proof: formal verification proves that software satisfies its formal specification, but writing a complete and correct formal specification is itself a hard problem. If the specification is wrong, the proof confirms the wrong thing with high certainty. Dijkstra's precision problem does not disappear; it moves upstream.

The 'Docker is Weird' blog post — 544 points and 235 comments, the week's highest-scoring developer experience piece — offered a complementary archaeology of accumulated design friction. The post catalogs Docker's networking model, the way image layers interact with file deletions, the unintuitive relationship between ENTRYPOINT and CMD, and the behavior of Docker's build context. Experienced Docker contributors in the thread explained why each decision made sense in its original single-host context, and why those same decisions create constant friction inside a Kubernetes cluster. Tools designed for one set of assumptions, adopted at much larger scale, accumulate resistance precisely where the original assumptions no longer hold.