I think this essay has aged pretty well and remains pretty spot on.

Some people will push back that agent development is "natural language programming" but I don't think that's right. I think in that case the agent is the one programming, and the programming still always happens in a deterministic language like Rust/Python/Typescript/etc. Maybe that'll change, but to me at least the other way would be a disaster.

The best exception I know of though, is definitely the Inform 7 language which is for writing text adventures[0]. It has a lot of fans, and I've never gone deep with it, but seems to do a pretty elegant job or marrying up natural language and programming together in a unique way.

Either way, definitely a must-check-out for any language-geeks interested in natural language programming.

[0] https://ganelson.github.io/inform-website/

I send this article to everyone who tells me how English is now a high-level programming language, the next level of abstraction up the chain from machine language to <their favorite language>. This analogy tends to be followed by "Just like most programmers never look at assembly code, looking at higher-level source code is going to become something only a few people do".

Dijkstra's arguments tend not to change their minds. I think the analogy takes hold because there is a kernel of truth in it. AI models now give us the magical ability to program in natural language, but the implication that an AI model is a form of compiler is deeply flawed. AI models don't replace compilers, they replace software developers. The reason software developers rarely look at assembly code is that compilers (and emulators and VMs) are able to precisely preserve the semantics of the original program.

A natural language spec is not a program, and there are many possible programs that can meet the spec. Software engineers and AI models turn specs into code, but the code is not the spec I think the analogy clouds our thinking about the value of programming languages as a tool for formally describing what the computer should do and enforcing properties of the program that should not be left to either humans or AI models to uphold.

I'm going to take the contrarian view and say that formalism without jargon, friction and gatekeeping is just natural language.

I've been going through an identity crisis for a year now as I realize more and more that nearly the entirety of what I know comes down to arcane incantations producing transpilation instead of magic. My tech career was just converting specs from clients and employers into machine code, with extra steps.

To move now at the speed of thought and let AI complete whatever tedium was preventing me from getting real work done has been a revelation.

To the point that I fantasize about the day I can leave tech behind and get back to the human experience. No longer drowning in the unending workload that demands ever-increasing productivity for the same pay, but finally able to say enough's enough and provide time/money/resources for myself and eventually the community at large outside of the hierarchical economy.

If we can't automate our livelihoods with AI, then we don't have anything.

I've had the same view since coding agents appeared. LLMs are good for summarizing, thus I tend to use them to understand code. However, the more I understand a code base the more I tend to be more picky with the agent. While the less I know about the code base, the more open I am to let it do its thing.

I've realized that the agent doesn't write 'good' code, instead my vague understanding of what I expect makes me think it does. When I look at the AI code, I see that there are more nuances and decisions that needed to be taken before writing the code. One would say that a spec would suffice, but then I remember TLA+, developed by Leslie Lamport to help developers think critically about their programs/algorithms. Sitting down and formally writing what I want to do helps me better understand the problem and come up with a real -not vaguely defined- solution.

I think the difference is between communicating to a purely mechanical being versus communicating to an intelligent entity: unlike programs, which are purely formal languages, we write textbooks and papers in a mix of human language and formal language. often we introduce "just formal enough" notations. and the intelligent reader will read in-between, inter legere literally means just that: reading in between. filling the gaps, connecting the dots.

and in practice I find it _very_ effective to express key ideas with some formal language where applicable. a little ebnf here, some snippets of python or prolog there or other languages there. and I find llms wonderful at filling in the dots and, and that's the topic here, to translate our semi formal conversation into rigorous, formal language.

and I dare one step further: I also find llms useful in formulating and refining technical proposals, for human peer review and llm driven implementation, and of course these proposals mix natural language prose with semi-formal and formal detail. think PEP-12 and PEP-1 style. and these then get work packages which each loop in a spec as in sdd.

seems to work just fine so far :-)

Natural language is full of nuances and implicit cultural and domain specific connotations. LLMs work because they have been trained on massive corpus of materials that encode some (but not all) of those hidden meanings.

