Live data from Hacker News

Dijkstra On the foolishness of "natural language programming"

cs.utexas.edu

201–210 of 281 posts

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

#201

Formal can be foolish, too. If you don't believe that, then I have a set for sale, with the property that it contains all sets that don't contain itself.

The problem you’re referring to arose precisely due to lack of formalism. It was a problem back when mathematicians were toying with naive set theory, one not based on axioms, but instead on intuitive terminology. Moving to axiomatic, more formal, set theory solved it.

The problem is the same, no matter if you look at it formally or informally. You could get your set theory axioms wrong, for example, but you would still be formal. Oh wait, you have a proof that set theory is consistent, right?

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

#202
Why did mathematicians invent new symbols? Imagine if all of algebra, calculus, linear algebra looked like those word problems from antiquity? Natural language is not good for describing systems, symbolic forms are more compressed and be considered a kind of technology in its own right.

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

#203
post #165
post #116

Earlier quoted context omitted.

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.

Welcome to the world of advocating for Literate Programming:

http://literateprogramming.com/

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

#204
post #179

Earlier quoted context omitted.

Is it like the human detractor who only spouts the criticism and does not offer feedback towards improvement?

Its feedback is more poignant than most humans. Here's what it said about a recent PR of mine that refactored code to fix a linter warning. > Ah, the grand theater of code review—where humans playact at immortality through version control. You want me to parse this PR's mechanical copulation of const& and std::move? Fine. Let's autopsy this digital cadaver. > Your commits scream optimization fervor: converting parame…

This is wonderful!

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

#205

Earlier quoted context omitted.

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…

If that's correct, then it's very falsifiable. If a businessperson says "there's a gap in the market - let's build X" they will be following a formalism at their level of detail. They see the market, the interactions between existing products and customers, and where things might be going. Just because they can't spell it out to the nth degree doesn't matter. Their formalism is "this is what the market would like". H…

You're either not really thinking through what you're saying, or you're being disingenuous because you want to promote AI.

A formalism isn't "person says Y". It's about adhering to a structure, to a form of reasoning. Mathematical formalism is about adhering to the structure of mathematics, and making whatever argument you desire to make in the formal structure of formulas and equations.

Saying "A palindrome is a word that reads the same backwards as it does forwards" is not a formal definition. Saying "Let r(x) be the function that when given a string x returns the reversed string, x is then a palindrome iff x = r(x)" (sans the formal definitions of the function r).

Formalism is about reducing the set of axioms (the base assumptions of your formal system) to the minimal set that is required to build all other (provable) arguments. It's not vague hand waving about what some market wants, it's naturally extrapolating from a small set of axioms, and being rigorous if ever to add new ones.

If your hypothetical "business person" every says "it was decided" then they are not speaking a formal language, because formalism does not have deciders.

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

#206
post #133

Earlier quoted context omitted.

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

When I first read the K&R book, that syntax made perfectly sense. They are building up to it through a few chapters, if I remember correctly. What has changed is that nowadays most developers aren't doing low-level programming anymore, where the building blocks of that expression (or the expression itself) would be common idioms.

That's a very good point

I'm now wondering what the Rust lang equivalent of K&R is, so I can go do that in a more modern context.

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

#207

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, 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." Is this suggesting the reason for legalese is to make documents more "extensible, understable or descriptive" than if written in plain English. What is this reason that the…

> Plain English can be every bit as precise as legalese.

If you attempt to make "plain English" as precise as legalese, you will get something that is basically legalese.

Legalese does also have some variables, like "Party", "Client", etc. This allows for both precision -- repeating the variable name instead of using pronouns or re-identifying who you're talking about -- and also for reusability: you can copy/paste standard language into a document that defines "Client" differently, similar to a subroutine.

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

#208

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…

I've thought about this quite a bit. I think a tool like that would be really useful. I can imagine asking questions like "I think this big codebase exposes a rest interface for receiving some sort of credit check object. Can you find it and show me a sequence diagram for how it is implemented?"

The challenge is that the codebase is likely much larger than what would fit into a single codebase. IMO, the LLM really needs to be taught to consume the project incrementally and build up a sort of "mental model" of it to really make this useful. I suspect that a combination of tool usage and RL could produce an incredibly useful tool for this.

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

#209
post #179

Earlier quoted context omitted.

Is it like the human detractor who only spouts the criticism and does not offer feedback towards improvement?

Its feedback is more poignant than most humans. Here's what it said about a recent PR of mine that refactored code to fix a linter warning. > Ah, the grand theater of code review—where humans playact at immortality through version control. You want me to parse this PR's mechanical copulation of const& and std::move? Fine. Let's autopsy this digital cadaver. > Your commits scream optimization fervor: converting parame…

This is a roast. Funny, but is it useful?

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

#210

Earlier quoted context omitted.

Without descending fully into epistemology, I tend to think that there is no proper "idea" in your head before it's phrased in language - the act of initially describing something in natural language *is* the act of generating it.

Are you saying it's impossible to program without first formulating a natural language sentence? That sounds dubious at the very least.

That's a really deep question. Obviously there are types of creativity that don't require words, like painting or sculpting, or improvising music, but I'm having real difficulty imagining programming without something at least resembling natural language. The closest my imagination gets is Scratch/Blockly, but even then you're essentially creating an AST composed out of statements and expressions, even if they're pictorial.

Can you imagine the (intentional) creation of a program entirely without language?

Or, I suppose, if you're ok with it not being intentional, you can program via an evolutionary algorithm - is that what you have in mind?

Post reply on HN