Live data from Hacker News

Dijkstra On the foolishness of "natural language programming"

cs.utexas.edu

81–90 of 281 posts

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

#81
Using natural language to specify and build an application is not unlike having a game design document before you actually start prototyping your game. But once you have implemented the bulk of what you wanted, the implementation becomes the reference and you usually end up throwing away the GDD since it's now out of sync with the actual game.

Insisting that for every change one should go read the GDD, implement the feature and then sync back the GDD is cumbersome and doesn't work well in practice. I've never seen that happen.

But if there ever comes a time when some AI/LLM can code the next version of Linux or Windows from scratch based on some series of prompts, then all bets are off. Right now it's clearly not there yet, if ever.

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

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

No, the key difference is that an engineer becomes more product-oriented, and the technicalities of the implementation are deprioritized.

It is a different paradigm, in the same way that a high-level language like JavaScript handles a lot of low-level stuff for me.

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

#83
post #12

(2010) by the way, which makes this article all the more impressive. I was under the assumption this was a current body of work seeing as Dijkstra spoke so well about the possibilities but this just goes to show some people were ahead of their tike with their worries. Also adding your home address to something you write / publish / host on the internet is pretty hardcore.

Dijkstra died in 2002, so I assume 2010 is just the date of transcription

1979. https://doi.org/10.1007/BFb0014656

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

#84
post #59

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…

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.

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

#85
post #53
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…

you guys are not wrong. explain any semi complez program, you will instantly resort to diagrams, tables, flow charts etc. etc. ofcourse, you can get your LLM to be bit evil in its replies, to help you truly. rather than to spoon feed you an unhealthy diet. i forbid my LLM to send me code and tell it to be harsh to me if i ask stupid things. stupid as in, lazy questions. send me the link to the manual/specs with an RT…

If you don't mind sharing - what's the specific prompt you use to get this to happen, and which LLM do you use it with?

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

#88
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 feel that's merely side-stepping the issue: if natural language is not succint and unambiguous enough to fully specify a software program, how will any "ordinary person" trying to write software with it be able to avoid these limitations?

In the end, people will find out that in order to have their program execute successfully they will need to be succinct in their wording and construct a clear logic flow in their mind. And once they've mastered that part, they're halfway to becoming a programmer themselves already and will either choose to hire someone for that task or they will teach themselves a non-natural programming language (as happened before with vbscript and php).

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

#90
post #30
post #28

Earlier quoted context omitted.

Sure but we build (leaky) abstractions, and this is even happens in legal texts. Asking an llm to build a graphical app in assembly from an ISA and a driver for the display would give you nothing. But with a mountain of abstractions then it can probably do it. This is not to defend an LLM more to say I think that by providing the right abstractions (reusable components) then I do think it will get you a lot closer.

Being doing toy-examples of non-trivial complexity. Architecting the code so context is obvious and there are clear breadcrumbs everywhere is the key. And the LLM can do most of this. Prototype-> refactor/cleanup -> more features -> refactor / cleanup add architectural notes. If you know what a well architected piece of code is supposed to look like, and you proceed in steps, LLM gets quite far as long as you are han…

This begs the question, how many of the newer generation of developers/engineers "know what a well architected piece of code is supposed to look like"?
Post reply on HN