Re: GR: Ban LLM contributions from Debian

Gard Spreemann <[email protected]> Wed, 29 Jul 2026 13:32:54 +0200
Newsgroups gmane.linux.debian.devel.vote
Message-ID <[email protected]>
--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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.

> In fact the whole history of programming language developemnt shows us
> that this is *exactly* what people have always tried to achieve. COBOL
> was sold as English-like data processing language that would require
> no programmers. BASIC was created to be as close to simple English as
> possible. The whole object oriented programming thing was (in part)
> created to make code more alligned with language sentence
> structures. Python values highly the the approach of nouns and verbs
> and code that is readable as natural language would be. And those are
> only the most widely succesfull examples.

Those languages are not natural languages. They are well-defined
constructed languages, constructed with precise meaning in mind. Sure,
they may have characteristics that may make them easier to learn for
some people, but that doesn't mean they're prose. There is far less
fundamental difference between coding x86 assembly and Python or COBOL,
than there is between coding Python or COBOL and writing a prosaic
description of a program to be consumed by an LLM.

> The way LLMs are developing, I would not be too surprised to see a
> more formal intermediate representation being developed that is valid
> natural language, but at the same time is also a very high level
> programming language that has a deterministic output. For the cases
> where that is important.

I don't think we should put too much weight on speculations about the
future when discussing GRs.

> Also, you *can* use a junior programmer like a calculator, with some
> effort - just give them a strict style guide (with autoformatter), a
> library of coding patterns that they are expected to always reuse and
> so on :D

My point is simply that that's fundamentally different from a classical
calculator. And substantially *more* so than the difference between
mental arithmetic and a classical calculator.

> Also many contractors have been indistinguishable in their output from
> worst LLMs, decades before LLMs existed. ;)

This is entirely besides the point I'm trying to make.



 Best,
 Gard
=20

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

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

iQJGBAEBCgAwFiEEz8XvhRCFHnNVtV6AnRFYKv1UjPoFAmpp5OYSHGdzcHJAbm9u
ZW1wdHkub3JnAAoJEJ0RWCr9VIz6roIP/Ag1BHeIb7wP04yYPmkJfBWM/l26upT4
DXPwirmKAWpPnI5BEbEv764u6bcCfslw/CX6hLDyF71VdlzrTyx+5tpKms+n2lBx
eWWj/Z1cEaV9xzZXeliUWcUafCfNu0+kAUd8eOjE8dxnfXNYMbAp+O2WmHt87Ycl
WIVXvaRJGYyB4PvZg332KDG4CaSIj/Exj8gYHzUJsQupN2AjykMpHR6BOPubls/Z
KmSHf587auu7hhsLgUiI6TKSnYEhOc0VStjYoZ1+PGaUN/BICp0nKW+1SrSZqGrP
x0agI6vVb5j7zeXkwVrZwrfKOhEUh43PB2436jE2F0MvwNbu4W9XyP3lDGIDJBf9
TYy1JGXPQQzdzrDe+vtDeuqnCcA3o/hSjC38h55A7njI12CNJA6CPGUMtlm1dq03
3nJT8XE1ZZGuJs0gVSCCbGY+4u+RsFAF4JG1YKYV75dPpqZ7xvO3oPmM3GbamcI9
+gb7HVNTPJweoSl8uod7QHSJBvLF18O1Uo40E5JGgmuYwm04GX3Pmr6DWMWNaA0N
J9cJ4pI/7b0g0yfl6U//KVNRpU+IxcdeAo9i1UxV47scWoXH3VQ0vWW1g7ShwKr2
Uo1C54J7mm9iIr8SrePYImh7BbbV2nvX0RQqkv4YBpNAIr65Bs8/7Kj3Hmu/7u5P
mXNhNMTJ91y6
=q6Zi
-----END PGP SIGNATURE-----
--=-=-=--