8 ms·

I am not convinced. - Natural languages are ambiguous. That's the reason why we created programming languages. So the documentation around the code is generall

by palata 8mo ago

I am not convinced. - Natural languages are ambiguous. That's the reason why we created programming languages. So the documentation around the code is generally ambiguous as well. Worse: it's not being executed, so it can get out of date (sometimes in subtle ways). - LLMs are trained on tons of source code, which is arguably a smaller space than natural languages. My experience is that LLMs are really good at e.g. translating code between two programming languages. But translating my prompts to code is not working as well, because my prompts are in natural languages, and hence ambiguous. - I wonder if it is a question of "natural languages vs programming languages" or "bad code vs good code". I could totally imagine that documenting bad code helps the LLMs (and the humans) understand the intent, while documenting good code actually adds ambiguity. What I learned is that we write code for humans to read. Good code is code that clearly expresses the intent. If there is a need to comment the code all over the place, to me it means that the code is maybe not as good as it should be :-). Of course there is an argument to make that the quality of code is generally getting worse every year, and therefore there is more and more a need for documentation around it because it's getting hard to understand what the hell the author wanted to do.

hosh 8mo ago
I don’t have my LLMs generate literate programming. I do ask it to talk about tradeoffs. I have full examples of something that is heavily commented and explained, including links to any schemas or docs. I have gotten good results when I ask an LLM to use that as a template, that not everything in there needs to be used, and it cuts down on hallucinations by quite a bit.
bottd 8mo ago
> If there is a need to comment the code all over the place, to me it means that the code is maybe not as good as it should be :-) If good code was enough on its own we would read the source instead of documentation. I believe part of good software is good documentation. The prose of literate source is aimed at documentation, not line-level comments about implementation.
- WillAdams 8mo ago
  https://diataxis.fr/ https://diataxis.fr/ (originally developed at: https://docs.divio.com/documentation-system/ https://docs.divio.com/documentation-system/) --- divides documentation along two axes: - Action (Practical) vs. Cognition (Theoretical) - Acquisition (Studying) vs. Application (Working) which for my current project has resulted in: - readme.md --- (Overview) Explanation (understanding-oriented) - Templates (small source snippets) --- Tutorials (learning-oriented) - Literate Source (pdf) --- How-to Guides (problem-oriented) - Index (of the above pdf) --- Reference (information-oriented)
  - zenoprax 8mo ago
    I've been trying to implement this as closely as possible from scratch in an existing FOSS project: https://github.com/super-productivity/super-productivity/wiki https://github.com/super-productivity/super-productivity/wik... Even with a well-described framework it is still hard to maintain proper boundaries and there is always a temptation to mix things together.
  - ramses0 8mo ago
    README => AGENTS.md HOWTO => SKILLS.md INFO => Plan/Arch/Guide REFERENCE => JavaDoc-ish I'm very near the idea that "LLM's are randomized compilers" and the human prompts should be 1000% more treated with care. Don't (necessarily) git commit the whole megabytes of token-blathering from the LLM, but keeping the human prompts: "Hey, we're going to work on Feature X... now some test cases... I've done more testing and Z is not covered... ok, now we'll extend to cover Case Y..." Let me hover over the 50-100 character commit message and then see the raw discussion (source) that led to the AI-generated (compiled) code. Allow AI.next to review the discussion/response/diff/tests and see if it can expose any flaws with the benefit of hindsight!
- AdieuToLogic 8mo ago
  > If good code was enough on its own we would read the source instead of documentation. An axiom I have long held regarding documenting code is: Code answers what it does, how it does it, when it is used, and who uses it. What it cannot answer is why it exists. Comments accomplish this.
