Re: GR: Ban LLM contributions from Debian

--=-=-=
Content-Type: text/plain

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

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

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

iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAmpp+YYSHGdzcHJAbm9u
ZW1wdHkub3JnAAoJEJ0RWCr9VIz6SxEQAKNWTokxYWa1vTFHbLtdYEsWESKQw8JZ
+jQ1p+X1AXtQ+fMhdHJlwcwL+ZnWs/q1MHgRZgCSNmkP4Cc89eporYvTTGV142Fj
1DOVxaJpamO9BV+JAHhcrd+vCggkpTljXqMZ3KjALKhKg6t8WKKv6Z2Gd/TsLWPX
H/gPeCVZhRbASOm+dSg4gH62sV4wLPsyo46DMgIx3aYzuBcPtd7LpZ3FlVza3cpX
SBWO3+cyNXcFoCFzDc4+GGDSt2N7noCm/PvKxxliOO5GjWpQaGlzjNZNQ5EtI+jZ
BeYgk3FjLs3skGVnATc1JFV8euwzme4cIPxb7FHCibb5t+JvirBV8/lMAe8EAX5h
7eFg6K83BW+zchdzAhSARNFWDfd2PgqcGt1bbGQY5cGgVNOBJ59sncieE7wqvOyD
sgJjFRdys/25l0ST0tT7Bqqrq0kZdlHj5WEOM9Yl+k58owuluprsTTVkiq7ZjT8K
g/huAvguFY7G9aGZ77JRr9W6N19pFnOaPZxyVOXDnh9iKLtuCFdeFNZSiFF2j+wF
3Rh9wqDT95pHNczT3hAV3gZts4lEvf3ULxg03ac8GYbSYgKFNdClZdhoIM5/Gx/F
XLG0G5JfWd3D/Z5lXAEj3s2uwuVC7QHlfVROzedC+SCHnX/9tYRYTgCi1bj9dSwG
kyF0Npq7B5ga
=yXzu
-----END PGP SIGNATURE-----
--=-=-=--