←back to thread

448 points nimbleplum40 | 1 comments | | HN request time: 0s | 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 #
jimmydddd ◴[] No.43570002[source]
--I think there is a reason why legalese is not plain English

This is true. Part of the precision of legalese is that the meanings of some terms have already been more precisely defined by the courts.

replies(2): >>43570287 #>>43572738 #
xwiz ◴[] No.43570287[source]
This opens an interesting possibility for a purely symbol-based legal code. This would probably improve clarity when it came to legal phrases that overlap common English, and you could avoid ambiguity when it came to language constructs, like in this case[1], where some drivers were losing overtime pay because of a comma in the overtime law.

[1] https://cases.justia.com/federal/appellate-courts/ca1/16-190...

replies(1): >>43571234 #
1. ◴[] No.43571234{3}[source]