Live data from Hacker News

Dijkstra On the foolishness of "natural language programming"

cs.utexas.edu

161–170 of 281 posts

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

#161

Earlier quoted context omitted.

I'm not so sure it's about precision rather than working memory. My presumption is people struggle to understand sufficiently large prose versions for the same reason a LLM would struggle working with larger prose versions: people have limited working memory. The time needed to reload info from prose is significant. People reading large text works will start highlighting and taking notes and inventing shorthand forms…

So is more compact better? Does K&R's *d++ = *s++; get a pass now?

That's confusing because of order of operations. But

  while ( *(d++) = *(s++) );
is fairly obvious, so I think it gets a pass.

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

#162
post #154
post #85

Earlier quoted context omitted.

If you don't mind sharing - what's the specific prompt you use to get this to happen, and which LLM do you use it with?

The rudest and most aggressive LLM I've used is Deepseek. Most LLMs have trained-in positivity bias but I can prompt Deepseek to tell me my code is shit very easily.

Of all the things I heard about deep seek that's the one that has motivated me the most to try it out XD

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

#163
One of the things LLM's/natural language programming brings is greater access. While the actual code may be crap, it opens up things to more people to play around and iterate on ideas without having to have a ton of knowledge. That is powerful by itself.

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

#164
post #67

This reminded me of this old quote from Hal Abelson: "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…

Well that sure isn't what they teach in computer science programs anymore

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

#165
post #116

Earlier quoted context omitted.

Reading up on the history of mathematics really makes that clear as shown in https://www.goodreads.com/book/show/1098132.Thomas_Harriot_s... (ob. discl., I did the typesetting for that) It shows at least one lengthy and quite wordy example of how an equation would have been stated, then contrasts it in the "new" symbolic representation (this was one of the first major works to make use of Robert Recorde's development…

Although if you look at most maths textbooks or papers there's a fair bit of English waffle per equation. I guess both have their place.

People definitely could stand to write a lot more comments in their code. And like... yea, textbook style prose, not just re-stating the code in slightly less logical wording.

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

#166
post #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?

https://en.wikipedia.org/wiki/Predicate_transformer_semantic...

Found in about 9 seconds.

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

#167
post #59

Earlier quoted context omitted.

isn't that just copilot "explain", one of the earliest copilot capabilities. It's definitely helpful to understand new codebases at a high level > there is a reason why legalese is not plain English, and it goes beyond mere gatekeeping. unfortunately they're not in any kind of formal language either

> isn't that just copilot "explain", one of the earliest copilot capabilities. It's definitely helpful to understand new codebases at a high level In my experience this function is quite useless. It will just repeat the code in plain English. It will not explain it.

Haven’t tried copilot but cursor is pretty good at telling me where things are and explaining the high level architecture of medium-largeish codebases, especially if I already vaguely know what I’m looking for. I use this a lot when I need to change some behavior of an open source project that I’m using but previously haven’t touched.

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

#168

Earlier quoted context omitted.

Language can carry tremendous amounts of context. For example: > I want a modern navigation app for driving which lets me select intersections that I never want to be routed through. That sentence is low complexity but encodes a massive amount of information. You are probably thinking of a million implementation details that you need to get from that sentence to an actual working app but the opportunity is there, the…

You call it context or information but I call it assumptions. There are a ton assumptions in that sentence that an LLM will need to make in order to take that and turn it into a v1. I’m not sure what resulting app you’d get but if you did get a useful starting point, I’d wager the fact that you chose a variation of an existing type of app helped a lot. That is useful, but I’m not sure this is universally useful.

> There are a ton assumptions in that sentence that an LLM will need to make in order to take that and turn it into a v1.

I think you need to think of the LLM less like a developer and more like an entire development shop. The first step is working with the user to define their goals, then to repeat it back to them in some format, then to turn it into code, and to iterate during the work with feedback. My last product development conversation with Claude included it drawing svgs of the interface and asking me if that is what I meant.

This is much like how other professional services providers don’t need you to bring them exact specs, they take your needs and translate it to specifications that producers can use - working with an architect, a product designer, etc. They assume things and then confirm them - sometimes on paper and in words, sometimes by showing you prototypes, sometimes by just building the thing.

The near to mid future of work for software engineers is in two areas in my mind:

1. Doing things no one has done before. The hard stuff. That’s a small percentage of most code, a large percentage of value generated.

2. Building systems and constraints that these automated development tools work within.

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

#169
post #7

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

Apple didn't learn those lessons with Apple Script either: there is a rigid sequence of characters that represents a valid program and if you're off by one character, tough. If you're lucky, the tool will guide you to what it wants. If not, you're stuck looking up the exact syntax so off to the reference manual you go, either way.

So there's minimal to looking up the syntax, whether it's based on some natural language phrase or a less wordy or ambiguous artificial language.

"friendly" or "natural" really is not a thing.

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

#170
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…

Computers can and should help along the way, but Dijkstra's argument is that a) much of the challenge of human ideas is discovered in the act of converting from natural to formal language and b) that this act, in and of itself, is what trains our formal logical selves. So he's contesting not only the idea that programs should be specified in natural language, but also the idea that removing our need to understand the…

But even real translation is bad.

There has been some efforts to make computer languages with local (non-english) keywords. Most have fortunately already failed horribly.

But it still exists, e.g. in spreadsheet formulas.

In some cases even number formatting (decimal separators) are affected.

Post reply on HN