With specification driven development, the prompts need to be very detailed in order to produce exactly what is required.

> I suspect that machines to be programmed in our native tongues —be it Dutch, English, American, French, German, or Swahili— are as damned difficult to make as they would be to use.

He's still quite correct. I generally see a machine as being "programmed in" whatever is tracked in source control. So as long as your git repo is tracking changes in Java, that's still programmed in Java, even if the Java was generated with the assistance of LLMs. I may consider the thesis of this article invalidated only when the majority of repos start tracking natural language rather than programming languages as the primary artifacts defining behavior of the software.

What Dijkstra said still holds true, and the essence is consistent with Brooks' discussion on essential complexity vs accidental complexity. I do think one thing has changed, though: when someone asks AI to implement XXX with very vague English, the implicit ask is picking the best[1] ever solution that someone else has done to solve XXX. For instance, if I ask AI to extract the Japanese subtitle of Shirojima show and convert it to an epub with all the nantural and cultural explanations, I was assuming that AI will fill in the blanks and do a good job and AI did. This won't help expert, but does it matter? Being good enough can be good enough to take away many people's jobs.

[1] For many people, the result is actually the mean not the best, but it's another topic.

Todays natural language program won't work tomorrow due to unstable nature of natural language.

Apart of natural evolution of meanings, look at Orwellian limitations some (cloud) models impose on is that our natural language program become illegal. Due to topic or combination of words the program needs to be flagged and soon likely reported to three leter agency.

Next, RMS would ask: can you make your own natural language program compiler from scratch? I know we have (very expensive) local models, but wait until GPUs get a propper online subscriptions to work and surveillance taps.

>And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.

That could just as easily be written today

From a pragmatic perspective, I'm with Djikstra for a very specific reason.

Clearly it is possible to "program" in natural language. I have one- and few-shotted a number of apps that meet my requirements.

Generally as the number and complexity of requirements grows it becomes harder to parse them if they are in a poorly structured natural language format.

I can't think of a time that I have provided specifications in natural language with sufficient rigor that if I was to run the prompt ten times, the ten generated programs would look identical or provide exactly the same outputs for the same inputs under all situations.

Whenever I find that I need the rigor such that the code could be considered to be a cache, not an authoritative artifact, I find domain specific languages to help me to ensure the comprehensiveness of my requirements around the dimensions that I care about.

I also find such structure to aide collaboration with other humans trying to understand or extend such specifications.

So I think for code to become ephemeral, for substantial pieces of software that require the documentation of many complicated requirements, writing such specifications in natural language is not the best interface and would require substantial support from LLMs to project them in ways (flow charts, UX demos, etc) that humans could reliably understand and mutate them without introducing regressions.

But we'll see. Last year I still thought git was an appropriate version control system to use!

Possibly relevant:

The experiment in designing a language that resembled natural languages (English and Japanese) was not successful. -[1]- William R. Cook, AppleScript, HOPL IV

Now our new LLMs are different, because they don't use "language the resembled natural languages", but actual natural language. But the lesson is instructive nevertheless, because it gives us some empirical evidence to compare to Dijkstra's theoretical arguments.

And this is that natural language is at best a two-edged sword. Yes, there are benefits, but there are also huge drawbacks. And one problem is that the benefits are front-loaded and the drawbacks are long-term problems.

To me, one thing we are missing is that what LLMs do for us actually has 2 parts.

1. It allows us to use natural language, allowing us to be fuzzy.

2. It allows us to specify what we want at a much, much higher level than usual.

With our LLMs, these two are intrinsically linked. I think the whole would be much, much more valuable if we could separate them.

[1] https://dl.acm.org/doi/10.1145/1238844.1238845

NL programming is foolish to me not on technical grounds but on practical ones. It is most valuable when the business wants to understand how an already working thing does its job.

I have observed several samples where the business, when provided with a natural language configuration opportunity, will wind up staring blankly at the textarea until the original developer gives them a complete starting point.

