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

111–120 of 281 posts

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

#111

Post by card_zero »

still_grokking wrote: post #103
card_zero wrote: post #96

Earlier quoted context omitted.

> Explorative work becomes quite difficult if the type system is really rigid Or to put it another way, the ease of programming is correlated with the ease of making undetected mistakes.

I'm not sure you tried to understand what I've depicted. As long as you don't know how the end result should look like there are no "mistakes" . The whole point of explorative work is to find out how to approach something in the first place. It's usually impossible to come up with the final result at first try! After you actually know how to do something in general tools which help to avoid all undetected mistakes in…

"Rust as both language and community is so preoccupied with avoiding problems at all cost that it completely loses sight of what matters, delivering an experience that is so good that whatever problems are there aren't really important."

Eh, I'm being mugged by Rust-lovers. But as soon as I read Dijkstra's snotty remark about how making mistakes is the opposite of easy (!?) I had an intuitive reaction of "balls". Maybe that was a mistake, but it came easy.

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

#112

Post by skydhash »

WillAdams wrote: post #63
dr_dshiv wrote: post #50

Earlier quoted context omitted.

Vibes aren’t really about clarity, are they? The point is that a clear, programmatic approach is not the only effective computational mechanism for realizing intentions anymore. Keep in mind that Dijkstra had some giant shoulders to stand on. This article is the very first one I’ve ever seen that directly dealt with vibes.

The thing is, for at least some readers, the attraction of _The Glass Bead Game_ and similar abstractions is that they should be able to communicate more clearly, and without the ambiguity of natural language, but with a naturalness which allows unbridled expression. I really would like to see such a programming system realized, see efforts at: https://github.com/IndieSmiths/myappmaker-sdd but the more I work at prog…

> I just need to find the perfect GUI toolkit which allows Bézier Curve representations in a way which clicks and makes sense to me, and suits my next project.

Not a proper answer, but here is a very good video on splines:

https://youtu.be/jvPPXbo87ds

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

#113

Post by jimmydddd »

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…

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

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

#114

Post by WillAdams »

skydhash wrote: post #112
WillAdams wrote: post #63

Earlier quoted context omitted.

The thing is, for at least some readers, the attraction of _The Glass Bead Game_ and similar abstractions is that they should be able to communicate more clearly, and without the ambiguity of natural language, but with a naturalness which allows unbridled expression. I really would like to see such a programming system realized, see efforts at: https://github.com/IndieSmiths/myappmaker-sdd but the more I work at prog…

> I just need to find the perfect GUI toolkit which allows Bézier Curve representations in a way which clicks and makes sense to me, and suits my next project. Not a proper answer, but here is a very good video on splines: https://youtu.be/jvPPXbo87ds

It was that video which gave me the hope that I would be able to master the math necessary for what I wish to do.

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

#115

Post by moralestapia »

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

This is one of the best comments I've read on this site in a long while.

A single, crude, statement of fact slaying the work of a million typewriter monkeys spewing out random characters thinking they're actually writing the Shakespeare novel, lmao.

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

#116

Post by tim333 »

WillAdams wrote: post #56
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…

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.

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

#117

Post by kmoser »

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?

Nothing wrong with that as long as the expected behavior is formally described (even if that behavior is indeterminate or undefined) and easy to look up. In fact, that's a great use for LLMs: to explain what code is doing (not just writing the code for you).

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

#118

Post by tim333 »

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…

> prefer the coded format. Is is compact...

On the other hand "a folder that syncs files between devices and a server" is probably a lot more compact than the code behind Dropbox. I guess you can have both in parallel - prompts and code.

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

#119

Post by xwiz »

jimmydddd wrote: post #113
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…

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

This opens an interesting possibility for a purely symbol-based legal code. This would probably improve clarity when it came to legal phrases that overlap common English, and you could avoid ambiguity when it came to language constructs, like in this case[1], where some drivers were losing overtime pay because of a comma in the overtime law.

[1] https://cases.justia.com/federal/appellate-courts/ca1/16-190...

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

#120

Post by soraminazuki »

soulofmischief wrote: post #100
soraminazuki wrote: post #99

Earlier quoted context omitted.

A programming language implementation produces results that are controllable, reproducible, and well-defined. An LLM has none of those properties, which makes the comparison moot. Having an LLM make up underspecified details willy-nilly, or worse, ignore clear instructions is very different from programming languages "handling a lot of low-level stuff."

[citation needed] You can set temperature to 0 in many LLMs and get deterministic results (on the same hardware, given floating-point shenanigans). You can provide a well-defined spec and test suite. You can constrain and control the output.

LLMs produce deterministic results? Now, that's a big [citation needed]. Where can I find the specs?

Edit: This is assuming by "deterministic," you mean the same thing I said about programming language implementations being "controllable, reproducible, and well-defined." If you mean it produces random but same results for the same inputs, then you haven't made any meaningful points.

Post reply on HN