On Wed, 29 Jul 2026 at 15:01, Gard Spreemann <[email protected]> wrote:
> 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). Except that is false. *Because* the underlying instructions are differemt the results *will be* different. There will be different resource usage, different timings. This will cause different end results and different side-effects. This will only show up in corner cases, but they *will* show up. I have myself spent days debugging a crash that happened bacause a new compiler version introduced a new opmimization that changed the timings between evens in a multi-threaded environment and this caused memory to be used before it was allocated and filled with data. Even a relatively low level language as C is still not precise enough to describe exactly what is to be done across all contexts. The compiler has to try to guess what branch prediction *might* do, for example. Higher level languages are further and further away from that. And if you "exclude bugs" well, then that is a spherical cow in a vaccum. There are always bugs. In all layers. And slightly differing implementations that produce same results in most cases, but differ in special cases, which are not really bugs, but cause different side-effects none the less. Even two equal processors with identical model numbers from a single wafer can have slightly different actual hardware printed and enabled, you can then see same exact code working fine on one CPU and failing on another. This is everyday work for overclocking contests, for example. And slightly different machine code can easily influence crash or pass in such conditions as well. It is all fine and precise in *theory*. In practise we have been dealing with imprecise programming languages ever since leaving assembly. I am not a compiler developer, I am sure they can tell you much better horror stories. Telling an LLM to add a quicksort in-line implementation into your code to sort *that* list is in the end no different than importing it from a library. From implementation precision perspective. -- Best regards, Aigars Mahinovs
