Preface

I grew up experimenting with BASIC on an MSX computer in Brazil. That was a time when the computer would come with a printed manual that had little games and exercises with the code listings, and you would have to type it out to see what happened. When my family got a 486 PC, I transitioned to QBASIC. I still remember the first time I built an entire game with animations and everything from scratch.

Later, I transitioned to Delphi, where I would help my older brother in some of his projects, and eventually presented a small educational application at my school that I built with a colleague to explore the periodic table. At that time, I was also transitioning to using GNU/Linux and exploring with C programming.

I only became a “real” software developer once I learned Perl. This was 1998, and my older brother bought the Learning Perl and Programming Perl books. I still spoke “baby Perl,” as Larry Wall would say, and it would be a few years until I was confident enough to ship my first module to CPAN.

I became an avid advocate for the Perl language and started publishing various CPAN modules and participating in conferences. I remember all the hours I spent on perlmonks.org, and the moment my name finally showed up on the Saints in Our Book page.

But while at the turn of the century, Perl was “the duct tape of the internet,” by the turn of the 2010s, there was a very strong sentiment against it in the industry. I had to accept that I couldn’t just be a Perl developer; I had to be an “anything developer.”

This has led me to take a very different perspective when looking at programming language and interpreter design. To look beyond the what and start asking the why. Why did Python choose to use a Global Interpreter Lock? Why did Perl have a share-nothing approach for multi-threading? Why does the C++ language have entirely different systems for programming and meta-programming?

Meanwhile, my formal education was in social sciences, which made me look at all of this from an anthropological perspective. At the end of the day, we’re talking about human communication; there’s no stick we can use to measure whether one language is better than another. You have different languages and people with different levels of fluency. You have ecosystems and communities that build a specific culture around those languages.

It is with this perspective that I arrived at the premise of this book, which is that we will never stop creating new programming languages, for as long as we have to write code. But this doesn’t need to be just a matter of aesthetic preference. Some niche problems require niche solutions, and building programming language interpreters is a way to introduce novel solutions to existing problems.

At the same time, a programming language is heavily influenced by the runtime environment it targets, but it’s also possible to build custom runtime environments that target a specific programming language.

The existing literature tends to treat those areas as fundamentally independent, while I feel that there is a lot left behind by not considering the design and implementation of the programming language and of the runtime environment it targets as a coherent set.

That is why it was important to me to choose a bottom-up approach when working on this book. I want you to look at the entire problem of both programming language and interpreter design and implementation as a single unit.

By the end of this book, I hope that you find yourself as fascinated as I am by all the technical and non-technical aspects that are connected to programming language and interpreter design and implementation.