Live data from Hacker News

Dijkstra On the foolishness of "natural language programming"

cs.utexas.edu

71–80 of 281 posts

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

#71

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/statistics/793628/worldwide-develop...

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

#72
Over the last couple of weeks or so of me finally starting to use AI pair programming tools (for me, Cursor) I've been realizing that, much like when I play music, I don't really think about programming a natural language terms in the first place, it's actually been kind of hard to integrate an AI coding agent into my workflow mentally

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

#73

- some people found error messages they couldn't ignore more annoying than wrong results I wonder if this is a static vs dynamic or compiled vs interpreted reference. Anyway I love it. Made me giggle that we are still discussing this today, and just to be clear I love both sides, for different things.

50 years ago, in "The Mythical Man-Month" Fred Brooks was already discussing the cost of cloud based solutions.

> Since size is such a large part of the user cost of a programming system product, the builder must set size targets, control size, and devise size-reduction techniques, just as the hardware builder sets component-count targets, controls component count, and devises count-reduction techniques. Like any cost, size itself is not bad, but unnecessary size is.

And the why of Agile, DDD and TDD:

> Plan the System for Change [...] Plan the Organization for Change

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

#74

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…

Yes! I have a certain personality preference for abstractions and tend to understand things in an abstract manner which is extremely difficult for me to articulate in natural language.

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

#75

This is the most beautiful thing I've read in a long time.

Me too, I printed it and underlined it, I will try to memorize some of the concepts and the exposition, because this is a cristallization of what I vaguely feel about the abuse of LLM I am currently witnessing

Absolutely with you on the abuse of LLMs. I'm deeply concerned about loss of competence and I am so burned out from having to deal with other people's messy and overly complex code.

I think people who think about this like us need to start building resilience for the very real possibility that in a couple of years we'll be the ones dealing with these awful LLM-generated code bases, fixing bad logic and bugs.

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

#76
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

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

Most formulas made of fancy LaTeX symbols you find in math papers aren't a formal language either. They usually can't be mechanically translated via some parser to an actual formal language like Python or Lean. You would need an advanced LLM for that. But they (the LaTeX formulas) are still more precise than most natural language. I assume something similar is the case with legalese.

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

#78
> Remark. As a result of the educational trend away from intellectual discipline, the last decades have shown in the Western world a sharp decline of people's mastery of their own language: many people that by the standards of a previous generation should know better, are no longer able to use their native tongue effectively, even for purposes for which it is pretty adequate.

Compare that to:

https://news.ycombinator.com/item?id=43522966

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

#79

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?

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 an equivalent of "8th grade reading level" for C that forbade pointer arithmetic on the left hand side of an assignment (for example) it could be reformatted by an LLM fairly easily. Some for loop expressions would probably be significantly less elegant, though. But that seems better that converting it to English.

That might actually make a clever tooltip sort of thing--highlight a snippet of code and ask for a dumbed-down version in a popup or even an English translation to explain it. Would save me hitting the reference.

APL is another example of dense languages that (some) people like to work in. I personally have never had the time to learn it though.

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

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

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 developers, who had to deal with zero code platforms, probably would prefer to just work with ordinary code.

Post reply on HN