|
By Adrian Kosmaczewski, June 2nd, 2025
Welcome to the 81st issue of De Programmatica Ipsum, about Compilers.
In this edition:
Download this issue in DRM-free PDF or EPUB format, and read it on your preferred device. You can also subscribe to our RSS feed, featuring the full content of our articles.
We would like to thank our patrons who generously contribute every month (or have contributed in the past) to our work and help us run this magazine. Thank you so much! In alphabetical order: Adam Guest, Adrian Tineo Cabello, Benjamin Sheldon, Christopher Nascone, Colin Powell, Franz Lucien Moersdorf, Guillermo Ramos Álvarez, Jean-Paul de Vooght, Dr. Juande Santander-Vela, Patryk Matuszewski, Paul Hudson, Quico Moya, Roger Turner, Szymon Licau, and countless more leaving anonymous tips every month.
Enjoy this issue! Please subscribe to our free newsletter to stay updated about new releases, share the articles on social media, or contribute if you would like to support our work with a donation via Liberapay.
Cover photo by Kelly Sikkema on Unsplash.
|
|
|
The Allure Of Vibe Coding
|
|
|
By Adrian Kosmaczewski, June 2nd, 2025
“Compiler Explorer” is the name of a fascinating project by Matt Godbolt, a British C++ software developer living in Chicago. It is the simplest and most wonderful thing; just paste a snippet of code on the left pane (in C, C++, D, C#, Java, Python, and a myriad more languages), and you will see on the right its equivalent in assembly code, as produced by one of a long list of compilers, including some commercial ones, for a wide variety of CPU architectures and software versions.
The default example, when you access the website for the first time, converts (at the time of this publication) the C++ code below,
// Type your code here, or load an example.
int square(int num) {
return num * num;
}
into the following x86-64 assembly code, as compiled by GCC 15.1:
square(int):
push rbp
mov rbp, rsp
mov DWORD PTR [rbp-4], edi
mov eax, DWORD PTR [rbp-4]
imul eax, eax
pop rbp
ret
(As you can imagine, the line imul eax, eax is the one performing the actual squaring of a number; the rest is just bookkeeping and ABI compliance.)
Not only that, but this gem of an open source project highlights the equivalent instructions between the C++ code and the resulting assembly using the same colors. The fun begins when you change the target CPU architecture (ARM, RISC-V, POWER, SPARC, MIPS, etc.) or the word length (32 or 64 bits), and you realize the diversity therein… even though all of those assembly snippets, from the point of view of the user, essentially do the same thing.
For example, the same C++ code, using the same GCC 15.1 compiler, produces the following ARM64 assembly:
square(int):
sub sp, sp, #16
str w0, [sp, 12]
ldr w0, [sp, 12]
mul w0, w0, w0
add sp, sp, 16
ret
(Again, the line mul w0, w0, w0 needs no explanation.)
Compiler Explorer is a humbling and refreshing look at the compiler, the ultimate developer tool, the one that has singlehandedly defined developer experience during the past 73 years. The one that provided a very welcome layer of translation between humans and machines, allowing people to represent algorithms and data structures with a language akin to English or mathematics, all while enabling the porting of software across platforms as a bonus.
After overcoming the initial skepticism (“I can generate much better machine code that this thing!” dixit operators in front of an IBM 1401), compilers have grown in sophistication. They have evolved from the single-pass BASIC compiler of Dartmouth in 1964 and the typeless, simple BCPL compiler of 1967, to the powerful LLVM infrastructure enabling a strongly-typed language like Rust.
It seems to me that we have reached a summit in compiler extravaganza. The four wonders of the compilation world, are all open-source, free as in beer as free as in freedom, and each has enabled successive revolutions of its own: GCC, LLVM, V8, and GraalVM.
In particular, I have often considered LLVM (kids: that is not the same as “LLM”, keep on reading to learn more) as the biggest breakthrough in software technology of the past few decades. Just to give everyone an idea, this is the compiler framework that begat Clang, Rust, Emscripten, Zig, and Swift. It is hard to overstate the importance of the work that Chris Lattner has given the world for free.
But we are in 2025, so for the purposes of this article I literally asked ChatGPT the same question (that is, to translate the snippet of C++ code above into the flavors of assembly chosen previously), and it did not disappoint, bookkeeping and ABI compliance notwithstanding.
I have recently blogged about “vibe coding” the C version of a personal project of mine, and making it compatible with C89, an old but widely supported standard of C in retrocomputing environments, with extraordinary results.
Have I cared about the compilers themselves during the exploration process that led to my article? Yes, but admittedly at a very superficial level; the biggest concern was, as you can imagine, the syntax of flags and arguments to pass at the command-line level, and how to find the proper preprocessor macro that identified each of those compilers of yore. Said complexity would be, in turn, abstracted away on a script or a Makefile, and promptly forgotten.
Gone are the days of debating whether a language was Turing Complete or not; gone are the days of YACC and Backus-Naur forms; gone are the days of CompCert.
Precisely, software developers have been abstracting themselves from the computer, in a slow but steady process. And we continue to do so right now with LLMs, “Copilots”, and similar contraptions. “Automatic Programming” as the one promised by Remington Rand’s FLOW-MATIC in 1957 led to higher and higher levels of abstraction and type checking, to finally a know-it-all chatbot that will ultimately make ours an obsolete and vintage profession worthy of a museum.
Despite their naming similarities, LLVM and LLM are truly very different things. Compilers are predictable and deterministic machines; same input code, with same flags and under the same versions, produce the same output. LLMs, and its associated new kid on the block, “vibe coding”, are based on a random, statistical, and unpredictable machine.
But as we have argued before, we have opened Pandora’s Box, and we cannot go back in time. We have to contend with LLMs today, whether we like it or not. That means that we have to teach younger generations of software developers not only how to use these new tools, but also the intricacies of the lower-level, deterministic, arguably old-fashioned compilers that made our craft possible during the past seven decades.
We cannot preclude developers from “vibe coding” their way into a working application; but we can teach them how to properly integrate the very likely spaghetti mess produced by those bullshit machines, how to understand it, and how to make it work with today’s compilers, which, let us be honest: are the best we have ever had, and it would be a shame to ignore them completely. And Godbolt’s Compiler Explorer is an extraordinary tool for that matter.
We must, however, make sure that their human skills stay valuable in the workplace, teaching them all the empathy, writing skills, and ethics that you cannot neither embed in the source code of a compiler, nor feed into an LLM.
Cover photo by Igor Omilaev on Unsplash.
|
|
|
Grace Hopper & David Letterman
|
|
|
By Adrian Kosmaczewski, June 2nd, 2025
Among the many documents available at the Computer History Museum website there is an interesting artifact: a commercial brochure published in 1957 by the Remington Rand UNIVAC, “a division of Sperry Rand Corporation”, titled “introducing a new language for automatic programming”. In it, we learn about the advantages of the new (at the time) FLOW-MATIC programming language, the brainchild of United States Navy Rear Admiral Grace Murray Hopper.
On page five of this brochure we find, among an enumeration of six key advantages of FLOW-MATIC, a beautiful quote that resonates strongly in the soul of this magazine:
Breaks the Communications Barrier Between Programming and Management Groups
Since FLOW-MATIC uses English through all preliminary stages of an application, the programming is intelligible to all who understand the application. This makes available to the programming effort the knowledge of many experts previously excluded.
The impossible dialogue was already a problem in 1957. I do not think this should be a surprise to anyone.
Contrary to the popular lore, Grace Hopper neither came up with the idea of the compiler, nor wrote the first one from scratch; the truth is a bit more subtle, as explained on a post published in 2022 on the Communications of the ACM blog:
These elucidations can be summarized as follows: Heinz Rutishauser was the first to propose automatic programming (machine translation with the aid of the computer, 1951/52) and Grace Hopper developed the first utility programs for the management of subprograms (1952). Alick Glennie lays claim to the first true compiler that actually operated on a computer (1952).
But we are not interested in knowing who did what first; this is not a Grand Prix. We do know that Grace Hopper was the first to refer to program errors as “bugs”, as explained on the Fireship YouTube channel:
This month’s Vidéothèque video starts with the quintessential founding myth of our craft: Grace Hopper finding the legendary moth (“bug”) stuck in her computer. According to the narrator, and quite truthfully so, developers these days can create their own bugs thanks to, you guessed it, code editors.
Ms Hopper also effectively designed a series of interpreters and compilers (A-0, ARITH-MATIC, MATH-MATIC, and FLOW-MATIC) leading to her participation in the COBOL committee, which included a distinguished group of pioneers featuring none other than Bob Bemer, the creator of IBM’s COMTRAN programming language.
What is important to remember, though, is that Ms Hopper had a hard time convincing her management of the importance of the idea of having a program translating an English-like language into machine codes, as explained on a recent article on IEEE Spectrum:
“I had a running compiler, and nobody would touch it, because they carefully told me computers could only do arithmetic; they could not do programs,” Hopper said. “It was a selling job to get people to try it. I think with any new idea, because people are allergic to change, you have to get out and sell the idea.”
It took two years for the company’s leadership to accept the A-0.
Today, thankfully, the location where Ms Hopper created the A-0 compiler is recorded with an IEEE Milestone recognition plaque at the University of Pennsylvania.
Grace Hopper was chosen by famed photographer Lynn Gilbert among 46 pioneering American women to be interviewed for her 1982 book “Particular Passions: Talks with Women Who Have Shaped Our Times”. Ms Hopper shared those pages with luminaires such as Billie Jean King, Ruth Bader Ginsburg, and Julia Child, among others. (Kids: if you do not know who these women are, look them up and read their Wikipedia entries. Please.)
There is a freely available chapter (well, at least at the time of this publication) of “Women of Wisdom”, a selection of 12 of those 46 interviews, published in 2018 by the same Lynn Gilbert, featuring two major gems in Grace Hopper’s interview that I would like to highlight here. The first is the not-so-obvious realization that the computer industry is a direct offspring of the United States’ government spending, and that the current defunding, as presently led by some techbro oligarchs, can only spell disaster.
I think one of the reasons we’re not getting those kinds of innovations today is that government support has almost totally disappeared, and with inflation, companies themselves have cut back on the amount they spend on research. They may spend the same amount but because of inflation it doesn’t have as much effect. You’ll notice that much of the equipment we’re using today is the result of the work done right after World War II—the forties and early fifties.
The second quote is the same Grace Hopper reminding us that computers, as they were originally designed, were meant to work for humans and to make their lives easier, not the other way around.
My vision of a world with computers is a world in which people have a lot more time to do what they like, to do what they want to do and read the books they want to read. It won’t make books obsolete, it’s too tiring to read on computers. Playing tennis, jogging… they’ll have plenty of time to go to the shore. I’d go over to the library and start digging through books. I could do my work at home. I could have a computer at home and talk to my office. I could live up on top of a nice mountain in New Hampshire and smell pine trees and it would be the same as if I were here in the sub-sub-subbasement of the Pentagon.
Amazing Grace, we hear you.
The cover picture of Lynn Gilbert’s book features a 1977 photograph of Grace Hopper snapped by (you guessed it) Gilbert herself, and for those of you interested, it is part of a limited set and its silver gelatin print, available at the Ilon Art Gallery of New York, sells for a modicum sum of USD 2’500.
Ms Hopper was a fearless fighter against the impossible dialogue. In the book “A History of Computing in the Twentieth Century” by Nicholas Metropolis, Jack Howlett, and Gian-Carlo Rota, there is a chapter titled “The Early Development of Programming Languages”, available at the Internet Archive, written by none other than Donald Knuth and Luis Trabb Pardo. In turn, this chapter quotes Grace Hopper’s 1959 paper “Automatic programming: present status and future trends” in pages 217 and 218, with this outstanding excerpt:
I used to be a mathematics professor. At that time I found there were a certain number of students who could not learn mathematics. I then was charged with the job of making it easy for businessmen to use our computers. I found it was not a question of whether they could learn mathematics or not, but whether they would.… They said, “Throw those symbols out–I do not know what they mean, I have not time to learn symbols.” I suggest a reply to those who would like data processing people to use mathematical symbols that they make them first attempt to teach those symbols to vice-presidents or a colonel or admiral. I assure you that I tried it.
Check out this month’s Vidéothèque entry, Grace Hopper’s appearance at NBC’s “Late Night with David Letterman”, aired October 2nd, 1986. This witty, charming, funny, and outstandingly brilliant person, the real “Queen of Software”, spontaneously produced a memorable quote for posterity:
Letterman: How did you know so much about computers then?
Hopper: I didn’t–this was the first one.
Cover snapshot chosen by the author, precisely right after the audience erupts in laughter after Grace Hopper’s reply, and Letterman’s realizes the brilliance of the moment.
|
|
|
By Adrian Kosmaczewski, June 2nd, 2025
There are a lot of different things we could have talked about in the Library section of an edition dedicated to compilers; one obvious choice would have been to talk about the quintessential compiler theory book, the 1986 “Dragon Book” also known as “Compilers: Principles, Techniques, and Tools” by Alfred V. Aho, Ravi Sethi, and Jeffrey D. Ullman. As excellent and Wikipedia-worthy as this one is, that is not the book we will talk about here.
We are in 2025, and there is no shortage of excellent resources devoted to the craft of compiler making. For the sake of the curious among you, we can mention a few honorable choices, at least according to the taste of this author.
We have already mentioned in the pages of this magazine (during the edition dedicated to the Go programming language) the fantastic “Writing An Interpreter In Go” and “Writing A Compiler In Go” by Thorsten Ball. We can only wish Mr. Ball a boost in sales after the one and only Anders Hejlsberg recently announced a rewrite of the TypeScript compiler… using the Go programming language, precisely.
Definitely worthy of mention are also “Modern Compiler Design”, a book written in 2000 by Grune, Bal, Jacobs, and Langendoen. The beautiful and recent “Crafting Interpreters” by Robert Nystrom. Or the 1996 “Compiler Construction” book by none other than Niklaus Wirth. Speaking about celebrities, the long-awaited Volume 7 of “The Art of Computer Programming” by Donald Knuth will be titled “Compiler Techniques”… hopefully.
It would be unfair to leave Jack Crenshaw’s classic “Let’s Build a Compiler” series out of this review. Originally published between 1988 and 1995 at the “comp.compilers” Usenet newsgroup, and illustrating the construction of a compiler written in the Pascal programming language targeting the Motorola 68000 CPU architecture, this resource has been adapted and prettified numerous times, for example into C compiling to x86 code, in Go, in JavaScript, and yes, even in Rust, because we have to rewrite all things with it.
Maybe you prefer to see the source code of a compiler? Instead of dealing with open source behemoths such as LLVM, GCC, GraalVM, or the V8 JavaScript engine, you could instead study a compiler for a small subset of Scala, or the embeddable and short (merely 20’000 lines of code) LCC compiler. If you are still interested in diving into the LLVM source code, remember that Amy Brown and Greg Wilson have your back.
Want more? Check out the seminal paper titled “A Catalogue of Optimizing Transformations” written in 1971 by IBM engineers Frances Elizabeth Allen (the first woman to win a Turing Award) and John Cocke (usually referred to as “the father of the RISC architecture”). On pages 34 to 52 of the October 1978 edition of Byte Magazine, interspersed in between all the advertising, you could find the commented source code of a Pascal compiler written in BASIC. There is also Loren Segal’s article called “Writing Your Own Toy Compiler Using Flex, Bison and LLVM”, and Douglas Thain’s free e-book, “Introduction to Compilers and Language Design”. And we could go on and on, including tutorials and online courses and university lectures about the subject.
Phew. Clearly, a lot of ink has been spilled about compilers during the past 50 years. No need to say more; instead, and following our style, we decided to steer away from dry subjects such as abstract syntax trees, generators, P-code, and what-have-you, instead focusing on a book that deserves more praise. One that, in all honesty, we completely forgot to mention when we reviewed our brief history of programming artists, more than 6 years ago. We feel bad about this omission, so here we are trying to fix this injustice.
This month’s Library entry is “Geek Sublime: Writing Fiction, Coding Software”, a 2014 book by Vikram Chandra, and which, if you have not already, I beg you to grab a copy of and read it. Never before have I implored my readers to read a book; I am doing this now.
And no, this is not going to be a classic book review article, either; we leave that job to Jacob Silverman from The New Republic, who did an excellent job at precisely that in 2014:
If it’s not apparent already, this isn’t your typical tech book. Despite its thin profile, Geek Sublime is unusually expansive and rich. Its concerns are deeply heterodox: the difficulty and joys of coding, Sanskrit linguistics and literary theory, free market ideology, British colonial history, Indians in Silicon Valley, the writing of Chandra’s first novel, suppressed Hindu sects, women’s diminished status in the tech industry (in India, the situation is markedly better).
In my own personal website I sketched some notes that convey the sense of wonder I got through the lecture of this gem back in the day:
An absolute surprise, a delightful read. Astonishing and very, very deep. The geek part is actually almost irrelevant. The key is language, communication, gender, history, preservation, unity, rasa and dhvani through literature and poetry. Extraordinary.
What? Rasa? Dhvani? What are those things, and what do they have to do with code? Vikram Chandra explains:
Dhvani derives from dhvan, “to reverberate”; dhvani poetry therefore causes an endless resonance within the reader—“the suggested sense [flashes] forth in an instant in the minds of intelligent auditors who are averse to the literal sense and in quest of the real meaning.” (…)
So rasa—the word literally means “taste” or “juice”—is not emotion (bhava); it is the aestheticized satisfaction or “sentiment” of tasting artificially induced emotions.
And the connection comes in chapter 10:
The effects of code will spill out from the compiler; its vyanjana or suggestiveness will echo through the world and the human body. Undoubtedly, artists will—and already do—arrange this suggestion to manifest dhvani and rasa.
In his ground-breaking “Tractatus Logico-Philosophicus” published in 1922, Austrian philosopher Ludwig Wittgenstein wrote this (often quoted) phrase:
Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt.
In English: “The limits of my language stand for the limits of my world”.
Programmers, as users of compilers, experience Wittgenstein’s observation every day; newer programming languages provide more sophisticated ways to express algorithms, thereby expanding the limits of their own programming capacity, LLMs and “vibe coding” notwithstanding. Compiler and language designers “frame” the ways in which an algorithm can be described, and thus, how a programmer can express themselves, hopefully providing Turing completeness in the mix.
In “Geek Sublime”, Chandra connects East and West, Lacan and Abhinavagupta, and, needless to say, in a much more serious way than Geoffrey James’ “Tao of Programming”:
Jacques Lacan broke from the psychoanalytic establishment with his famous manifesto “The Function and Field of Speech and Language in Psychoanalysis,” and in this speech he refers directly to Abhinavagupta and dhvani theory, invoking “the teaching of Abhinavagupta” to elaborate upon “the property of speech by which it communicates what it does not actually say.” Lacan argued that the unconscious “does not express itself in speech; it reveals itself through suggestion,” and that the analyst should deploy the power of dhvani “in a carefully calculated fashion in the semantic resonances of his remarks.”
As programmers, we have a never-ending duty of expanding our horizons, learning new languages every so often (of the human and programming kind), and increasing our capacity for understanding. This ongoing task will make us not only better programmers, but also better humans. In this time and age, we need more of this superpower called empathy. And Vikram Chandra’s book is all about his own personal quest for knowledge and wisdom, both through computer and human lingo.
No need to drop acid, as Steve Jobs allegedly once told Bill Gates; this book will do, thankyousomuch.
Now that the summer months are approaching in the Northern Hemisphere, I can only wish you to carry in your bag a copy of “Geek Sublime” by Vikram Chandra, either in paper or in electronic form, and enjoy your well-deserved time off with a book that speaks not just to your brain, but also, and most importantly, directly to your heart.
Cover photo from the book’s website.
|
|
|
|
|