awesome_dude 8mo ago
> Natural languages are ambiguous. That's the reason why we created programming languages. So the documentation around the code is generally ambiguous as well. Worse: it's not being executed, so it can get out of date (sometimes in subtle ways). I loathe this take. I have rocked up to codebases where there were specific rules banning comments because of this attitude. Yes comments can lie, yes there are no guards ensuring they stay in lock step with the code they document, but not having them is a thousand times worse - I can always see WHAT code is doing, that's never the problem, the problems is WHY it was done in this manner. I put comments like "This code runs in O(n) because there are only a handful of items ever going to be searched - update it when there are enough items to justify an O(log2 n) search" That tells future developers that the author (me) KNOWS it's not the most efficient code possible, but it IS when you take into account things unknown by the person reading it Edit: Tribal knowledge is the worst type of knowledge, it's assumed that everyone knows it, and pass it along when new people onboard, but the reality (for me) has always been that the people doing the onboarding have had fragments, or incorrect assumptions on what was being conveyed to them, and just like the childrens game of "telephone" the passing of the knowledge always ends in a disaster
- AdieuToLogic 8mo ago
  > Yes comments can lie ... Comments only lie if they are allowed to become one. Just like a method name can lie. Or a class name. Or ...
  - bonesss 8mo ago
    Right. The compiler ensures that the code is valid, and what ensures that ‘// used a suboptimal sort because reasons’ is updated during a global refactor that changes the method? … some dude living in that module all day every day exercising monk-like discipline? That is unwanted for a few reasons, notably the routine failures of such efforts over time. Module names and namespaces and function names can lie. But they are also corrected wholesale and en-masse when first fixed, those lies are made apparent when using them. If right_pad() is updated so it’s actually left_pad() it gets caught as an error source during implementation or as an independent naming issue in working code. If that misrepresentation is the source of an emergent error it will be visible and unavoidable in debugging if it’s in code, and the subsequent correction will be validated by the compiler (and therefore amenable to automated testing). Lies in comments don’t reduce the potential for lies in code, but keeping inline comments minimal and focused on exceptional circumstances can meaningfully reduce the number of aggregate lies in a codebase.
k32k 8mo ago
"But translating my prompts to code is not working as well, because my prompts are in natural languages, and hence ambiguous." Not only that, but there's something very annoying and deeply dissatisfying about typing a bunch of text into a thing for which you have no control over how its producing an output, nor can an output be reproduced even if the input is identical. Agreed natural language is very ambiguous and becoming more ambiguous by the day "what exactly does 'vibe' mean?". People spoke in a particular way, say 60 years ago, that left very little room for interpretation of what they meant. The same cannot be said today.
- caseyohara 8mo ago
  > People spoke in a particular way, say 60 years ago, that left very little room for interpretation of what they meant. The same cannot be said today. Surely you don’t mean everyone in the 1960s spoke directly, free of metaphor or euphemism or nuance or doublespeak or dog whistle or any other kind or ambiguity? Then why are there people who dedicate their entire life to interpreting religious texts and the Constitution?
  - k32k 8mo ago
    Compared with today, on average, they did. There's a generation of people that 'typ lyk dis'. So yes.
    - jyounker 8mo ago
      Your point is less persuasive than you intended. You complain about linguistic ambiguity, but then you show an example of sensible spelling reform.
    - ChrisGreenHeur 8mo ago
      that example is regarding syntax, and is actually no worse than any other
deleted 8mo ago
[deleted]
casey2 8mo ago
Programming languages are natural and ambiguous too, what does READ mean? you have to look it up to see the types. The power comes from the fact that it's audit-able, but that you don't need to audit it every time you want to write some code. You think you write good code? try to prove it after the compiler gets through with it. Natural languages are richer in ideas, it may be harder to get working code going from a purely natural description to code, than code to code, but you don't gain much from just translating code. One is only limited by your imagination the other already exists, you could just call it as a routine. You only have a SENSE for good code because it's a natural language with conventions and shared meaning. If the goal of programming is to learn to communicate better as humans then we should be fighting ambiguity not running from it. 100 years from now nobody is going to understand that your conventions were actually "good code".
- musicale 8mo ago
  > Programming languages are natural and ambiguous too Programming languages work because they are artificial (small, constrained, often based on algebraic and arithmetic expressions, boolean logic, etc.) and have generally well-defined semantics. This is what enables reliable compilers and interpreters to be constructed.
  - mexicocitinluez 8mo ago
    Exactly. Programming is the art of removing ambiguity and making it formal. And it's why the timelines between getting an EXACT plan of what I need to implement vs hazy requirements are so out of whack.
