Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dijkstra On the foolishness of "natural language programming"

cs.utexas.edu

Post reply on HN
Print view View original

251–260 of 281 posts

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

#251

Post by anonzzzies »

card_zero wrote: post #58
fluidcruft wrote: post #54

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?

Arthur Whitney writes compact code in C (and in k of course); most things fit on one A4 which is actually very nice to me as an older person. I cannot remember as much as I could (although i'm still ok) and just seeing everything I need to know for a full program on 1 page is very nice vs searching through a billion files, jump to them, read, jump back and actually mostly forgotten the 1000 steps between (I know, this refers to a typical overarchitected codebase I have to work on, but I see many of those unfortunately).

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

#253

Post by xpmatteo »

codebje wrote: post #232
School-Cotton wrote: post #220

Earlier quoted context omitted.

Theorems and proofs are almost never written in formal symbolic language.

My experience in reading computer science papers is almost exactly the opposite of yours: theorems are almost always written in formal symbolic language. Proofs vary more, from brief prose sketching a simple proof to critical components of proofs given symbolically with prose tying it together. (Uncommonly, some papers - mostly those related to type theory - go so far as to reference hundreds of lines of machine veri…

Common expressions such as f = O(n) are not formal at all -- the "=" symbol does not represent equality, and the "n" symbol does not represent a number.

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

#255

Post by pyrale »

haolez wrote: 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…

Hal Abelson, casually enraging functional programing CS people around the world.

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

#256

Post by pyrale »

roccomathijn wrote: post #105
l0new0lf-G wrote: post #61

Finally someone put it this way! Natural language has embedded limitations that stem from our own mental limitations -the human mind thinks sometimes too abstract or too specific things, and misses important details or generalizations. 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 symboli…

The man has been dead for 23 years

I wonder how long we have to wait before we can pitch a machine that presses fruit juice packs into a glass to gullible VCs again.

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

#257

Post by Sammi »

drpixie wrote: post #45
01100011 wrote: post #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 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…

What do I need to google in order to learn about this format?

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

#258

Post by corimaith »

diputsmonro wrote: post #173
drpixie wrote: post #45

Earlier quoted context omitted.

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

An interesting perspective on this is that language is just another tool on the job. Like any other tool, you use the kind of language that is most applicable and efficient. When you need to describe or understand weather conditions quickly and unambiguously, you use METAR. Sure, you could use English or another natural language, but it's like using a multitool instead of a chef knife. It'll work in a pinch, but a to…

I would caution to point of that the Strong Sapir-Whorf hypothesis is debunked; Language may influence your understanding, but it's not deterministic and just means more words to explain a concept for any language.

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

#259

Post by yencabulator »

falcor84 wrote: post #247
yencabulator wrote: post #211

Earlier quoted context omitted.

I think you're the kind of person who has an internal voice talking in their head, and can't imagine any other kind of thought? Math is all about abstract shapes and properties, for me. So is much of programming.

Yeah, I suppose you're right and I'd love to understand more. Do you imagine a modality of programming a computer in an abstract (pictorial? diagrammatic?) way that fully bypasses the current need to form statements?

Let's try this as an example.

    fn foo() -> Result { ... }

    let x = foo();
    match x {
        Ok(num) => println!("foo is {num}");
        Err(error) => eprintln!("no foo for you: {error:?}");
    }
So I have in my head a thing that has the name "x" and a spatial connection to that area of the source code where foo is called.

x is a Result and in my head that's a vague abstract shape with the "potential" to be either the uint32 shape (in my mind, a "brick" of a certain size) or a MyError shape (vague blob and since I know it's an enum it also has its own "potential" to be multiple shapes; it kind of has the branchiness of a tree without being tree-shaped; this is all abstract and concepts, not concrete shapes).

When "x" meets the "match" the "x" shape splits into its "potential" shapes, and "num" has the uint32 brick shape.

None of this has anything to do with visual programming like Scratch. It's just that I never say in my head words like "x has value of what foo returns" or "num is an uint32"; those just are.

Does that make any sense to you?

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

#260

Post by rootnod3 »

light_triad wrote: post #176
haolez wrote: 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…

This is key: computation is about making things happen. Coding with an LLM adds a level of abstraction but the need for precision and correctness of the "things that happen" doesn't go away. No matter how many cool demos and "coding is dead" pronouncements because AI - and the demos are very cool - the bulk of the work moves to the pre- and post-processing and evals with AI. To the extent that it makes programming mo…

Yeah but in the end when it comes down to it, one would have to specify the exact details, especially for very intricate systems. And the more and more you would abstract and specialize that language for the LLM, you end up going a very long round about way to re-inventing code basically.
Post reply on HN