In high school I created ACID1, a clone for the BASIC programming language. ACID1 was never completed but I felt I could take the world down with my very own programming language. That did not happen. ACID2 was born some years later in a college dorm. It did not work either.
These failures taught me an important lesson. ACID1 was created with no prior knowledge of language building whatsoever. ACID2 was, however, created with a surplus of theories (the Dragon Book, anyone?). I needed a middle ground.
I found Language Programming Patterns by Terence Parr about a month ago. LIP, if you may, since we are quite pleased with K&R, CLRS, TAOCP, etc... When I picked up LIP, my internal alarm went off, I felt it was going to be a good read.
Guido van Rossum, creator of Python (Python forever!), commented: Throw away your compiler theory book! So I knew. I also found out that professor Parr has been teaching language applications programming for years. Then I knew. The book itself came from the famous Pragmatic Bookshelf. And I knew: LIP would be a good read.
The book did not disappoint me, and will not disappoint any programmer with interests in language applications. LIP is the perfect mix of theory and practice. LIP is the working ACID I did not write.
Parr uses Java for his examples. I confess that I barely know Java. But half the patterns I have translated to Python while reading. This wouldn't have been possible without the great explanations in the book.
Each pattern has a Purpose, a Discussion, an Implementation, and Related Pattern section. Patterns are grouped together in chapters in such a way that when you've completed the chapter, you have a complete skill.
In chapter 2, Basic Patterns, for instance, I reminisced strange symbols like LA, LL(1), LL(k). Only this time they made actual sense and were put in real world examples. Professor Parr explained why you don't need LL(k) for, say, a simple list ([a,b,c]) parser. Programmers will often go miles to accomplish this.
Parr uses his popular tool ANTLR a lot in the text and this might annoy some. It is also my only regret. In his defense, good alternatives to ANTLR are scarce. Oh well. I, who have scant knowledge of Java, completed the book. So should any programmer.
There are 31 patterns in LIP. You dont have to know them all. Just where and how to find them. Chapter 10, Building Bytecode Interpreters, is easily my favorite. For long I wanted to learn how bytecode interpreters work. Chapter 10 discusses two patterns: Stack-Based Bytecode Interpreters and Register-Based Bytecode Interpreters. Popular Lua uses a Register-Based Bytecode Interpreter for example. Python (Python forever!) is Stack-Based.
Chapter 13, Putting It All Together, is the ice cream. In that chapter, Parr shows how to put your patterns together to fix real world problems: finding patterns in proteins structure, building a scripting language to generate 3D scenes, and fixing, sorry I meant tweaking, Java. Needless to say, Chapter 13 is the chapter you must not skip.
I believe chapters 1 through 6 are the core. The matter. The substance, like my chemistry professor used to say. Patterns from these first six chapters are all you need to build a simple language. We are talking no data aggregation and object orientation, right? With Chapter 13 (the one I just discussed), that's seven chapters not to skip.
Fellow dynamically typed languages lovers: Chapter 8, Enforcing Static Typing Rule, will fill our faces with smile and brighten our day, let's not skip it. It is essential knowledge.
Professor Parr has written a classic here. The book deserves a place on the golden shelf. I once asked Brian W. Kernighan what constitutes a good book. And the reply was insightful.
Kernighan wrote that he believes in books that are authoritative, are written by authors who love what they are writing about, instead of what is hot. He added that books should be pragmatic and useful rather than theoretical and philosophical.
Thank you professor Parr, for writing LIP.