- mexicocitinluez 8mo ago
  > Programming languages are natural and ambiguous too, what does READ mean? Not nearly in the same sense actual language is ambiguous. And ambiguity in programming is usually a bad thing, whereas in language it can usually be intended. Good code, whatever that means, can read like a book. Event-driven architectures is a good example because the context of how something came to be is right in the event name itself.
- 8mo ago
pdntspa 8mo ago
> because my prompts are in natural languages, and hence ambiguous. Legalese developed specifically because natural language was too ambiguous. A similar level of specificity for prompting works wonders One of the issues with specifying directions to the computer with code is that you are very narrowly describing how something can be done. But sometimes I don't always know the best 'how', I just know what I know. With natural language prompting the AI can tap into its training knowledge and come up with better ways of doing things. It still needs lots of steering (usually) but a lot of times you can end up with a superior result.
- vnorilo 8mo ago
  Yes. LLMs are search engines into the (latent) space or source code. Stuff you put into the context window is the "query". I've had some good results by minimizing the conversational aspect, and thinking in terms of shaping the context: asking the LLM to analyze relevant files, nor because I want the analysis, but because I want a good reading in the context. LLMs will work hard to stay in that "landscape", even with vague prompts. Often better than with weirdly specific or conflicting instructions.
  - ptx 8mo ago
    But search engines are not a good interface when you already know what you want and need to specify it exactly. See for example the new Windows start menu compared to the old-school run dialog – if I directly run "notepad", then I get always Notepad; but if I search for "notepad" then, after quite a bit of chugging and loading and layout shifting, I might get Notepad or I might get something from Bing or something entirely different at different times.
    - vnorilo 8mo ago
      Indeed, which is not all that different from LLM code generation, to be honest.
- Copyrightest 8mo ago
  [dead]
baq 8mo ago
Docs and code work together as mutually error correcting codes. You can’t have the benefits of error detection and correction without redundant information.
- ghywertelling 8mo ago
  > With agents, does it become practical to have large codebases that can be read like a narrative, whose prose is kept in sync with changes to the code by tireless machines? I think this is true. Your point supports it. If either the explanation / intention or the code changes, the other can be brought into sync. Beautiful post. I always hated the fact that research papers don't read like novels, eg "ohk, we tried this which was unsuccessful but then we found another adjacent approach and it helped." Computer Scientist Explains One Concept in 5 Levels of Difficulty | WIRED https://www.youtube.com/watch?v=fOGdb1CTu5c https://www.youtube.com/watch?v=fOGdb1CTu5c Computer scientist Amit Sahai, PhD, is asked to explain the concept of zero-knowledge proofs to 5 different people; a child, a teen, a college student, a grad student, and an expert. Using a variety of techniques, Amit breaks down what zero-knowledge proofs are and why it's so exciting in the world of cryptography.
alkonaut 8mo ago
Maybe if we had a really terse and unambiguous form of English? Whenever there is ambiguity we insert parentheses and operators to really make it clear what we mean. We can enclose different sentences in brackets to make sure that the scope of a logical condition and so on. Oh wait
gwbas1c 8mo ago
> That's the reason why we created programming languages. No, we created programming languages because when computers were invented: 1: They (computers) were incapable of understanding natural language. 2: Programming languages are easier to use than assembly or writing out machine code by hand. LLMs are a quite recent invention, and require significantly more computing power than early computers had.
psychoslave 8mo ago
>Natural languages are ambiguous. That's the reason why we created programming languages. Programming languages can be ambiguous too. The thing with formal languages is more that they put a stricter and narrower interpretation freedom as a convention where it's used. If anything there are a subset of human expression space. Sometime they are the best tool for the job. Sometime a metaphor is more apt. Sometime you need some humour. Sometime you better stay in ambiguity to play the game at its finest.
- palata 8mo ago
  Programming languages are non-ambiguous, in the sense that there is no doubt what will be executed. It's deterministic. If the program crashes, you can't say "no but this line was a joke, you should have ignored it". Your code was wrong, period.
  - cindyllm 8mo ago
    [dead]

