Aigars Mahinovs <[email protected]> writes: > On Wed, 29 Jul 2026 at 13:33, Gard Spreemann <[email protected]> wrote: > > Aigars Mahinovs <[email protected]> writes: > > > On Tue, 28 Jul 2026 at 15:42, Gard Spreemann <[email protected]> wrote: > > > > But now you're comparing LLMs to junior programmers! My issue is with > > comparing the role of LLMs to that of compilers or calculators. We > > definitely interact with junior programmers through natural language > > already, so nothing changes there. My point is that we interact with > > compilers and calculators through *formal languages*, and that therefore > > it's not helpful to compare LLMs to those. > > > > But we only do that (interact with compilers with formal language) > > because that was historically the only option that worked. If we could > > describe the program in natural language to the compiler and get a > > good result .... we would. > > I very much doubt that. To many of us, the best attribute of a computer > is the fact that it will do precisely as told. Natural language is > notoriously imprecise, and is thus a poor match for instructing > computers. > > High level programming languages are (conditionally) deterministic. As > in - from the same input you will reproducibly get the same > output. Assuming you have the *exact* same version of the compiler and > all dependencies. If you have a different version of the compiler, the > output may change radically. This alone actually contradicts your > point - *high level* programming languages do not *precisely* describe > exactly what and how is going to be done. They are not precise on the > action, they only describe the intent.
This is patently false. High-level languages have precisely defined semantics. Within those semantics, the languages are precise (barring bugs). Determinism has nothing to do with this (except for some esoteric languages where nondeterminism is the point). Yes, two different (correct) C compilers may compile the same C program to two different lists of machine instructions. However, as long as the C program is sound, those instructions will produce exactly the same observable side-effects when run (barring bugs in the compiler, the supporting software, or the underlying hardware). This is of course what people mean when they talk about a language being precise; no mainstream language that I'm aware of has the exact assembly instructions a compiler should output as part of their specified semantics. In other words: there are many assembly programs that are equivalent as far as the semantics of higher level languages are concerned. That's not a problem. > You can have the same kind of determinism from an LLM as well - same > prompt to the same version of the same LLM (with randomness > surpressed) should generate the same output code. I am not talking about determinism. > And then (supposedly) small change in the input (like setting the > debug flag, just two byte change!) can cause massive changes in the > final output. That is true for both LLMs and compiler outputs. Your > loops may grow too large and cause a different optimisation method to > be used, for example. This is not what I'm talking about. > It is not easy to predict what real effect (on code execution, > resource consumption or other performance factors) will a small change > in a high level language have on the end product. In assembly or > machine code that is very straightforward. That is what characterises > a very precise instruction set. > > And yet such imprecise languages like Python and JavaScript dominate > the coding landscape. The things you mention indeed make higher-level languages imprecise *as tools for producing machine instructions*. They are, however, precise as tools for producing behavior within their specified semantics. This is lacking when the source language is natural prose. Best, Gard
signature.asc
Description: PGP signature
