Re: GR: Ban LLM contributions from Debian

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Aigars Mahinovs <[email protected]> writes:

> 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]> wr=
ote:
>  >  >
>  >  >  But now you're comparing LLMs to junior programmers! My issue is w=
ith
>  >  >  comparing the role of LLMs to that of compilers or calculators. We
>  >  >  definitely interact with junior programmers through natural langua=
ge
>  >  >  already, so nothing changes there. My point is that we interact wi=
th
>  >  >  compilers and calculators through *formal languages*, and that the=
refore
>  >  >  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 co=
uld
>  >  > 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 comput=
er
>  >  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.

That is not the case. As a trivial counterexample: a compiler is free to
add a bunch of no-ops to the code it produces for a C program without
changing the program's semantics. (As a less trivial example: different
compiler optimization levels produce different code, but with the same
semantics if the source code is sound.)

> There will be different resource usage, different timings.

Sure. These are typically not part of the high level language's
semantics. At least I don't know of any examples =E2=80=93 could you share =
some
if you do?

> 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.

Did the semantics change, or did you accidentally not adhere to them?
The latter is infamously hard for multithreaded programming in C (and
many other language), as I'm sure you know.

> 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.

I'm not an expert at C, but I don't believe that the C semantics say
anything about branch predictors. You are talking about observable
effects *outside* of the programming language. I'm saying that when the
programming language is human prose, *pretty much everything useful is
outside of the language's defined semantics!*

("But lots of formal stuff, like mathematics, is written in human
prose!", you might object. And that is true, but the *reader* of a
mathematical text is *not* a machine that does exactly what it's told. I
am not claiming that prose is inappropriate for everything, I'm
expressing doubt that it's appropriate for instructing a precise
machine.)

> And if you "exclude bugs" well, then that is a spherical cow in a
> vaccum. There are always bugs. In all layers.

This is non-sensical. Bugs can be found and fixed. LLMs playing the role
of compilers don't have "bugs" =E2=80=93 they're "not even wrong", if I may
borrow Pauli's words.

> And slightly differing implementations that produce same results in
> most cases, but differ in special cases,

If those special cases are distinguishable within the semantics of the
programming language, then something is broken somewhere, and can and
should be fixed.

> 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.

No. Conformant code can not work "fine" on one CPU and "fail" on another
of the same type. Then something somewhere is broken. It is not a state
of things that you accept.

> 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.

In that example, it's usually the case that the hardware is working
outside of its design envelope. Of course all bets are off then. It's
the hardware equivalent of writing code with undefined behavior. My
argument is again that with LLMs as "compilers" from natural prose to
machine code, there *isn't even a design envelope to begin with!*

> It is all fine and precise in *theory*. In practise we have been
> dealing with imprecise programming languages ever since leaving
> assembly.

We sure have. But that's from *mistakes* =E2=80=93 mistakes either in the d=
esign
of the programming language's semantics, or in the software author's
understanding of those semantics, or in the compiler, or in the OS, or
in the hardware. Mistakes happen. They are abnormalities outside of the
scope of how things are intended to be. That scope of how things are
ment to be does not even exist when using an LLM to "compile" natural
prose to code.

> 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.

It might be no different if you inspect the LLM's output code after it's
been formed, I agree. But remember that that's not what we're talking
about here. We're talking about the comparison of:

1: An implementation written correctly in a well-specified programming
language.

2: An "implementation" written "in" (as?) prose.

If we are to think of LLMs as compilers (I'm arguing that that's a bad
idea), we have to stop there. And at that point, 1 and 2 are entirely
different!


 Best,
 Gard

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAmpqCqkSHGdzcHJAbm9u
ZW1wdHkub3JnAAoJEJ0RWCr9VIz6LZ0P/20YG0M+0W9+enhEtNV4I3u7Q+5S8Y0/
4+xJSjPlTwmP5cYSrKfkdZUmSTGtCvm3sCGHlGMlhGtAua5y8DrJiyLN6uEdSWKR
MI8VX8Xa+ra0y0W+zymayZelT+bko0SrjsdhQxVSTaYtGfRDASI63O5qzHQ6MuY7
CsDIbFNVh3tVTV7ucSAJTj1BgJnuminvhfm/LbXPvDpCzUzHXYX7RzIax3rCGvWK
MToe4oJ+AU8/FBuTQL4m/UwcVNQWR1LPMHHa1ngmAWCZOMK3uEfADA7yrjPOMrjv
yWhY3/dcU9bNfmss4oKXlntMNxH0SMFRjAI86FPB/n+eSd+eHcKZvEhGFEAo2UVf
ZPMaxvFeg/2zL42L3vtZIQEJtY9kup6B/QjTUUv19f4zFVQebm6UmKGiTA3ROT17
qZyq9xHXrHuPeM4OXYslRV0BuqmYoFqx10fG1gqx0jeMzkVT81TV92dwzIW2J8u5
ogsr825pFd+71TpkzNVjowv3TtEgSQdCWht3grAbR38nIF2ovVJDG71PnvJhG8k6
YaSExEsfrwIKYcrpBEYaG88l3epAJk+UPrRCRou75lq0gih+ybLEA8j6pq3daDL+
oNW/UCcFke1svq2GFwMHcDhv9qUCbdRM07BK/WTzsvCGzsIrF2ltqbKuFndCxhdH
KpGFlEVPt1SJ
=Bse5
-----END PGP SIGNATURE-----
--=-=-=--