by palata 8mo ago

hosh 8mo ago

I don’t have my LLMs generate literate programming. I do ask it to talk about tradeoffs. I have full examples of something that is heavily commented and explained, including links to any schemas or docs. I have gotten good results when I ask an LLM to use that as a template, that not everything in there needs to be used, and it cuts down on hallucinations by quite a bit.

bottd 8mo ago

> If there is a need to comment the code all over the place, to me it means that the code is maybe not as good as it should be :-) If good code was enough on its own we would read the source instead of documentation. I believe part of good software is good documentation. The prose of literate source is aimed at documentation, not line-level comments about implementation.

WillAdams 8mo ago
https://diataxis.fr/ https://diataxis.fr/ (originally developed at: https://docs.divio.com/documentation-system/ https://docs.divio.com/documentation-system/) --- divides documentation along two axes: - Action (Practical) vs. Cognition (Theoretical) - Acquisition (Studying) vs. Application (Working) which for my current project has resulted in: - readme.md --- (Overview) Explanation (understanding-oriented) - Templates (small source snippets) --- Tutorials (learning-oriented) - Literate Source (pdf) --- How-to Guides (problem-oriented) - Index (of the above pdf) --- Reference (information-oriented)
- zenoprax 8mo ago
  I've been trying to implement this as closely as possible from scratch in an existing FOSS project: https://github.com/super-productivity/super-productivity/wiki https://github.com/super-productivity/super-productivity/wik... Even with a well-described framework it is still hard to maintain proper boundaries and there is always a temptation to mix things together.
- ramses0 8mo ago
  README => AGENTS.md HOWTO => SKILLS.md INFO => Plan/Arch/Guide REFERENCE => JavaDoc-ish I'm very near the idea that "LLM's are randomized compilers" and the human prompts should be 1000% more treated with care. Don't (necessarily) git commit the whole megabytes of token-blathering from the LLM, but keeping the human prompts: "Hey, we're going to work on Feature X... now some test cases... I've done more testing and Z is not covered... ok, now we'll extend to cover Case Y..." Let me hover over the 50-100 character commit message and then see the raw discussion (source) that led to the AI-generated (compiled) code. Allow AI.next to review the discussion/response/diff/tests and see if it can expose any flaws with the benefit of hindsight!
AdieuToLogic 8mo ago
> If good code was enough on its own we would read the source instead of documentation. An axiom I have long held regarding documenting code is: Code answers what it does, how it does it, when it is used, and who uses it. What it cannot answer is why it exists. Comments accomplish this.

awesome_dude 8mo ago

> Natural languages are ambiguous. That's the reason why we created programming languages. So the documentation around the code is generally ambiguous as well. Worse: it's not being executed, so it can get out of date (sometimes in subtle ways). I loathe this take. I have rocked up to codebases where there were specific rules banning comments because of this attitude. Yes comments can lie, yes there are no guards ensuring they stay in lock step with the code they document, but not having them is a thousand times worse - I can always see WHAT code is doing, that's never the problem, the problems is WHY it was done in this manner. I put comments like "This code runs in O(n) because there are only a handful of items ever going to be searched - update it when there are enough items to justify an O(log2 n) search" That tells future developers that the author (me) KNOWS it's not the most efficient code possible, but it IS when you take into account things unknown by the person reading it Edit: Tribal knowledge is the worst type of knowledge, it's assumed that everyone knows it, and pass it along when new people onboard, but the reality (for me) has always been that the people doing the onboarding have had fragments, or incorrect assumptions on what was being conveyed to them, and just like the childrens game of "telephone" the passing of the knowledge always ends in a disaster