I don't think "natural" language makes much of a difference unless you are already skilled in the art of developing useful engineering specifications. I often have to babysit the business through very basic boolean algebra concerns despite everyone having 3+ decades experience dealing with this stuff. Making everyone speak python could only make this worse, not better.

I use HN to keep myself warmed up on natural language expression. The difference between developers who post here prolifically and those who barely write one email a month is fairly shocking in my experience. If you intend to use a specific instrument to accomplish a complex task, you need to practice it constantly. Ideally every single day. There is no substitute for this. There never will be.

LLM interfaces on everything these days equate to touch screen on cars. It is definitely a useful tool, but generally speaking, that's not how you'd talk to your computer.

Dijkstra elegantly explains why AI systems are effective at mathematics and programming but much less effective when writing prose or other realms where what is good is nebulously defined:

> "The virtue of formal texts is that their manipulations, in order to be legitimate, need to satisfy only a few simple rules; they are, when you come to think of it, an amazingly effective tool for ruling out all sorts of nonsense that, when we use our native tongues, are almost impossible to avoid."

>We would need all the intellect in the world to get the interface narrow enough to be usable,

It seems Dijkstra is describing potential calability of LLM model trained on published collective human knowledge enabled by the Internet

>and, in view of the history of mankind, it may not be overly pessimistic to guess that to do the job well enough would require again a few thousand years

Since the article was written in 1978 (about 50 years ago) and from the time the computing resources of CPU and RAM has increased exponentially until the LLM first appeared in 2020s, it seems the thousand of years prediction is merely several decades accelerated by the rapid advances of computer and communication systems technology spearheaded by companies like Nvidia.

This feels so incredibly relevant for today. This also makes me think about the cognitive delegation problem - structured interfaces in machines and structured methodologies in mathematics helped humans build structured thoughts to express abstract intuition. With machines starting to speak natural language, it's probably not too far fetched to say that humans will eventually stop organising their thoughts, which will turn their thoughts into a kind of brain fog.

There’s em dashes in that 1978 article.

The most obvious reason natural language is a poor choice for programming is ambiguity.

Time flies like an arrow.

I saw the parade coming through the window.

For small programs that basically duplicate something else with a few tweaks, sure, natural language can be fine. "The same thing as A, but with a red border, and add a new button to do X." Beyond that things start to get tricky.

Interactive programming has far more value than natural language programming, and agents also give you that. An ambiguous natural language spec. that leads to the wrong result is less problematic when you can interactively correct the problem; "No, that button should have been on the left hand side." It is the new version of REPL.

Yeah - in my own personal experience building AI products this still holds true. And you can see it in the way they behave themselves, they don't really write prompts for themselves to use in the future (say CLAUDE.md) when they need the output to be deterministic. They write code for it, then write tests around that code, then fix the bugs in that code.

Yes it all started with "natural language", but even AI has an understanding that you need more structure than natural language when you want deterministic results.

My take is that this is largely right. To be specific though, I feel the future is natural language commands that will be translated into a proper language through llm systems.

In this way, the generated output, whether used as a proper program or just some scripts to do small activities, they can be audited later, reused, and tested even if a client created the request in plain language.

We would then mostly be translating bugs from english to the underlying language and bugs would mostly be people speaking ambiguously or just misspeaking

This article shows every now and then, and it's a must read. Indeed the natural language programming requires massive clusters of gpus just to make a half baked crud app

Programming in natural language still doesn't work, Btw! whenever you're using a Ml model to either autocomplete code or as an agent, you're not really programming in natural language but "delegating" in natural language!

The old skeptics weren’t wrong about the foolishness of natural language as a programming language, it's just that they assumed the only possible intermediary way to "write" code was something compiler-like! they never really thought about a future where ai would become good enough to translate natural language instructions into runnable code

"...some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate 'the ease of programming' with the ease of making undetected mistakes."

What a spot-on sentence.

Fun fact: there are over 600 definitions of the word "run" and over 400 for "set". But yeah, English is really precise enough for programming.

How many times have we seen that there's been a spec for something and the programmers write something that is exactly like the spec said but was completely wrong?

