I wonder, what if you did the opposite? Take a project of moderate complexity and convert it from code back to natural language using your favorite LLM. Does it provide you with a reasonable description of the behavior and requirements encoded in the source code without losing enough detail to recreate the program? Do you find the resulting natural language description is easier to reason about?

I think there's a reason most of the vibe-coded applications we see people demonstrate are rather simple. There is a level of complexity and precision that is hard to manage. Sure, you can define it in plain english, but is the resulting description extensible, understandable, or more descriptive than a precise language? I think there is a reason why legalese is not plain English, and it goes beyond mere gatekeeping.

"Underlying our approach to this subject is our conviction that "computer science" is not a science and that its significance has little to do with computers. The computer revolution is a revolution in the way we think and in the way we express what we think. The essence of this change is the emergence of what might best be called procedural epistemology—the study of the structure of knowledge from an imperative point of view, as opposed to the more declarative point of view taken by classical mathematical subjects. Mathematics provides a framework for dealing precisely with notions of "what is". Computation provides a framework for dealing precisely with notions of "how to"."

As a programmer, I know first hand that the problems or even absurdities of some assignments only become apparent after one has begun implement the code as code, i.e. as strict symbolisms.

Not to mention that it often takes more time to explain something accurately in natural language than it takes to just write the algorithm as code.

“You are the graphics system, an entity that manages what is on the screen. You can receive requests from all programs to create and destroys “windows”, and further requests to draw text, lines, circles, etc. in a window created earlier. Items can be of any colour.

You also should send more click information to whomever created the window in which the user clicked the mouse.

There is one special program, the window manager, that can tell you what windows are displayed where on any of the monitors attached to the system”

and

“you are a tic-tac-toe program. There is a graphics system, an entity that manages what is on the screen. You can command it to create and destroys “windows”, and to draw text, lines, circles, etc. in a window created earlier. Items can be of any colour.

The graphics you draw should show a tic-tac-toe game, where users take turn by clicking the mouse. If a user wins the game, it should…

Add ads to the game, unless the user has a pay-per-click subscription”

That should be sufficient to get a game running…

To save it, you’d need another prompt:

”you are a file system, an entity that persists data to disk…”

You also will want

”you are a multi-tasking OS. You give multiple LLMs the idea that they have full control over a system’s CPU and memory. You…”

I look forward to seeing this next year in early April.

I feel that we’ve collectively jumped into programming with LLMs too quickly. I really liked how Rust has iterated on pointing out “silly mistakes” and made it much more clear what the fix should be. That’s a much more favorable development for me as a developer. I still have the context and understanding of the code I work on while the compiler points out obvious errors and their fixes. Using an LLM feels like a game of semi-intelligent guessing on the other hand. Rust’s compiler is the master teaching the apprentice. LLMs are the confident graduate correcting the master. I greatly prefer Rust’s approach and would like to see it evolved further if possible.

We are still debating what some laws and amendments mean. The meaning of words change over time, lack of historical context, etc.

I would love natural language to operate machines, but I have been programming since mid 80's and the stubbornness of the computer languages (from BASIC, to go) strikes a good balance, and puts enough responsibility on the emitter to precisely express what he wants the machine to do.

Typically the first step, translation from natural to formal language, will be done by business analysts and programmers. But why not try to let computers help along the way?

If I didn't know who wrote this it would seem like a jab directly at people who dislike Rust.

Insisting that for every change one should go read the GDD, implement the feature and then sync back the GDD is cumbersome and doesn't work well in practice. I've never seen that happen.

But if there ever comes a time when some AI/LLM can code the next version of Linux or Windows from scratch based on some series of prompts, then all bets are off. Right now it's clearly not there yet, if ever.

Or weak typing. How many languages thought that simplifying strings and integers and other types into "scalar", and making any operation between any operands meaningful, would simplify the language? Yet every single one ended up becoming a total mess instead.

Or constraint-based UI layout. Looks so simple, so intuitive on simple examples, yet totally failing to scale to even a dozen of basic controls. Yet the idea keeps reappearing from time to time.

Or an attempt at dependency management by making some form of symlink to another repository e.g. git modules, or CMake's FetchContent/ExternalProject? Yeah, good luck scaling that.

Maybe software engineering should have some sort of "Hall of Ideas That Definitely Don't Work", so that young people entering the field could save their time on implementing one more incarnation of an already known not good idea.

The question is "natural" to whom, the humans or the computers?

AI does not make human language natural to computers. Left to their own devices, AIs would invent languages that are natural with respect to their deep learning architectures, which is their environment.

There is always going to be an impedance mismatch across species (humans and AIs) and we can't hide it by forcing the AIs to default to human language.

If you still don’t want to do programming, then you need some way to instruct or direct the intelligence that _will_ do the programming.

