I was sitting in an intermediate-level compiler class many years ago. The professor opened the lecture that day with a recruiting announcement for her mobile social network project. “We’ve built it wrong for the desktop operating system,” she said, “and we have spent the next two decades fixing the security issues that has created.” It was still the early days of programmable smart phones, her thinking goes, and there were still opportunities to experiment with alternative models of device-mediated social connections. Decentralized, peer-to-peer social applications, for example. She was also opposed to the programming model where you have to pay your phone’s vendor just to be able to put your own code on your own phone.
I wasn’t too much interested in that project. I had been a commercial app developer for many years already, and I remember shaking my head when I took a look at some of their lab’s early demos. They looked so rudimentary. Lacking polish. A sign of not having the attention to details. The words I parroted from tech pundits back then.
These days I read few tech commentaries, but after so many years I still come back to that comment of hers. That we can’t stop thinking and talking about our relationship with our devices—and the online services we rely on through the devices—is certainly a sign that we’ve built it wrong.
I missed the aspect of frustration when she said that we had collectively failed creating today’s desktop operating system. People knew how not to design a computing architecture. Capability-based access control, just to name one, had existed in computer science literature long before personal computers were a thing, yet we collectively simply didn’t go down that path. Checking access privilege before doing anything with the data was such an added-on latecomer in personal computing and networking that we are still living with the security implications of many design decisions made decades ago. In a similar vein, we have learned enough from the past two decades how not to design user interfaces or online services, yet we still have collectively gone along with the trajectory (because you have to allude to ballistics when you talk about technology; paths are for slowpokes on earth) we are on now.
Two additional thoughts here. First, by saying “we’ve built it wrong,” it implies that there could have been a right way to build it. I have never noticed that until very recently, but you seldom hear people say “we should never have built it,” which is a totally different matter and attitude.
The other point I wanted to make is that we tend to resign ourselves to the impersonal forces that have shaped the world. Market force, for example, is often what many of us attribute to how the personal computer ecosystem had been shaped. One prevalent attitude towards impersonal forces is Panglossian: an optimistic, perhaps-it-all-works-out-in-the-end, look-at-how-many-things-we-enjoy-now-are-because-of-it attitude, but that is perhaps a very recent development. Even just riding along with the impersonal forces sets up many a premise of classic tragedy, and perhaps the time has finally come for us technologists to ask what we have wrought in the past two decades.
There’s a reason why this intermediate-level compiler class has left such an impression. Early on, she made a bold statement that the parsing theories we had learned previously and all the optimization techniques we were going to learn at her class were all good, but none of those contributed to the most improvement of programmer productivity in the previous decade. No one who raised their hand could guess what that was on her mind.
It turned out to be quality of error messages. In other words, diagnosis. The fact that compilers could finally tell you which exact keyword or variable name that you typed wrong and where exactly you made the mistake was, according to her, the biggest improvement that few in her field had really focused on. Ironically, she told us, such improvement was made possible by throwing out everything we learned at our entry-level class: none of the industry-grade compilers we used at that point were created using parser generators (a mechanism that automatically generates parsers according to your grammar rules) powered by the theories; all of them had hand-written parsers created with the technique that could be covered by by two, three hours of lecture, and yet what difference in usability this makes through going back to such a prosaic technique. We trusted her: the professor was the fourth author of a definitive textbook in that field, and it’s not common that someone whose textbook has pretty much defined the field tells you that you may as well put a lot of those aside when you go into practice.
2026-07-06