AdieuToLogic 8mo ago
> Yes comments can lie ... Comments only lie if they are allowed to become one. Just like a method name can lie. Or a class name. Or ...
- bonesss 8mo ago
  Right. The compiler ensures that the code is valid, and what ensures that ‘// used a suboptimal sort because reasons’ is updated during a global refactor that changes the method? … some dude living in that module all day every day exercising monk-like discipline? That is unwanted for a few reasons, notably the routine failures of such efforts over time. Module names and namespaces and function names can lie. But they are also corrected wholesale and en-masse when first fixed, those lies are made apparent when using them. If right_pad() is updated so it’s actually left_pad() it gets caught as an error source during implementation or as an independent naming issue in working code. If that misrepresentation is the source of an emergent error it will be visible and unavoidable in debugging if it’s in code, and the subsequent correction will be validated by the compiler (and therefore amenable to automated testing). Lies in comments don’t reduce the potential for lies in code, but keeping inline comments minimal and focused on exceptional circumstances can meaningfully reduce the number of aggregate lies in a codebase.

k32k 8mo ago

"But translating my prompts to code is not working as well, because my prompts are in natural languages, and hence ambiguous." Not only that, but there's something very annoying and deeply dissatisfying about typing a bunch of text into a thing for which you have no control over how its producing an output, nor can an output be reproduced even if the input is identical. Agreed natural language is very ambiguous and becoming more ambiguous by the day "what exactly does 'vibe' mean?". People spoke in a particular way, say 60 years ago, that left very little room for interpretation of what they meant. The same cannot be said today.

caseyohara 8mo ago
> People spoke in a particular way, say 60 years ago, that left very little room for interpretation of what they meant. The same cannot be said today. Surely you don’t mean everyone in the 1960s spoke directly, free of metaphor or euphemism or nuance or doublespeak or dog whistle or any other kind or ambiguity? Then why are there people who dedicate their entire life to interpreting religious texts and the Constitution?
- k32k 8mo ago
  Compared with today, on average, they did. There's a generation of people that 'typ lyk dis'. So yes.
  - jyounker 8mo ago
    Your point is less persuasive than you intended. You complain about linguistic ambiguity, but then you show an example of sensible spelling reform.
  - ChrisGreenHeur 8mo ago
    that example is regarding syntax, and is actually no worse than any other

deleted 8mo ago

[deleted]

casey2 8mo ago

Programming languages are natural and ambiguous too, what does READ mean? you have to look it up to see the types. The power comes from the fact that it's audit-able, but that you don't need to audit it every time you want to write some code. You think you write good code? try to prove it after the compiler gets through with it. Natural languages are richer in ideas, it may be harder to get working code going from a purely natural description to code, than code to code, but you don't gain much from just translating code. One is only limited by your imagination the other already exists, you could just call it as a routine. You only have a SENSE for good code because it's a natural language with conventions and shared meaning. If the goal of programming is to learn to communicate better as humans then we should be fighting ambiguity not running from it. 100 years from now nobody is going to understand that your conventions were actually "good code".

musicale 8mo ago
> Programming languages are natural and ambiguous too Programming languages work because they are artificial (small, constrained, often based on algebraic and arithmetic expressions, boolean logic, etc.) and have generally well-defined semantics. This is what enables reliable compilers and interpreters to be constructed.
- mexicocitinluez 8mo ago
  Exactly. Programming is the art of removing ambiguity and making it formal. And it's why the timelines between getting an EXACT plan of what I need to implement vs hazy requirements are so out of whack.
