Steve Yegge's review of Design Patterns: Elements of Reusable Object-Oriented Software

This book was incredible. When it came out in early 1995, it offered a set of 23 little reprieves from the blind, crawling, Lovecraftian madness of C++ programming. (Ever notice how "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn" and "Protected abstract virtual typedef'd copy constructor function" sound identical underwater? Yup. The Elder Gods are lumbering and gibbering around Redmond right now.)

Well, it was 22 reprieves, really, since the Interpreter pattern was put in there as sort of an in-joke. 1994, the year the book was being prepared, was in fact the 40th anniversary of John Backus's 1954 observation that most programmers detested the idea of a "compiler":

At that time, most programmers wrote symbolic machine instructions exclusively (some even used absolute octal or decimal machine instructions). Almost to a man, they firmly believed that any mechanical coding method would fail to apply that versatile ingenuity which each programmer felt he possessed and constantly needed in his work. Therefore, it was agreed, compilers could only turn out code which would be intolerably less efficient than human coding..."   [John Backus in the 1954 Fortran report]

So true! Compilers are for sissies. Just ask anyone from Geoworks, if you can find anyone left now that they've gone out of business. We all wrote everything in assembly language; it's obvious that computer time is more expensive than programmer time, and good programmers can hand-generate code that outperforms anything any compiler can generate. If-statements and for-loops were for pansies. We had "jcxz" and that was enough.

Most of the programming world who believed that you should write everything in assembly language have moved on (that's a euphemism for "died".) Their children and grandchildren today (that's you!) realize that, well, compilers are pretty important. We'll begrudge them their place. But programmers today firmly believe that any Interpreted coding method such as Java or Ruby fails to apply that versatile ingenuity which each programmer feels he/she possesses and constantly needs in his/her work, etc.

The authors of Design Patterns thought this was pretty funny. The machines change; the languages change, but people don't change. So they threw in the Interpreter pattern as a sort of practical joke, a gag that no real programmers with hairs on their chests would actually understand, let alone agree with.

Other than that, the book was great!

Ref: https://sites.google.com/site/steveyegge2/ten-great-books