Live data from Hacker News

Dijkstra On the foolishness of "natural language programming"

cs.utexas.edu

181–190 of 281 posts

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

#181

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 think there is a reason why legalese is not plain English This is true. Part of the precision of legalese is that the meanings of some terms have already been more precisely defined by the courts.

Yeah, my theory on this has always been that a lot of programming efficiency gains have been the ability to unambiguously define behavior, which mostly comes from drastically restricting the possible states and inputs a program can achieve.

The states and inputs that lawyers have to deal with tend to much more vague and imprecise (which is expected if you're dealing with human behavior and not text or some other encodeable input) and so have to rely on inherently ambiguous phrases like "reasonable" and "without undue delay."

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

#182
post #71

Earlier quoted context omitted.

> 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. Yet JavaScript and Python are the most widely used programming languages [1]. Which suggests your analysis is mistaken here. [1] https://www.statista.com/stat…

Python went through a massive effort to add support for type annotations due to user demand. Similarly, there's great demand for a typed layer on top of Javascript: - Macromedia: (2000) ActionScript - Google: (2006) GWT [Compiling Java to JS], and (2011) Dart - Microsoft: (2012) Typescript

You’re talking about static typing, the opposite of which is dynamic typing. User hamstergene is talking about weak vs. strong typing, which is another thing entirely. Python has always been strongly typed, while JavaScript is weakly typed. Many early languages with dynamic types also experimented with weak typing, but this is now, as hamstergene points out, considered a bad idea, and virtually all modern languages, including Python, are strongly typed.

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

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

As somebody that occasionally studies pure math books those can be very, very light on regular English.

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

#184
About every six to ten years I look in on the state of the art on making artificial human languages in which one cannot be misunderstood.

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.

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

#185
post #45

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…

> Do you find the resulting natural language description is easier to reason about? An example from an different field - aviation weather forecasts and notices are published in a strongly abbreviated and codified form. For example, the weather at Sydney Australia now is: METAR YSSY 031000Z 08005KT CAVOK 22/13 Q1012 RMK RF00.0/000.0 It's almost universal that new pilots ask "why isn't this in words?". And, indeed, mos…

And to this point - the English language has far more ambiguity than most programming languages.

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

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

I was actually positively surprised at how well even qwen2.5-coder:7b managed to talk through a file of Rust. I'm still a current-day-LLM-programming skeptic but that direction, code->English, seems a lot safer, since English is ambiguous anyway. For example, it recognized some of the code shapes and gave English names that can be googled easier.

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

#187
post #60

Earlier quoted context omitted.

What you're describing is decontextualization. A sufficiently powerful transformer would theoretically be able recontextualize a sufficiently descriptive natural language specification. Likewise, the same or an equivalently powerful transformer should be able to fully capture the logic of a complicated program. We just don't have sufficient transformers yet. I don't see why a complete description of the program's des…

>sufficiently descriptive natural language specification https://www.commitstrip.com/en/2016/08/25/a-very-comprehensi...

sounds like it would pair well with a suitably smart compiler

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

#188

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 parent thinks legalese is used that "goes beyond gatekeeping".

Plain English can be every bit as precise as legalese.

It is also unclear that legalese exists for the purpose of gatekeeping. For example, it may be an artifact that survives based on familiarity and laziness.

Law students are taught to write in plain English.

https://www.law.columbia.edu/sites/default/files/2021-07/pla...

In some situations, e.g., drafting SEC filings, use of plain English is required by law.

https://www.law.cornell.edu/cfr/text/17/240.13a-20

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

#189

Earlier quoted context omitted.

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.

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.

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

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

Congratulations, you have unearthed a new layer of hell.
Post reply on HN