Some successful computer books have earned memorable nicknames. There is the "K&R" book, the "Gang of Four" book, and, to please generations of board and role game players, there are also the "Wizard Book", the "Dragon Book", and the "Dinosaur Book". There's the "Camel" book and the "Pickaxe" book. And then, with a decidedly more corporate look and feel, let us talk today about the "Pink Shirt" book, officially titled "The Peter Norton Programmer's Guide to the IBM PC." More corporate, yes, because the PC was after all a business machine coming from a business corporation.
Kent Beck might deny that Kent Beck needs an entry in the programmers' library. "All I did was rediscover what other people had done before," he might say, or "all I did was to interpret what Ward Cunningham was doing." But that discovery, that reinterpretation, is the most important part of the process. One person doing things differently is an oddball. Two are the beginning of a revolution.
If you wanted to write a book about any subject related to computers, but not specifically about a particular programming language, which language would you choose? For example: if you wanted to teach programming concepts (algorithms, patterns) to an absolute beginner, which language would convey your thoughts better? Say, if you had to explain algorithms that could be implemented in any Turing-complete language, which one would you pick, and why?
Let's start at the end. The last sentence in "NeXTSTEP Programming Step One: Object-Oriented Applications" by Simson L. Garfinkel and Michael K. Mahoney looks like this: "Go out and write a killer app!" This is slightly punchier than the way the same authors signed off in "Building Cocoa Applications: A Step-by-Step Guide": "Now go out and write a killer application!"
Of all the articles I have written in this "Library" section, this has been by far the most difficult to write of them all. It is extremely hard to summarize in a thousand words the major achievements of a person that has defined the way our modern world and our industry work, in the most unfathomable ways.
It would of course be easy to single out authors who have made important contributions to the world of Free, Libre and Open Source Software for this month's Library article. I'm sure we'll address their work in later issues. One of the most important reasons for the success of Free Software is its collaborative nature so this month we'll acknowledge the community effort to document open source software.
The history of programming language books can be roughly divided in three distinctive eras. The first one stretches from the beginnings of programming to the mid 1970s. Programming books from those times were an often underestimated byproduct of the marketing budget of big companies such as IBM, and inherited the dry approach of most engineering books in the post-war era.
These days, it's hard to appreciate that Object-Oriented Programming is so easy, it was taught to kids in junior high before it was ever taught to adults. As supposedly senior software engineers debate whether a Car truly "is a" Vehicle, and whether it wouldn't be easier to learn lambda calculus and determine the median monad blog post than to reflect the real objects in the real-world problem they're solving in their software, it seems reasonable to ask: is it really so difficult?
From October 24th to 29th, 1927, twenty-nine scientists gathered in Brussels for the fifth Solvay Conference. Among the attendees, of which seventeen got a Nobel Prize before or after attending, were Erwin Schrödinger, Wolfgang Pauli, Werner Heisenberg, Paul Dirac, Louis de Broglie, Max Born, Niels Bohr, Max Planck, Marie Curie, Hendrik Lorentz, and Albert Einstein. One might think there might have not been such an assembly of brilliant thinkers since the Platonic Academy.
Many developers will have heard of Barbara Liskov, through her appearance in Robert C. Martin's SOLID list of design principles. The abstract of her 1994 paper with Jeanette Wing, A Behavioral Notion of Subtyping, makes the principle sound easy in, well, in principle.