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