Hi! I'm Eduardo Lávaque, and this is my blog.
Writing software for 11+ years. Eschew hype; focus on performance.
Living in Switzerland since 2017.
Hi! I'm Eduardo Lávaque, and this is my blog.
Writing software for 11+ years. Eschew hype; focus on performance.
Living in Switzerland since 2017.
Online one keeps reading post after post after post about how what's happening with LLMs now is the same as what happened in the 20th century with programming languages.
First there was Assembly, then there were programming languages which were compiled into Assembly. And people didn't trust these sneaky compilers, so they always went down to read the Assembly to make sure it was right.
And that's what's happening now, people don't trust an LLM's code output, so they go down to read the code before shipping.
It's the same thing happening now, that happened back then! Therefore, in due time, we probably won't need to read the code anymore once LLMs get good enough!
Except, I don't mean to insult anyone, but this train of thought demonstrates such a poor understanding of human language, of human conscience, of machine code and of machines, of LLMs, and of compilers.
It just demonstrates no particular deeper thought. It's the r/im14andthisisdeep meme.
Let's break this down one by one, going from bottom to top.
The computer, in this case we'll primarily address the CPU core, is a highly complex electronic circuit, which has been manufactured with amazing nano-scopic tech, allowing us to pack what once used to take entire rooms, into a couple centimeters. It is a marvellous technology and honestly a miracle of human creativity.
At its most basic level, it is just logic gates. Little things keeping track of when they've been told to stay on, and hold that charge or when they've been told to stay off, and not hold a charge. Computers run on electricity, and while electricity has an infinite number of values, depending on how much you put through the cable, it does not stay the same from one nanosecond to the next, it is an extremely noisy medium, so you need to decide on some cutoff point where you say "this is on" and "this is off".
That's why we use binary numbers, a base 2 number, where things are either ON, or OFF. 1 or 0. With binary, luckily, if we're clever, we can represent any number. And with numbers we can represent any letter. And with both of those, we can represent anything we want for human use or for more scientific use.
Thus computers are extremely versatile and used everywhere in our modern world.
Very important: this machine is extremely dumb, and not anything close to what ANYONE would consider intelligent. Unless you think it requires intelligence to add 1+1. (Please note a mechanical calculator was already invented for this.)
Also very important: it is however extremely, extremely, fast. It can figure out basic number additions trillions of times per second without sweating.
Machine code is how we tell the machine, what to do.
Normally this requires more than just a CPU to be useful. We also need memory locations and so on. But that's why we have not just a CPU, but also a motherboard, which connects all these pieces together.
But in short that's it. The instructions are on the level of "pick this up", "put it there", "pick this other thing up", "put it over there", "now take this thing, and that thing, and add them". And so on. The instructions are extremely simplistic, even adding numbers requires multiple instructions, we cannot just do 1+1.
Assembly is just the most direct, while still readable, way for a human to express machine code. It is basically machine code in human readable format.
Here's an example in x86 Assembly language.
mov eax, 10 ; Load 10 into the EAX register
add eax, 20 ; Add 20 to EAX (EAX now equals 30)
add eax, 30 ; Add 30 to EAX (EAX now equals 60)
I hope we agree, that this still doesn't sound anything close to "fetch data and handle errors" that some people suggest one can do with LLMs effectively.
Now it's good to note, that the Assembly will change depending on what kind of CPU you're running. The "syntax" won't look the same for an x86 CPU core, vs an ARM core.
Even if many people consider C to be a low level programming language, that's only relatively. It is in fact considered a high level programming language, compared to what it's abstracting over, the Assembly.
We'll take C because it is generally considered to be the closest thing to Assembly while still being high level. Which is funny as we'll see in a moment.
I'll be using godbolt.org for all of the following examples, as it is a magnificent product. It allows us to take some C, or a variety of other languages, and find out what kind of machine code (Assembly) will be outputted by the compiler.
Let's talk quickly about the compiler.
The compiler takes any language it supports, and transforms it into Assembly.
For example the following C code, which just sums:
int testFunction(int* input, int length) {
int i, sum = 0;
for (i = 0; i < length; ++i) {
sum += input[i];
}
return sum;
}
Can be translated into the following x86 Assembly code by the compiler:
"testFunction":
push rbp
mov rbp, rsp
mov QWORD PTR [rbp-24], rdi
mov DWORD PTR [rbp-28], esi
mov DWORD PTR [rbp-8], 0
mov DWORD PTR [rbp-4], 0
jmp .L2
.L3:
mov eax, DWORD PTR [rbp-4]
cdqe
lea rdx, [0+rax*4]
mov rax, QWORD PTR [rbp-24]
add rax, rdx
mov eax, DWORD PTR [rax]
add DWORD PTR [rbp-8], eax
add DWORD PTR [rbp-4], 1
.L2:
mov eax, DWORD PTR [rbp-4]
cmp eax, DWORD PTR [rbp-28]
jl .L3
mov eax, DWORD PTR [rbp-8]
pop rbp
ret
So we see that even the most simple C code, quickly explodes in lines of code, when translated to machine code.
The very important point here is, given the same inputs, the output is, for most intents and purposes, the same. If you use the same compiler version, with the same compilation flags, with the same code input, you will get the same output. It's reliable and consistent.
If you got this far, you might already know where I'm going with this.
A wonder of modern technology and the developments of the Machine Learning field.
I truly respect what they developed here. Because what they found is not easy to find.
For the longest time the Turing Test, whether a machine has intelligence comparable to that of a human, was done via interactive dialogue. Between the machine and the subject trying to detect whether it's a machine or not, there is a human delivering the messages to each other, so that the human subject doesn't know whether it's the human or the machine speaking.
Two important things here, one it's a test of intelligence, and back then it was considered that if it exhibits human speech, it is therefore intelligent. The problem of human speech is that hard, and that's why I respect the field that developed LLMs.
We can definitely say that LLMs, at least frontier models, have passed the turing test. They exhibit human-like conversational skills. If your standards are high, you can easily detect it's an LLM, but if you're untrained or confused (as a famous intellectual seems to be), it might seem to you that it is a human.
Does being good at seeming human mean it has intelligence though? Here I'd like to challenge the original Turing Test.
We finally get to the point which all of us experience daily, but few of us study.
We experience it daily. Human conscience.
Introspection, looking inwards at one's own mental processes, reveals for most people a simple fact: they do not think in language.
Language is in fact a process that takes place in their mind, as perhaps a representation of thought, but not as thought itself.
Most people can easily do the following exercise, I encourage you to try to guide somebody through it:
And immediately we realize, there is an "I" involved in this whole process.
If you think LLMs have an "I", try this exercise with them, they'll admit they can't do it, or divert into feigning interest into the whole practice. Totally un-human-like behavior, in case you were wondering. Anyway.
Human conscience is something we haven’t been able to measure thus far. I'm inclined to believe we won't be able to measure it any time soon, as it seems meta-physical. If we could, we'd definitively be able to say there isn't a soul, or there is, but it's not something we can measure so it's outside of the field of most science, but it's something everybody experiences, therefore it cannot be ignored or handwaved away.
Personally I'm on the side of that there is a soul or an "I" which is experiencing.
LLMs (Large Language Models) cannot begin to model human conscience, because human conscience is more than just language.
Like when a compiler translates your code into Assembly out of a higher programming language, an LLM can generate code out of human language.
Like when a compiler translates your code into Assembly, you noticed the lines of code exploded. Well the same thing happens with an LLM.
The following prompt to ChatGPT:
a function that passes the turing test
Results in the following:
A “function that passes the Turing test” is not really well-defined: the Turing test evaluates a system’s conversational behavior over time, not a single function.
For a toy version, here is a Python function that tries to sound human by reflecting, hedging, asking follow-ups, and avoiding overly precise answers:
import random import re def turingish_reply(user_input: str) -> str: text = user_input.strip() lower = text.lower() if not text: return random.choice([ "I was about to ask the same thing.", "Say more.", "I’m not sure what to do with a blank message." ]) # Basic conversational memory illusion if re.search(r"\b(you|yourself|chatgpt|bot|ai)\b", lower): return random.choice([ "I’m not great at describing myself. What made you ask?", "Depends what you mean by that. I can answer, but context matters.", "I try not to overclaim. What are you actually testing?" ]) if "?" in text: return random.choice([ "My first instinct is yes, but I’d want one more detail before committing.", "Probably, though there’s a catch.", "That depends on the assumptions. What are you optimizing for?", "I don’t know for sure. I can reason it through, though." ]) if any(w in lower for w in ["sad", "angry", "tired", "stressed", "worried"]): return random.choice([ "That sounds unpleasant. What happened?", "Reasonable reaction. Is this a one-off thing or ongoing?", "I’d probably want to separate the facts from the interpretation first." ]) if any(w in lower for w in ["hello", "hi", "hey"]): return random.choice([ "Hey. What are you working on?", "Hi. What do you need?", "Hey — what’s the task?" ]) return random.choice([ "That’s interesting. What makes you frame it that way?", "I see the point, but I’m not fully convinced yet.", "Maybe. The details matter here.", "There’s a simple answer and a more accurate answer.", "I’d need to know what you’re comparing it against." ])Usage:
while True: msg = input("You: ") if msg.lower() in {"quit", "exit"}: break print("Bot:", turingish_reply(msg))This will not pass a serious Turing test. A more plausible approach is not a clever function, but a system with memory, long-context reasoning, natural timing, error correction, personality consistency, and the ability to admit uncertainty.
Please note that it answers with one of the previous solutions to the turing test, programming based. This normally doesn't pass the turing test. It isn't clever enough to tell me to use an LLM (which would pass the turing test), but it does tell me about a lot of the parts that comprise a chatbot.
Lines of code explode. Why?
The human language is an extremely dense format. And yet at the same time extremely redundant.
Here's a dense example:
古池や蛙飛び込む水の音, which when romanized looks like furu ike ya kawazu tobikomu mizu no oto, translated it's old pond, frog leaps in, water's sound. I will say the translation is not perfect, a better one I found is an ancient pond / a frog jumps in / the splash of water, but even that one is not quite right. Why? Because when translating a poem, the density is lost even in a human-language-to-human-language process.
It's a famous haiku. To a human reader of the era it brought endless pictures to mind, more than just those present in the words at face-value, and was apparently a hit.
The original's Japanese's semantics and all this other stuff, packed into a short haiku, cannot be packed into English succintly. An English poem would have the same problem when translated to Japanese.
Let's take another example of dense human language loop over the array and log each value.
Why is it dense? Because it contains a lot of implicit knowledge that the reader is supposed to fill in and make decisions about, when translating it into code.
Let's be less dense, and more explicit.
Loop over the values in the A array, for each one log with console.log the value, don't stringify it.
With the first one you had a lot of guesses about how it could be done, with the second one there's less.
Let's look at the same thing in a programming language, Python, which is rather high level language:
for a in A:
print(a)
Oops, the programming language was more precise, AND shorter than the English language.
OK I cheated, I spoke in JavaScript but wrote the code in Python, let's write it in JavaScript:
for (const a of A) {
console.log(a);
}
Ah damn it's still shorter, and yet more precise than the English.
You see with the English I didn't tell you whether it should be a for loop or a .forEach or a .map or what have you. You can probably assume it's not a .map, but actually you could do the following and still be following my instructions, technically:
A.map(console.log)
But with the code there is no doubt, what is there is what was meant, at least it has a 99% chance unless the writer was drunk or some what have you.
Here we have a problem with LLMs. It is not consistent. And it cannot be the way they’ve been made so far. Ask the LLM the same question twice and it'll give you two different answers, or perhaps the same answer with two different wordings, it isn’t consistent.
You need precision when programming.
Because the machine is precise, you need precision. The machine cannot guess your meaning not even one bit (the 0/1 bit).
Now, some people might prefer to deliver hyper specific instructions in human language, I prefer to deliver them in programming languages, because it is easier, and less prone to error and no room for interpretation.
With human language there is interpretation, and it cannot be avoided. It's just about who does it. Is it the human reading the ticket? Or the LLM ingesting the tokens and spitting them out?
This is the main problem with LLMs.
So, to the next guy that suggests programming languages will go away because LLMs are here, they're wrong. Maybe programming languages will go away, but only once computers go away. In the meanwhile, the next productive jump for programming languages might be some kind of visual form, but we'll have to wait and see.
By the way, it's worth noting, there is no incentive to make programming languages go away. LLMs are imprecise, they need to be able to represent in something more precise. But LLMs only work with text. Programming languages are in text.
Perhaps somebody will invent a language that is "token optimized" or what have you. But we're pretty close with the Lisp languages, apparently Clojure is the most token efficient language, and we have lots of examples of code for for it already.