The foolishness of "natural language programming" (1978)

Original Article ↗ Hacker News Discussion ↗

Natural-language interfaces for coding are reviving a long‑standing dream that Edsger Dijkstra argued was fundamentally misguided in 1978. Commenters contrast his emphasis on the precision of formal languages with today’s large language models, noting that AI can now turn vague English requests into working code but still inherits natural language’s ambiguity, lack of guarantees, and dependence on human oversight. Many see LLMs less as “natural language compilers” and more as stochastic junior developers or agents, useful for accelerating work and raising abstraction levels but not replacing traditional programming languages, specifications, or careful software engineering.

Scope of “Natural Language Programming”

  • Many argue the essay still applies: natural language is informal, ambiguous, and ill-suited as the primary program representation.
  • Several commenters stress that today’s “natural language programming” is really natural-language delegation to an agent that then writes conventional code.
  • A minority argue the original critique is “moot” because natural language now serves as one more abstraction layer that gets compiled into formal languages.

LLMs: Compilers, Developers, or Something Else?

  • Strong view: LLMs do not replace compilers; they replace (or augment) software developers who translate informal specs into code.
  • Others see LLMs as a new kind of interpreter for an underspecified language (prompts), i.e., a form of programming, just with probabilistic semantics.
  • Debate over whether prompting is truly “programming” or just giving instructions to another programmer-like entity.

Determinism, Semantics, and Reliability

  • Multiple comments distinguish deterministic compiler pipelines from stochastic, context-sensitive LLM outputs.
  • Some push back that humans are also non-deterministic in practice, but others insist stochasticity is a different, stronger notion than mere variation.
  • Consensus that compilers and rich type systems remain essential for semantic guarantees, testing, and safety checks on LLM-generated code.

Specs, Meetings, and System Understanding

  • Several anecdotes highlight that real work depends on clarifying vague natural-language specs, whether done by humans or agents.
  • Business users often struggle even with natural-language configuration; “system thinking” and specification skill are still rare and crucial.
  • Agents lack real-world context (infrastructure, org constraints, accountability), limiting full automation of the analyst/engineer role.

Code, Prompts, and Source of Truth

  • Many insist the language in version control (Java/Python/etc.) determines what the system is “programmed in,” regardless of how that code was produced.
  • Some foresee prompts or conversations eventually being treated as primary artifacts, raising maintainability and open‑source licensing questions.
  • LLM output is compared to any one-off code generator: maintainability and reproducibility remain issues.

Empirical Experiences and Niche Exceptions

  • Users report success “vibe coding” apps via agents, but note missed non-functional requirements, infrastructure details, and subtle bugs.
  • Inform7 and legal drafting are cited as examples of quasi-natural languages: readable but still highly constrained, underscoring how hard true NL programming is.