It Bears Repeating

I know I've addressed this topic in the past, but it bears repeating, because there's either overly fervent tech-optimism or a fundamental lack of understanding of LLMs (or both, I guess).

I recently encountered this article about the approach of the death of the programming language.  It starts off with the usual straw man argument that compilers obviated the need to understand machine language, that VMs increased the level of abstraction even further, and that LLMs now (or soon will) preclude us from needing to understand high-level languages.

Except this isn't true.

The first evolutions dealt with deterministic tools.  If you're writing in C and compile the code to something machine-readable, you can be reasonably certain that the same input will produce the same output.  The universe (and the 2nd Law of Thermodynamics) being what it is, this isn't entirely correct.  Bugs exist in compilers, and things like cosmic radiation can actually affect behavior.  But compilers go through rigorous QA due to their critical and broad-reaching nature.  Any bugs that continue to exist are also deterministic.  And cosmic radiation (or other random effluvia) causing variations in output is so statistically improbable that it can essentially be written off as an impossibility from a planning standpoint.

Not so with LLMs.  LLMs are, by definition, predictive text generators.  Under bounded conditions, they're immensely helpful.  And under those conditions, it's true that it's quicker to read the output and make corrections than to write the same code from scratch.  However, left to its own devices, even over a couple of hundred lines, the code becomes inscrutable.  Reading code isn't like reading this blog.  It's part mathematical puzzle and part deciphering the stream of consciousness from a very disturbed individual (and that's even before AI was able to write code).

Again, something so indecipherable is fine with a compiler, because the output is deterministic.  But LLM paths aren't guaranteed, and execution order (or number of times code is executed) matters in high-level programming languages.  

What's more, much of what makes programming languages tricky and powerful is the manner in which they're used to solve scalability and reliability problems.  An LLM 99 times out of 100 (or greater, though still less accurate than any garden-variety compiler) will output simple code that's referenced 1000s of times in literature (like 'implement bubble sort'), but that doesn't really accomplish anything new (also, don't write your own sort).

Code is written for functionality, which, to some extent, is the easy part, but it also needs to be consistent and, in most cases, secure and scalable.  No instruction in Markdown is going to allow an LLM to write performant code without an engineer looking over its virtual shoulder.

It's reasonable to assume that we may not physically write code anymore.  I typically ask an LLM to generate the code and then point out revisions, even if they're 1 line long (though I've written code for 25+ years, so, presumably, I can read code better than someone who doesn't have that skill at their fingertips).  

It's also reasonable to assume that another abstraction will unlock another level of programming language.

But to assume we're close to skipping the middle step of needing to read or understand some version of an intermediary programming language and let the LLM handle it?  That's a bridge too far, me thinks.

Until next time, my human and robot friends.