←back to thread

448 points nimbleplum40 | 1 comments | | HN request time: 0.2s | source
Show context
01100011 ◴[] No.43566393[source]

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 description is easier to reason about?

I think there's a reason most of the vibe-coded applications we see people demonstrate are rather simple. There is a level of complexity and precision that is hard to manage. Sure, you can define it in plain english, but is the resulting description extensible, understandable, or more descriptive than a precise language? I think there is a reason why legalese is not plain English, and it goes beyond mere gatekeeping.

replies(12): >>43566585 #>>43567611 #>>43567653 #>>43568047 #>>43568163 #>>43570002 #>>43570623 #>>43571775 #>>43571852 #>>43573317 #>>43575360 #>>43578775 #
fluidcruft ◴[] No.43568047[source]

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 in their notes. Compact forms and abstractions help reduce demands for working memory and information search. So I'm not sure it's about language precision.

replies(2): >>43568144 #>>43571228 #
card_zero ◴[] No.43568144[source]

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

replies(8): >>43568588 #>>43569499 #>>43569619 #>>43570182 #>>43571065 #>>43571967 #>>43572616 #>>43580134 #
fluidcruft ◴[] No.43568588[source]

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.

replies(1): >>43569780 #
1. skydhash ◴[] No.43569780[source]

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