Live data from Hacker News

Dijkstra On the foolishness of "natural language programming"

cs.utexas.edu

21–30 of 281 posts

Re: Dijkstra On the foolishness of "natural language programming"

#21
post #4

I somewhat disagree with this. In real life, say in some company, the inception of an idea for a new feature is made in the head of some business person. This person will not speak any formal language. So however you turn it, some translation from natural language to machine language will have to be done to implement the feature. Typically the first step, translation from natural to formal language, will be done by b…

I don't think youre fully comprehending Dijkstra's argument. He's not saying to not use tool to help with translation, he is saying that not thinking in terms of formal symbols HURTS THINKING. Your ideas are worse if you don't think in formal systems. If you don't treat your thoughts as formal things.

In your example, he has no opinion on how to translate the idea of a "business person" because in his view the ideas of the "business person" are already shallow and bad because they don't follow a formalism. They are not worth translating.

Re: Dijkstra On the foolishness of "natural language programming"

#22

Reminds me of another recurring idea of replacing code with flowcharts. First I've seen that idea coming from some unknown Soviet professor from 80s, and then again and again from different people from different countries in different contexts. Every time it is sold as a total breakthrough in simplicity and also every time it proves to be a bloat of complexity and a productivity killer instead. Or weak typing. How ma…

Constraint-based layout works, but you need a serious constraint engine, such as the one in the sketch editors of Autodesk Inventor or Fusion 360, along with a GUI to talk to it. Those systems can solve hard geometry problems involving curves, because you need that when designing parts.

Flowchart-based programming scales badly. Blender's game engine (abandoned) and Unreal Engine's "blueprints" (used only for simple cases) are examples.

Re: Dijkstra On the foolishness of "natural language programming"

#24
People are sticking up for LLMs here and that's cool.

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.

Re: Dijkstra On the foolishness of "natural language programming"

#25
post #4

I somewhat disagree with this. In real life, say in some company, the inception of an idea for a new feature is made in the head of some business person. This person will not speak any formal language. So however you turn it, some translation from natural language to machine language will have to be done to implement the feature. Typically the first step, translation from natural to formal language, will be done by b…

The first step isn't from natural language to formal language. It's from the idea in your head into natural language. Getting that step right in a way that a computer could hope to turn into a useful thing is hard.

Re: Dijkstra On the foolishness of "natural language programming"

#26
> 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.

Seeing as transformers are relatively simple to implement…

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

Re: Dijkstra On the foolishness of "natural language programming"

#27

Dijkstra also advocated for proving the correctness of imperative code using the composition of a set of simple rules, and most programmers ignore that aspect of his work too.

Any specific paper or article of his you would recommend?

Re: Dijkstra On the foolishness of "natural language programming"

#28

People are sticking up for LLMs here and that's cool. 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 descri…

Sure but we build (leaky) abstractions, and this is even happens in legal texts.

Asking an llm to build a graphical app in assembly from an ISA and a driver for the display would give you nothing.

But with a mountain of abstractions then it can probably do it.

This is not to defend an LLM more to say I think that by providing the right abstractions (reusable components) then I do think it will get you a lot closer.

Re: Dijkstra On the foolishness of "natural language programming"

#29
post #8
post #7

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

The original text was from 1978 according to other sources

Ah, thanks. Yes it couldn't have been 2010 because he died in 2002. But the date this was written is important, otherwise his references to "the last decade" don't mean anything!

Re: Dijkstra On the foolishness of "natural language programming"

#30
post #28

People are sticking up for LLMs here and that's cool. 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 descri…

Sure but we build (leaky) abstractions, and this is even happens in legal texts. Asking an llm to build a graphical app in assembly from an ISA and a driver for the display would give you nothing. But with a mountain of abstractions then it can probably do it. This is not to defend an LLM more to say I think that by providing the right abstractions (reusable components) then I do think it will get you a lot closer.

Being doing toy-examples of non-trivial complexity. Architecting the code so context is obvious and there are clear breadcrumbs everywhere is the key. And the LLM can do most of this. Prototype-> refactor/cleanup -> more features -> refactor / cleanup add architectural notes.

If you know what a well architected piece of code is supposed to look like, and you proceed in steps, LLM gets quite far as long as you are handholding it. So this is usable for non-trivial _familiar_ code where typing it all would be slower than prompting the llm. Maintaining LLM context is the key here imo and stopping it when you see weird stuff. So it requires you act as thr senior partner PR:ing everyhting.

Post reply on HN