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

101–110 of 281 posts

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

#101

Post by alankarmisra »

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?

I would guard against "arguing from the extremes". I would think "on average" compact is more helpful. There are definitely situations where compactness can lead to obfuscation but where the line is depends on the literacy and astuteness of the reader in the specific subject as already pointed out by another comment. There are ways to be obtuse even in the other direction where written prose can be made sufficiently complicated to describe even the simplest things.

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

#102

Post by nizarmah »

One of the most challenging aspects in my career has been: communication.

This is largely because it leaves chance for misinterpretation or miscommunication. Programming languages eliminated misinterpretation and made miscommunication easier to notice through errors.

Programming language enables micromanaging proactively, I specify the instructions before they run. I often find myself micromanaging retroactively with LLMs, until I reach the path I am looking for.

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

#103

Post by still_grokking »

card_zero wrote: post #96
still_grokking wrote: post #92

Earlier quoted context omitted.

Rust? Since when is Rust the pinnacle of static type safety? After I've worked for some time with a language that can express even stronger invariants in types than Rust (Scala) I don't see that property anymore as clear win regardless circumstances . I don't think any more "stronger types == better, no matter what". You have a price to pay for "not being allowed to do mistakes": Explorative work becomes quite diffic…

> 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 the implementation of the chosen approach are really indispensable. But before having this general approach figured out too much rigidity is not helpful but instead a hindrance.

To understand this better read the linked article. It explains the problem very well over a few paragraphs.

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

#104

Post by yagyu »

In the same vein, Asimov in 1956:

Baley shrugged. He would never teach himself to avoid asking useless questions. The robots knew. Period. It occurred to him that, to handle robots with true efficiency, one must needs be expert, a sort of roboticist. How well did the average Solarian do, he wondered?

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

#105

Post by roccomathijn »

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

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

#106

Post by card_zero »

fluoridation wrote: post #98
card_zero wrote: post #58

Earlier quoted context omitted.

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

No, but *++d = *++s; does.

That means you have to point just before the source and destination.

(Yeah, I forgot the while: while *d++ = *s++;)

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

#107

Post by skydhash »

fluidcruft wrote: post #79
card_zero wrote: post #58

Earlier quoted context omitted.

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

That's probably analogous to reading levels. So it would depend on the reading level of the intended audience. I haven't used C in almost a decade and I would have to refresh/confirm the precise orders of operations there. I do at least know that I need to refresh and after I look it up it should be fine until I forget it again. For people fluent in the language unlikely to be a big deal. Conceivably, if there were a…

> APL is another example of dense languages that (some) people like to work in.

I recently learn an array programming language called Uiua[0] and it was fun to solve problems in it (I used the advent of code's ones). Some tree operation was a bit of a pain, but you can get very concise code. And after a bit, you can recognize the symbols very easily (and the editor support was good in Emacs).

[0]: https://www.uiua.org/

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

#108

Post by chongli »

vbezhenar wrote: post #80
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…

The point of LLM is to enable "ordinary people" to write software. This movement is along with "zero code platform", for example. Creating algorithms by drawing block-schemes, by dragging rectangles and arrows. This is old discussion and there are many successful applications of this nature. LLM is just another attempt to tackle this beast. Professional developers don't need this ability indeed. Most professional dev…

I think this is the principle-agent problem at work. Managers/executives who don't understand what programmers do believing that programmers can be easily replaced. Why wouldn't LLM vendors offer to sell it to them?

I pity the programmers of the future who will be tasked with maintaining the gargantuan mess these things end up creating.

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

#109

Post by throw1111221 »

cubefox wrote: post #71
hamstergene wrote: post #5

Reminds me of another recurring idea of replacing code with flowcharts. First I've seen that idea coming from some unknown Soviet professor from 80s, and then again and again from different people from different countries in different contexts. Every time it is sold as a total breakthrough in simplicity and also every time it proves to be a bloat of complexity and a productivity killer instead. Or weak typing. How ma…

> 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

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

#110

Post by skydhash »

nottorp wrote: post #40
misja111 wrote: 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…

Say, doesn't each business - each activity - have its own formal language? Not as formalized as programming languages, but it's there. Try to define any process, you end up with something trending towards formalized even if you don't realize it.

That's pretty much the whole basis of Domain Driven Design. The core message is to get to an Ubiquitous Language which is the formalization of the business jargon (pretty much a glossary). From which the code can then be derived naturally.
Post reply on HN