Rich Programmer Food

Pretty entertaining, if a bit melodramatic.<p>I really wish people didn't mystify such a basic programming skill. Compiler hacking is something reserved for the wizards <i>only</i> if you take the classic definition of compiler implementation: an expensive engineering project, targeting a new processor, architecture or OS.<p>In that sense, sure. You will be working in a lab with hundreds of developers, and tinkering with a piece of multimillion dollar prototype.<p>In reality, however, "compiler construction" boils down to foundational language theory, along with various tricks and techniques for translating a set of very straightforward algebriac rules, to another set. Anytime you write regexes or XPath to extract a set of fields from a documents and transform to something "readable", you're almost writing a simple one pass assembler, using some implicit "business rules" (i.e. all numbers should be floats, names capitalized, etc.) for productions.<p>Compiler skills will give you the theoretical backbone to discover, refine and assess those implicit rules. Not to mention techniques for transforming them from one form to another.<p>To the list of skills made mystical and magical by people I would add Lisp. It's not magic. I mention it because it just so happens to have compiler construction lore aplenty.<p>The first Lisp exercises you will read in your lisp book of choice (often requiring nothing more than basic English literacy and 6th grade arithmetic) are the expression simplification and evaluation exercises. Transforming your elementary school algebra rules (multiplication and division before addition and subtraction, etc.) to something the machine can execute. The hardest part is just understanding the words: if you have a hunch for what "expression", "term", "rule", "left/right hand-side" and "precedence" might mean, you're good to start.<p>Few chapters of a Lisp book will spare you volumes of traditional compiler construction techniques, taught by rote methods.<p>The first time I attempted to read SICP I had convulsions and physical pain. The whole time I had this inferiority complex nagging at me, telling me this was something for "smart kids" and I was unworthy. But this stopped after I went through the first few parts of chapter 1, and took in the playful tone the text. I felt stupid afterward; like being afraid of a St. Bernard. It looks big, but it's actually bubbly.<p>Don't listen to people when they say something is difficult or not for the faint of heart. Put a saddle on Falkor and go flying!

The logic Steve uses, while true, fails to appreciate the benefit of selective ignorance.<p>It's possible to reason effectively about a system without understanding the turtles all the way down, as long as you understand the limitations of the abstraction you are reasoning in, which is possible to do w/o dissecting turtles.<p>I'd further argue that the "scientist vs engineer" personality distinction is applicable here. The scientist is concerned with solving the primary problem, while the engineer is concerned with optimizing all the turtles.<p>Take a physicist using Mathematica... does she need to know how compilers work to effectively do cutting edge work with the tool? No. So why is any other programming langage any different (unless you're amused by dissecting turtles).

If you're interested in improving your skills and you read HN a lot, you're probably saying to yourself: 1. I wish I could improve my Lisp and 2. I wish I knew more about compilers.<p>Read Norvig's "Paradigms of Artificial Intelligence Programming." It proceeds through various early AI problems, which are good motivation. It shows how to solve some of them directly, then moves on to solving them with interpreters for DSLs, and finally shows how to speed up those solutions through compilation. The problem-specific portion of the code gradually gets smaller, more powerful, and faster.

I've been thinking about a compiler for Lisp/ML like functional languages. If we take the source program, convert it to continuation passing style, then lambda lift, we have an intermediate form where no closures appear, every call is a tail call and where the stack is represented as data structures explicitly. The next step is to convert every call site<p><pre><code> f(x) </code></pre> into<p><pre><code> if(f == FUNCTION1) FUNCTION1(x) else if(f == FUNCTION2) FUNCTION2(x) ... </code></pre> The reason for doing this is that now all function calls are to known functions (there are no calls to function pointers anymore). Because all calls are tail calls we can then convert every call to a jump instruction.<p>(note that this could cause code blowup with a lot of different functions and call sites, so it would probably be better to do this transformation lazily as you analyse what values f could take, and only actually do this transformation if you know that f can take at most 10 different values)<p>What we have now is one giant control flow graph (state machine) representing the entire program. All functions have been eliminated. The only thing left is primitive operations and jumps.<p>Why do I think that such a representation is interesting for a compiler? Because many things that previously had to be coded separately are now one analysis/transformation. Because there are no functions left all analysis and transformations automatically become interprocedural. And for example (loop) unrolling and inlining become the same transformation. So this could possibly make the compiler much simpler.<p>Could something like this work?

I like Steve's PL posts a lot, but I don't understand why he has to hate on static type systems so much. I appreciate and use both dynamic and static languages all the time, and both have their own respective strengths and weaknesses. There are some problems for which a static type system is extremely helpful, and others where no type system can really express the problem well. To say that a whole active branch of CS that affects the most popular languages in current use is worthless is a little presumptuous of him.

Work all the demonstrations and exercises in Kernighan and Pike's Chapter 8 of "The Unix Programming Environment". Less than 60 pages in a friendly large font. You'll be glad you did.

I'm no programmer, barely a web developer, and have no idea what he's talking about half the time. But jeeze this man can write.<p>I should go learn about compilers. Or improve my typing.

I've spent 20 years working on various compilers, yet I still don't think it's a big deal. Undergrads just need to work on any type of large systems project: OS, compilers, distributed systems, DBs, whatever. The problem with the compilers/programming languages field is that every idiot with a computer has an opinion. It's frustrating that popular languages are arguing about features that have been analyzed in depth 20+ years ago, e.g. closures really are the greatest thing ever and should be in any modern language.

(2007) should be added to the submission title.

I certainly agree that learning to type is the most important skill in programming. It saves you a few milliseconds every time you type anything, which adds up over thousands of keystrokes into a clear competitive advantage. And unlike compiler design, learning to touch-type is easy.

As a programmer who didn't take the compiler class in school, what's the best way to go about learning what it takes to write one? A book recommendation? Find a CS dept nearby and take the class?

Read this article a couple years ago and recognized it. The best part of it to remember:<p>&#60;&#60;A good friend of mine with a Ph.D. in languages told me recently that it's "very painful" to experience the realization that all those years of slaving over beautiful mathematical purity have more or less zero bearing on the real world.&#62;&#62;

Compiler class was the most fun class I had back in school, though there were a number of things I didn't understand and skimmed over. It was only years late that I re-read the Dragon book in depth that I understood some of the topics. Too bad there aren't too many language or compiler jobs.

Many things in software world are built on abstraction. It's not really possible to know it all and many times it is counter productive to get into any project with a mind set of I have to understand everything here.

I want to write a compiler that can take a Steve Yegge post as input and compile it down to a compact, concise form more readily executable by my brain.

His part about rails made laugh out loud.<p>I get the feeling Steve is teasing us with his magical vaporware just for laughs.

Turns out to be a good PR to taking a course on Compilers on faculty. I'm sold, I'll sign up for it.

I think a better title for this article would be "How monstrosities get written".

A large part of the problem is people only see the skills for compiler design being useful for compilers. If they would start with something simple they could avoid the compiler design class and write better code by using things like ANTLR from the start. The next time your program consumes text input try writing a grammar for it and processing the AST instead of half baking it with a regex.

Well as a physicst I say you can't understand a computer unless you understand the wavefunction of an electron crossing a potential barrier. So ner-ner-ni-ner-ner.....