Conversation with a Machine. Part 2
In the previous post I wrote about programming languages in the context of their relationship with natural languages.
The goal was to arrive at a somewhat uncomfortable conclusion: programming languages are not really languages in the everyday sense of the word.
They are closer to a system of formal rules that determine whether a piece of code can be successfully translated by a compiler or interpreter into instructions the CPU can execute.
TL;DR: they have more in common with road signs than with human conversation.
Serious business
That said, the matter isn’t nearly as simple as it sounds. Programming languages share quite a few traits with natural languages.
For one thing, they are created and evolved by humans. Their vocabulary is largely derived from natural language expressions. Most often English, since it functions as the lingua franca of the IT industry. But there is also a surprisingly large group of programming languages based on other languages — including some that aren’t even written using the Latin alphabet.
Natural languages evolve over time. They change, sometimes to the point where different generations struggle to understand each other. Something similar happens in programming languages. Different versions may break compatibility with older ones — Python 2 vs. Python 3 being the obvious example.
The same phenomenon exists in natural language. The Polish used by Mikołaj Rej or the English of “The Canterbury Tales” is nearly incomprehensible to modern speakers. You could say the language is no longer backward-compatible with its ancient version.
Where programming languages differ from natural ones is their extremely strict attitude toward meaning and syntax. They are brutally literal and almost completely intolerant of ambiguity. In that sense they resemble legal language — highly formalized and ideally stripped of multiple interpretations.
Programming languages operate with a very straightforward, almost biblical understanding of truth and falsehood.
Let your word be ‘Yes, yes’ or ‘No, no’; anything more comes from evil (Matthew 5:36–37)
This slightly ominous biblical line actually captures quite well the kind of information machines expect from high-level languages: precise, unambiguous, consistent.
You can’t convince a compiler that adding a number to a string makes sense.
Irony — a close cousin of humor — is not a machine’s strong suit. Programmers, however, are quite good at it.
A charming example of programmer humor are Easter eggs: undocumented and unexpected behaviors triggered by specific user actions.
They can be found in many popular applications like Excel or Word. Python contains quite a few of them as well (example list), and so does Linux.
Easter eggs also appear in hardware and even inside silicon itself. No kidding — someone has to be a very dedicated nerd to hide jokes at the microscopic level.
// magic. do not touch.
Humorous touches also show up in code comments.
Comments are messages from programmers to other programmers explaining why a certain design decision was made. Or sometimes why a decision wasn’t made — or the work wasn’t done at all (hello, famous TODO).
Some comments can be genuinely hilarious. If you need proof, check out this StackOverflow thread.
Programmers are such incorrigible jokers that even extremely serious projects contain playful details. For example, the control module code of Apollo 11 — the one that helped send humans to the Moon — contains a number of humorous remarks.
Curious Marc and his crew did a great job highlighting them:
Another example: Microsoft recently released the source code of BASIC 6502 on GitHub.
For context, this was a BASIC interpreter written in assembly for 8-bit processors like the MOS 6502 — the chip powering legendary machines such as the Apple II, the Nintendo Entertainment System, and the Commodore 64.
A piece of computing history in a single file.
What surprised me is that almost nobody pointed out the absolute gold mine hiding in the comments written by the authors themselves — Bill Gates and Ric Weiland 🙃
And now the slightly bitter twist: comments are not an integral part of programming languages. Code works perfectly well without them.
The processor simply ignores them.
The machine’s reality
What else does the processor ignore?
Pretty much the entire human world.
Programming languages lack all the visual, vocal, and gestural elements that accompany human speech. They also lack access to the broader context of reality — human experience and observation.
This probably explains why AI sometimes produces bizarre answers to questions that even a small child would handle correctly.
There is actually nothing funny about this.
It simply shows that the answers generated by AI are driven by probability, not by some extraordinary intelligence attributed to the machine.
A computer has no way of verifying whether the results of its operations correspond to the real world humans live in.
If our program prints the following statement about reality:
isHot = True
print("Is it hot today?\n",isHot)
and outside there’s a freezing blizzard, the CPU doesn’t care.
From the machine’s perspective everything checks out: the operations defined in the code executed correctly. We don’t ask a calculator about parts of the world it cannot access. Its answers can coincide with reality only by coincidence — not by design.
This is a universal rule and arguably the fundamental difference between human and machine languages.
They share structural similarities, but they refer to entirely different realities.
To avoid confusion — especially in discussions about AI — we probably need better conceptual categories than the language metaphors we currently use.
This may sound controversial. After all, software is a human creation and therefore exists within our reality.
It can interact with that reality: read sensor data, analyze space, sound waves, and light. It can control vacuum cleaners, airplanes, nuclear reactors, and coffee machines.
But even then, appropriate reactions to faulty sensor readings are simply the result of good error handling and fallback logic — not genuine situational awareness.
There and back again
In natural languages, the human world forms the foundation of semantics — the meanings of words and expressions.
The external context of an utterance — who speaks, how they speak, and what they point at — often resolves ambiguities common in everyday speech.
If you say in a restaurant: “pass me that,” while pointing at the salt shaker, your companion will likely grab it without hesitation.
Yet according to the dictionary definition, “that” could refer to almost anything.
Linguistics has a special term for such context-dependent expressions. Actually several terms: deixis, indexicals, shifters. I’ll stick with the term deixis.
They anchor speech to a specific situation:
- time (“now”, “later”, “yesterday”)
- person (“I”, “you”, “she”, “this”)
- place (“here”, “there”)
They exist in every natural language, and their meaning depends entirely on context.
A simple example: saying “come here” points to a different place depending on whether you say it from your basement or while calling your dog in the forest.
Intuitively, deixis should not appear in programming languages because it introduces semantic instability.
And yet it does.
In code we encounter many expressions whose meaning depends on context. Relative file paths are a simple spatial example:
./here.txt // file in this directory
../there.txt // file in the directory above
Code, like a poem or a novel, exists physically. In the past it was literally printed on punched cards or tape.
Modern code may be less tangible, but it still occupies space — visually in an IDE and physically on disk.
Executing code introduces the dimension of time.
Because of this, programming languages contain many constructs resembling deixis, such as:
These examples come from different languages and contexts, but the underlying principle is the same: the meaning of these words depends on where they appear.
Programming languages, in this respect, are not that different from natural languages. They have their own temporal, spatial, and relational realities.
Walruses and spaceships
Using language is intuitive for its speakers. We learn syntax from early childhood and manage daily communication without knowing what a noun or future perfect tense is.
We simply know which constructions sound right.
Syntax becomes a kind of scaffolding built from familiar pieces.
For instance, in many languages the phrase “not only X…” implies that something else will follow. These are called correlative conjunctions.
The phrase “not only X…, but also Y” is semantically very close to the logical operator && or and in many programming languages.
Code contains many such syntactic constructions that translate nicely into natural language equivalents.
One example is Python’s walrus operator (:=). It allows assigning a value to a variable while simultaneously using that value in an expression.
Instead of writing:
x = 5
if x > 3:
print("x is greater than 3")
we can write:
if (x := 5) > 3:
print("x is greater than 3")
If translated into spoken language, the expressions might look something like this.
Without the walrus:
X is the number 5.
If X is greater than 3, write that X is greater than 3.
With the walrus:
If X is the number 5, which is greater than 3, write that X is greater than 3.
Not exactly poetic, but the idea is clear: certain linguistic operations can be expressed in different ways without losing meaning. We simply use a different syntactic scaffold.
Another example of syntactic economy in programming languages is the spaceship operator (<=>).
It compares two values and returns:
0if they are equal1if the left value is greater-1if the right value is greater
The expression 7 <=> 7 returns 0.
In natural language we make comparisons like this all the time:
- “I earn more than Kumar” → (1)
- “I have as many bugs as Dmytro” → (0)
- “My IQ is lower than Oktawian’s” → (-1)
And finally, the ternary conditional operator.
It concisely expresses both a condition and the alternative outcome.
int cookies = 2;
printf("%s\n", (cookies > 0) ? "Take a cookie!"
: "Oops, we're out of cookies");
Translated into plain language: there are two cookies, so take one.
Hard to make it simpler.
And in its own way, more beautiful.
But that’s a story for the next part.