Re: GR: Ban LLM contributions from Debian

--0000000000001b62940657beddc0
Content-Type: text/plain; charset="UTF-8"

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.

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.

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.

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.
-- 
Best regards,
    Aigars Mahinovs

--0000000000001b62940657beddc0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Wed, 29 Jul 2026 at 13:33, Gard Spreem=
ann &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; wrot=
e:</div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Aigars Mahinovs &lt;<a href=3D"mailto:aiga=
[email protected]" target=3D"_blank">[email protected]</a>&gt; writes:<br>
<br>
&gt; On Tue, 28 Jul 2026 at 15:42, Gard Spreemann &lt;<a href=3D"mailto:gsp=
[email protected]" target=3D"_blank">[email protected]</a>&gt; wrote:<br>
&gt;<br>
&gt;=C2=A0 But now you&#39;re comparing LLMs to junior programmers! My issu=
e is with<br>
&gt;=C2=A0 comparing the role of LLMs to that of compilers or calculators. =
We<br>
&gt;=C2=A0 definitely interact with junior programmers through natural lang=
uage<br>
&gt;=C2=A0 already, so nothing changes there. My point is that we interact =
with<br>
&gt;=C2=A0 compilers and calculators through *formal languages*, and that t=
herefore<br>
&gt;=C2=A0 it&#39;s not helpful to compare LLMs to those.<br>
&gt;<br>
&gt; But we only do that (interact with compilers with formal language)<br>
&gt; because that was historically the only option that worked. If we could=
<br>
&gt; describe the program in natural language to the compiler and get a<br>
&gt; good result .... we would.<br>
<br>
I very much doubt that. To many of us, the best attribute of a computer<br>
is the fact that it will do precisely as told. Natural language is<br>
notoriously imprecise, and is thus a poor match for instructing<br>
computers.<br></blockquote><div><br></div><div></div></div><div>High level =
programming languages are (conditionally) deterministic. As in - from the s=
ame 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 di=
fferent version of the compiler, the output may change radically. This alon=
e actually contradicts your point - *high level* programming languages do n=
ot *precisely* describe exactly what and how is going to be done. They are =
not precise on the action, they only describe the intent.</div><div><br></d=
iv><div>You can have the same kind of determinism from an LLM as well - sam=
e prompt to the same version of the same LLM (with randomness surpressed) s=
hould generate the same output code.</div><div><br></div><div>And then (sup=
posedly) small change in the input (like setting the debug flag, just two b=
yte change!) can cause massive changes in the final output. That is true fo=
r both LLMs and compiler outputs. Your loops may grow too large and cause a=
 different optimisation method to be used, for example.</div><div><br></div=
><div>It is not easy to predict what real effect (on code execution, resour=
ce 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 instructio=
n set.</div><div><br></div><div>And yet such imprecise languages like Pytho=
n and JavaScript dominate the coding landscape.</div><span class=3D"gmail_s=
ignature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><=
div dir=3D"ltr">Best regards,<br>=C2=A0 =C2=A0 Aigars Mahinovs</div></div><=
/div>

--0000000000001b62940657beddc0--