And any sufficiently advanced method of instruction will look less like natural language, and more like an education.

Compare that to:

https://news.ycombinator.com/item?id=43522966

If I create a website with Node.js, I’m not manually managing memory, parsing HTTP requests byte-by-byte, or even attempting to fully grasp the event loop’s nuances. I’m orchestrating layers of code written by others, trusting that these black boxes will behave as advertised according to my best, but deeply incomplete, understanding of them.

I'm not sure what this means for LLMs programming, but I already feel separated from the case Dijkstra lays out.

https://githubnext.com/projects/speclang/

Funny coincidence!

I leave it here for the nice contrast it creates in light of the submission we're discussing.

The whole thing seems a step (or several steps) backwards also in terms of UX. I mean surely there was a reason why ls was named ls, and so forth?

A bonus point is that he had also something to say about a real or alleged degeneration of natural languages themselves.

Whether that is feasible is a different question (https://xkcd.com/1425/), but also can be described in natural language.

Here is something I tried with o3-mini:

> Create a program that takes an input image and can tell if there is a bird in it.

> ChatGPT said:

> Reasoned for 38 seconds

> Below is an example in Python that uses TensorFlow’s Keras API and a pre-trained ResNet50 model to classify an input image. The code loads an image, preprocesses it to the required size, obtains the top predictions, and then checks if any of the top labels appear to be a bird. You can expand the list of bird keywords as needed for your application.

> python code that works

If you take the critical view, you can always find a way to find an exception that will fail. I can see many happy cases which will just work most of the time, even with the currently available technology. Most of the programming work done today is putting libraries and api services together.

There is inherent value in using formal language to refine, analyze, and describe ideas. This is, after all, why mathematical symbolism has lasted in spite of the fact that all mathematicians are more than capable of talking about mathematical ideas in their natural tongues.

Code realizes a computable model of the world. A computable model is made up of a subset of the mathematical functions we can define. We benefit greatly from formalism in this context. It helps us be precise about the actual relationships and invariants that hold within a system. Stable relationships and invariants lead to predictable behaviors, and predictable systems are reliable systems on the plan of human interaction.

If you describe your system entirely in fuzzily conceived natural language, have you done the requisite analysis to establish the important relationships and invariants among components in your system, or are you just half-assing it?

Engineering is all about establishing relative degrees of certainty in the face of the wild uncertainty that is the default modality of existence. Moving toward a world in which we "engineer" systems increasingly through informal natural language is a step backwards on the continuum of reliability, comprehensibility, and rigor. The fact that anyone considers using these tools and still thinks of themselves as an "engineer" of some kind is an absolute joke.

This refers to the era of COBOL, or maybe Hypertalk, not LLMs.

13) Humans writing code is an inherently flawed concept. Doesn't matter what form the code takes. Machine code, assembly language, C, Perl, or a ChatGPT prompt. It's all flawed in the same way. We have not yet invented a technology or mechanism which avoids it. And high level abstraction doesn't really help. It hides problems only to create new ones, and other problems simply never go away.

21) Loosely coupled interfaces made our lives easier because it forced us to compartmentalize our efforts into something manageable. But it's hard to prove that this is a better outcome overall, as it forces us to solve problems in ways that still lead to worse outcomes than if we had used a simpler [formal] logic.

34) We will probably end up pushing our technical abilities to the limit in order to design a superior system, only to find out in the end that simpler formal logic is what we needed all along.

55) We're becoming stupider and worse at using the tools we already have. We're already shit at using language just for communicating with each other. Assuming we could make better programs with it is nonsensical.

For a long time now I've been upset at computer science's lack of innovation in the methods we use to solve problems. Programming is stupidly flawed. I've never been good at math, so I never really thought about it before, but math is really the answer to what I wish programming was: a formal system for solving a problem, and a formal system for proving that the solution is correct. That's what we're missing from software. That's where we should be headed.

This is largely because it leaves chance for misinterpretation or miscommunication. Programming languages eliminated misinterpretation and made miscommunication easier to notice through errors.

Programming language enables micromanaging proactively, I specify the instructions before they run. I often find myself micromanaging retroactively with LLMs, until I reach the path I am looking for.

One might naively think that the "AI" (LLM) is going to apply it's intelligence to give you the "best" code in response to your request, and in a way it is, but this is "LLM best" not "human best" - the LLM is trying "guess what's expected" (i.e. minimize prediction error), not give you the best quality code/design per your request. This is similar to having an LLM play chess - it is not trying to play what it thinks is the strongest move, but rather trying to predict a continuation of the game, given the context, which will be a poor move if it thinks the context indicates a poor player.

