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
signature.asc
Description: PGP signature
