Language Implementation Patterns: Create Your Own Domain-Specific and General Programming Languages
Buy it now
One Minute Bottom Line
|This book gives you the knowledge to create your own domain-specific and general programming languages.|
In high-school I created ACID1, a clone of the BASIC programming language. ACID1 was never completed though 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.
With these failures, I learned 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 Books anyone?). A middle ground was required.
I found Language Implementation Patterns (LIP, if you will, since we are quite pleased with K&R, CLRS, TAOCP, etc.) by Terence Parr about a month ago. When I picked it up, my internal alarm went off, I felt it was going to be a good read.
I knew I was going to enjoy this book because Parr has been teaching language applications programming for years and because the book comes from the famous Pragmatic Bookshelf. Guido van Rossum, creator of Python, commented: Throw away your compiler theory book!
As predicted, 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 perfect working ACID.
Parr uses Java for his examples. I confess that I barely know Java. But half the patterns I have translated to Python. This wouldn't have been possible without his explanations.
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 a real world example. Professor Parr explained why you don't need LL(k) for, say, a simple list ([a,b,c]) parser.
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.
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 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 tweaking, Java. Needless to say, Chapter 13 is chapter You can't skip it.
- 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. With Chapter 13, that's 7 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 even essential knowledge.
Parr has written a small classic here. The book deserves a place on the golden shelf. I once asked Brian Kernighan (bwk for those who know) what constitutes a good book. And his 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 to Parr for LIP that fulfills all the above requirements.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)