Re: GR: Ban LLM contributions from Debian
Aigars Mahinovs <[email protected]> Wed, 29 Jul 2026 15:28:28 +0200
| Newsgroups | gmane.linux.debian.devel.vote |
|---|---|
| Message-ID | <CABpYwDU5NC+vEFM7i19CMX5LjOqtSwBg6HzDjOe_um5ySefOKg@mail.gmail.com> |
--0000000000000e12170657bfef85 Content-Type: text/plain; charset="UTF-8" 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 --0000000000000e12170657bfef85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><div dir= =3D"ltr" class=3D"gmail_attr">On Wed, 29 Jul 2026 at 15:01, Gard Spreemann = <<a href=3D"mailto:[email protected]">[email protected]</a>> wrote:<b= r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex= ;border-left:1px solid rgb(204,204,204);padding-left:1ex">Aigars Mahinovs &= lt;<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= om</a>> writes:<br> <br> > On Wed, 29 Jul 2026 at 13:33, Gard Spreemann <<a href=3D"mailto:gsp= [email protected]" target=3D"_blank">[email protected]</a>> wrote:<br> ><br> >=C2=A0 Aigars Mahinovs <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>> writes:<br> ><br> >=C2=A0 > On Tue, 28 Jul 2026 at 15:42, Gard Spreemann <<a href=3D= "mailto:[email protected]" target=3D"_blank">[email protected]</a>> wrot= e:<br> >=C2=A0 ><br> >=C2=A0 >=C2=A0 But now you're comparing LLMs to junior programme= rs! My issue is with<br> >=C2=A0 >=C2=A0 comparing the role of LLMs to that of compilers or ca= lculators. We<br> >=C2=A0 >=C2=A0 definitely interact with junior programmers through n= atural language<br> >=C2=A0 >=C2=A0 already, so nothing changes there. My point is that w= e interact with<br> >=C2=A0 >=C2=A0 compilers and calculators through *formal languages*,= and that therefore<br> >=C2=A0 >=C2=A0 it's not helpful to compare LLMs to those.<br> >=C2=A0 ><br> >=C2=A0 > But we only do that (interact with compilers with formal la= nguage)<br> >=C2=A0 > because that was historically the only option that worked. = If we could<br> >=C2=A0 > describe the program in natural language to the compiler an= d get a<br> >=C2=A0 > good result .... we would.<br> ><br> >=C2=A0 I very much doubt that. To many of us, the best attribute of a c= omputer<br> >=C2=A0 is the fact that it will do precisely as told. Natural language = is<br> >=C2=A0 notoriously imprecise, and is thus a poor match for instructing<= br> >=C2=A0 computers.<br> ><br> > High level programming languages are (conditionally) deterministic. As= <br> > in - from the same input you will reproducibly get the same<br> > output. Assuming you have the *exact* same version of the compiler and= <br> > all dependencies. If you have a different version of the compiler, the= <br> > output may change radically. This alone actually contradicts your<br> > point - *high level* programming languages do not *precisely* describe= <br> > exactly what and how is going to be done. They are not precise on the<= br> > action, they only describe the intent.<br> <br> This is patently false. High-level languages have precisely defined<br> semantics. Within those semantics, the languages are precise (barring<br> bugs). Determinism has nothing to do with this (except for some esoteric<br= > languages where nondeterminism is the point).<br> <br> Yes, two different (correct) C compilers may compile the same C program<br> to two different lists of machine instructions. However, as long as the<br> C program is sound, those instructions will produce exactly the same<br> observable side-effects when run (barring bugs in the compiler, the<br> supporting software, or the underlying hardware).</blockquote><div><br></di= v><div>Except that is false. *Because* the underlying instructions are diff= eremt the results *will be* different. There will be different resource usa= ge, 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 bet= ween evens in a multi-threaded environment and this caused memory to be use= d 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 b= e done across all contexts. The compiler has to try to guess what branch pr= ediction *might* do, for example. Higher level languages are further and fu= rther away from that.</div><div><br></div><div>And if you "exclude bug= s" well, then that is a spherical cow in a vaccum. There are always bu= gs. In all layers. And slightly differing implementations that produce same= results in most cases, but differ in special cases, which are not really b= ugs, but cause different side-effects none the less. Even two equal process= ors with identical model numbers from a single wafer can have slightly diff= erent 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.</div><div><br><= /div><div>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 horro= r stories. Telling an LLM to add a quicksort in-line implementation into yo= ur code to sort *that* list is in the end no different than importing it fr= om a library. From implementation precision perspective.</div></div><span c= lass=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gma= il_signature"><div dir=3D"ltr">Best regards,<br>=C2=A0 =C2=A0 Aigars Mahino= vs</div></div></div> --0000000000000e12170657bfef85--