> (You have only to look at the indeed alarming amount of on close reading meaningless verbiage in scientific articles, technical reports, government publications etc.)

It is perhaps for the best that Djikstra did not live long enough to witness this problem become orders of magnitude worse.

The human equivalent of LLM could be to build a wiki / semantic graph of all algorithms, tutorials, framework docs, stdlib docs and attach a make file at the end each node.

I've been stating it elsewhere, attention has made English into a context aware sensitive programming language by resolving ambiguities through anaphora and coreference resolution. Inform7 did limited anaphora resolution - it - but LLMs are able to resolve "move that file to this folder".

His point is moot. His argument considers that natural language would be the direct expression of the program. It's not. It's an abstraction layer, that is then converted in formal language. He could have foreseen that, given he takes explicitly the example of machine code and high-level languages. High-level languages do not replace machine code, they translate into it. Just like natural language programming translates into high-level language.

I built a music player by talking to Claude Code in Japanese, and I can barely remember a time when words failed and I had to fall back to code. For example, I asked it to "keep the sidebar's shape, but add margin on the top, left and bottom so it looks like it's floating a bit — you know what I mean?" and it got it right on the first try.

I actually wrote a thesis on this in graduate school, and completely disagree with the author.

The problem with this argument isn't that natural language programming leads to vague/ambiguous code that would lead to errors. The problem is that the machine does not inform you of the ambiguity. Rational humans do just fine when they interact because they can identify these problems. Programming would work just find if context were identify and clarified while the code was being written.

If I were to tell a program to "buy political ads in Portland," yea, the point is that the program would need to know which Portland I mean. Otherwise it might accidentally think I mean Portland, OR, instead of Portland, ME:

https://www.yahoo.com/news/politics/articles/25-000-mistake-...

Humans can do the same thing if they're not being careful. The point is, the vast, vast, vast majority of time, someone would just say "wait, you mean Portland, Maine, right?" and you'd say "yes" and that would be that.

I am surprised that cs.utexas.edu uses a TLS certificate chain who's root is eMudhra's "emSign Root TLS CA - G1".

Programming happens in code. Software development happens in natural language.

Dichotomy solved, let’s go get lunch! ;-)

Natural language as code has existed for thousands of years. Today we call it legalese.

It's excruciating to write, excruciating to read, and even legit geniuses with decades of hard won experience still leave room for essentially infinite interpretation. laws and contracts are all still swiss cheese and can be made to demand or prohibit whatever the party with the most money or other influence wants.

I find c++ very unnatural, since it's a giant collection of small rules in the end more complex than assembler. I can't remember the entire sintaxis, zoo of function decorators, undefined behavior, intrinsics which are just labels over asm instructions, Code golf sintaxis...

App stores are approving an order of magnitude increase of new apps because people are now able to create them using natural language. End users are deriving great value from them. So this is settled?

Nature mints new fools every single day and they all know better than to be informed by past mistakes or — god forbid — anyone using their brains.

A really interesting read in the current era.

We should have listened.

All I gotta see is “utexas.edu” and “(197X)” and I know it’ll be a banger that’s still relevant today.

Inform7 disagrees; altough you can use Inform6 which is like a really simple OOP language to create text adventures.

We are now totally there: Programming With Natural Language.

I could only describe the "look and feel" of the ESP32-algorithm driving a sewing machine: "Snappy but not jerky, linear at low speeds, but accelerates fast".

Antigravity made it perfect but incomprehensible for a hewman.

Another article on this topic https://alexalejandre.com/programming/no-end-of-programming-...

And yet, the specification of almost every program in existence was communicated in natural language. At least between the customer and developer.

This argument makes the implicit assumption that humans are uniquely able to convert between this "customer wants a program that solves their problem" level and compileable code. That was a reasonable thing to believe in 1978, but is not a reasonable thing to believe in 2026.

Dijkstra's epigrams have not aged well. He once mocked software engineering as "how to program if you cannot"—but this too is a solved problem thanks to AI.

[flagged]

[dead]

[flagged]

[flagged]

[dead]

[dead]