So this has already been conceived of many decades ago, and there are some substantial issues with it, the illustrious djikstra covers it: https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...

Now this isn’t to say the current programming languages are good, they are generally not. They don’t offer good abstraction powers, typically. You pay for this in extra lines of code.

But having to restate everything in English, then hoping that the LLM will fill in enough details, then iterating until you can close the gaps, well it doesn’t seem super efficient to me. You either cede control to what the LLM guesses or you spend a lot of natural language.

Certainly in a language with great abstractions you’d be fine already.

▲

quantumgarbage a day ago | parent | next [-]

Ah so I was right to scroll down to find a sane take

▲

nojito a day ago | parent | prev [-]

It’s no different from translating business requirements into code.

Djikstra was talking about something completely different.

	▲	sponnath a day ago \| parent \| next [-]
		True but this only works well if the natural language "processor" was reliable enough to properly translate business requirements into code. LLMs aren't there yet.
	▲	lou1306 a day ago \| parent \| prev [-]
		Exactly, and translating business requirements into code is so frustrating and error-prone that entire philosophies (and consulting firms) have been built around it. LLMs are no silver bullet, they are just faster to come up with _something_.