With an RL-trained reasoning model, the LLM's behavior is slightly longer horizon - not just minimizing next token prediction errors, but also steering the output in a direction intended to match the type of reasoning seen during RL training. Again, this isn't the same as a human, applying their experience to achieve (predict!) a goal, but arguably more like cargo-cult reasoning - following observed patterns of reasoning in the training set, without the depth of understanding and intelligence to know if this is really applicable in the current context, nor with the ability to learn from it's mistakes when it is not.

So, while natural language itself is of course too vague to program in, which is part of the reason that we use programming languages instead, it's totally adequate as a way to communicate requirements/etc to an expert human developer/analyst, but when communicating to an LLM instead of a person, one should expect the LLM to behave as an LLM, not as a human. It's a paperclip maximizer, not a human-level intelligence.

I wonder if this is a static vs dynamic or compiled vs interpreted reference.

Anyway I love it. Made me giggle that we are still discussing this today, and just to be clear I love both sides, for different things.

I promise to upvote the next Dijkstra link that I see that does not present him as Ambrose Bierce with a computer.

Wasn't that the actual motivation behind the development of SQL?

IIRC, SQL was something that "even" business people could code in because it was closer to "natural language".

When you see the monstrosity the motivation gave birth to, I think the "foolish" argument was well warranted at the time.

Of course, in these days of LLM's, Dijkstra's argument isn't as clear cut (even if LLM's aren't there yet, they're getting much closer).

It is clear NLU can't be done in the reign of PL itself, there is never going to be natural language grammar that is precise as PL.

But LLM is a different kind of beast entirely.

If we ever invent a human language where laws can be laid out in a manner that the meaning is clear, then we will have opened a door on programming languages that are correct. I don’t know that a programmer will invent this first. We might, but it won’t look that natural.

Please check this talk on the contributions of these mentioned people for the complementary form of deterministic AI (machine intelligence) namely logic, optimization and constraint programming in a seminal lecture by John Hooker [1].

I have got the feeling that if we combine the stochastic nature of LLM based NLP with the deterministic nature of feature structure trchnique based NLP (e.g. CUE), guided by logic, optimization and constraint programming we probably can solve intuitive automation or at least perform proper automation (or automatic computing as Dijkstra put it).

Apparently Yann LeCun also recently proposing optimization based AI namely inference through optimization, or objective driven AI in addition to data-driven AI [2].

Fun facts, you can see Donald Knuth asking questions towards the end of the JH's lecture presentation.

[1] Logic, Optimization, and Constraint Programming: A Fruitful Collaboration - John Hooker - CMU (2023) [video]:

https://www.youtube.com/live/TknN8fCQvRk

[2] Mathematical Obstacles on the Way to Human-Level AI - Yann LeCun - Meta - AMS Josiah Willard Gibbs Lecture at the 2025 Joint Mathematics Meetings (2025) [video]:

https://youtu.be/ETZfkkv6V7Y

I was under the assumption this was a current body of work seeing as Dijkstra spoke so well about the possibilities but this just goes to show some people were ahead of their tike with their worries.

Also adding your home address to something you write / publish / host on the internet is pretty hardcore.

Just like Web 1.0 - when the best we could think of to do was shovel existing printed brochures onto web pages.

In AI 1.0 we are simply shoveling existing programming languages into the LLM - in no way marrying programming and LLM - they exist as entirely different worlds.

AI 2.0 will be programming languages - or language features - specifically designed for LLMs.

Baley shrugged. He would never teach himself to avoid asking useless questions. The robots knew. Period. It occurred to him that, to handle robots with true efficiency, one must needs be expert, a sort of roboticist. How well did the average Solarian do, he wondered?

Why talk to your team when you could just program it yourself?

https://www.glass-bead.org/article/a-theory-of-vibe/

laughs nervously

LLMs in the most general case do neither what you tell them, nor what you want them to. This, surprisingly, can be less infuriating, as now it feels like you have another actor to blame - even though an LLM is still mostly deterministic, and you can get a pretty good idea of what quality of response you can expect for a given prompt.

Programming is about iteratively expressing a path towards satisfying said goals.

What LLMs are doing now is converting "requirements" into "formalizations".

I don't think Djikstra is wrong in saying - that performing programming in plain-language is a pretty weird idea.

We want to concretize ideas in formalisms. But that's not what any human (including Djikstra) starts with... you start with some sort of goal, some sort of need and requirements.

LLMs merely reduce the time/effort required to go from goals -> formalism.

TLDR: Requirements != Implementation

Seeing as transformers are relatively simple to implement…

It stands to reason he was, in some sense, right. LLMs are damn easy to use.

Wittgenstein stated that the differences between personal and cultural language makes it impossible to agree on anything foundational to philosophy.

Godel did something similar to discrete structures by hacking self reference -- a kind of recursive self reference with no exit state.

I think pair programming with an LLM is interesting. You get to compare personal context with aggregate context. Plus, the external feedback helps me break out of excessive personal self reference.