Error Messages Are Lying to You (And That’s Okay for Machines)
2026-01-24
You know what drives me crazy? Python error messages.
When something goes wrong in my code—usually a simple logic error I made—Python fills my entire screen with a towering backtrace through libraries I didn’t write, functions I didn’t call, and stack frames I don’t care about. It’s the programming equivalent of asking “where are my keys?” and getting a lecture on the history of metallurgy.
As a human, I want my error messages concise. Tell me what broke, where I broke it, and ideally why. That’s it. Everything else is noise.
But here’s where it gets interesting.
The Machine Doesn’t Care
LLMs and other automated tools? They’re the opposite. They thrive on verbose, detailed, redundant information. Feed them a massive backtrace with every stack frame, every variable state, every imported module—they’ll parse it instantly and probably find patterns you’d miss.
This raises a question I’ve been circling around: Should error messages for humans be fundamentally different from error messages for machines?
I think the answer is yes, and it points to something deeper about how we design programming languages.
We’re Still Writing for Human Eyes
Every mainstream programming language—Python, JavaScript, even the “modern” ones—is designed primarily for human readability. Syntactic sugar everywhere. Meaningful variable names. Indentation. Comments. All the things that make code “clean” and “maintainable.”
But machines don’t need any of that.
I’ve started treating existing programming languages as assembler for something better. My recent experiments generate “ugly” Python and JavaScript—code that would make any human reviewer wince—but it’s correct, it works, and most importantly: the machine doesn’t care how it looks.
When you stop optimizing for human eyes, you unlock new possibilities. Machine-readable code can be generated from higher-level abstractions. Machine-writable code can be assembled from parts without worrying about aesthetic conventions.
Two Different Audiences, Two Different Languages
The insight isn’t just about error messages—it’s about the entire development stack.
Humans need one interface: concise, clear, abstracted.
Machines need another: verbose, detailed, explicit.
Right now, we’re trying to serve both audiences with the same tools, and we’re doing a mediocre job for both. Maybe it’s time to stop compromising.
What if we designed languages explicitly for machine consumption, with human-friendly views generated on demand? What if error messages knew their audience and adapted accordingly?
The tools are finally here to make this practical. We just have to let go of the idea that code must always be written for human eyes first.
What’s your most frustrating error message experience? Reply and let me know.
See Also
Email: ptcomputingsimplicity@gmail.com
Substack: paultarvydas.substack.com
Videos: https://www.youtube.com/@programmingsimplicity2980
Discord: https://discord.gg/65YZUh6Jpq
Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas
Twitter: @paul_tarvydas
Bluesky: @paultarvydas.bsky.social
Mastodon: @paultarvydas
(earlier) Blog: guitarvydas.github.io
References: https://guitarvydas.github.io/2024/01/06/References.html