mexicocitinluez 8mo ago
> Programming languages are natural and ambiguous too, what does READ mean? Not nearly in the same sense actual language is ambiguous. And ambiguity in programming is usually a bad thing, whereas in language it can usually be intended. Good code, whatever that means, can read like a book. Event-driven architectures is a good example because the context of how something came to be is right in the event name itself.
8mo ago

pdntspa 8mo ago

> because my prompts are in natural languages, and hence ambiguous. Legalese developed specifically because natural language was too ambiguous. A similar level of specificity for prompting works wonders One of the issues with specifying directions to the computer with code is that you are very narrowly describing how something can be done. But sometimes I don't always know the best 'how', I just know what I know. With natural language prompting the AI can tap into its training knowledge and come up with better ways of doing things. It still needs lots of steering (usually) but a lot of times you can end up with a superior result.

vnorilo 8mo ago
Yes. LLMs are search engines into the (latent) space or source code. Stuff you put into the context window is the "query". I've had some good results by minimizing the conversational aspect, and thinking in terms of shaping the context: asking the LLM to analyze relevant files, nor because I want the analysis, but because I want a good reading in the context. LLMs will work hard to stay in that "landscape", even with vague prompts. Often better than with weirdly specific or conflicting instructions.
- ptx 8mo ago
  But search engines are not a good interface when you already know what you want and need to specify it exactly. See for example the new Windows start menu compared to the old-school run dialog – if I directly run "notepad", then I get always Notepad; but if I search for "notepad" then, after quite a bit of chugging and loading and layout shifting, I might get Notepad or I might get something from Bing or something entirely different at different times.
  - vnorilo 8mo ago
    Indeed, which is not all that different from LLM code generation, to be honest.
Copyrightest 8mo ago
[dead]

baq 8mo ago

Docs and code work together as mutually error correcting codes. You can’t have the benefits of error detection and correction without redundant information.

ghywertelling 8mo ago
> With agents, does it become practical to have large codebases that can be read like a narrative, whose prose is kept in sync with changes to the code by tireless machines? I think this is true. Your point supports it. If either the explanation / intention or the code changes, the other can be brought into sync. Beautiful post. I always hated the fact that research papers don't read like novels, eg "ohk, we tried this which was unsuccessful but then we found another adjacent approach and it helped." Computer Scientist Explains One Concept in 5 Levels of Difficulty | WIRED https://www.youtube.com/watch?v=fOGdb1CTu5c https://www.youtube.com/watch?v=fOGdb1CTu5c Computer scientist Amit Sahai, PhD, is asked to explain the concept of zero-knowledge proofs to 5 different people; a child, a teen, a college student, a grad student, and an expert. Using a variety of techniques, Amit breaks down what zero-knowledge proofs are and why it's so exciting in the world of cryptography.

alkonaut 8mo ago

Maybe if we had a really terse and unambiguous form of English? Whenever there is ambiguity we insert parentheses and operators to really make it clear what we mean. We can enclose different sentences in brackets to make sure that the scope of a logical condition and so on. Oh wait

gwbas1c 8mo ago

> That's the reason why we created programming languages. No, we created programming languages because when computers were invented: 1: They (computers) were incapable of understanding natural language. 2: Programming languages are easier to use than assembly or writing out machine code by hand. LLMs are a quite recent invention, and require significantly more computing power than early computers had.

psychoslave 8mo ago

>Natural languages are ambiguous. That's the reason why we created programming languages. Programming languages can be ambiguous too. The thing with formal languages is more that they put a stricter and narrower interpretation freedom as a convention where it's used. If anything there are a subset of human expression space. Sometime they are the best tool for the job. Sometime a metaphor is more apt. Sometime you need some humour. Sometime you better stay in ambiguity to play the game at its finest.

palata 8mo ago
Programming languages are non-ambiguous, in the sense that there is no doubt what will be executed. It's deterministic. If the program crashes, you can't say "no but this line was a joke, you should have ignored it". Your code was wrong, period.
- cindyllm 8mo ago
  [dead]