“Since FORTRAN should virtually eliminate coding and debugging…” --- http://www.softwarepreservation.org/projects/FORTRAN/BackusE...

IMHO, the key here is "coding" and "the spec".

The coding we used to do and that LLMs now do so well has exactly the same status as the coding that was referenced in the 1958 FORTRAN report and that was eliminated by coding.

That sort of (assembly language) coding to the spec that "the programmers" delivered to "the coders" was replaced by the programmers writing the spec in FORTRAN and the compiler doing the coding.

Except that human language quickly morphed to follow the reality, and after that "coding" was writing programs in FORTRAN. And later C, PL/I, Algol(?), C++, Smalltalk, BASIC, etc.

And people only very rarely look at the output of their compiler.

So in some case, the shift to LLMs and "no-look" coding is just the same old same-old, shifted one level higher.

Except we don't actually have a new FORTRAN for this era. The new FORTRAN is natural language, in most cases English. And that's both convenient and also troubling. Because the translation from English to code, wether it is high-level code or low-level code is far less deterministic than the translation from C or FORTRAN to machine code.

And that leaves us in a bit of a pickle, not least of which is what to check into source control: the prompt that we can't be sure will ever yield the same program again, or the "source" code that we never looked at (and isn't really "source" code at all).

"far less deterministic" does not make sense. it's either deterministic, or it isn't. llms aren't. And to anyone who starts spouting the mantra that you can just set the temperature to zero and i just don't know what "deterministic means", I invite you to predict an llms output before you submit the prompt. I know the compiler will respect my code's semantics. You can't do that with any model.