There was a time when I put a corporate seal on my favorite books. Dr. Stroustrup noticed the embossed seal, ran his fingers over it, and remarked "nice" as he signed my copy.
The book was published circa 1994, and Stroustrup was on hand to give a talk to an eager C++ user group.
While the book describes the early evolution of C++ -- the proposals, the decisions, the trade-offs, and the mistakes -- it is in the early sections where we learn most about the author. Stroustrup writes:
"It is often claimed that the structure of a system reflects the structure of the organization that created it. Within reason, I subscribe to that idea."
In my years of programming and working with management, I have found this to be very true. This was Stroustrup's way of saying the C++ language is largely shaped by who he is. While it's no surprise he has advanced degrees in mathematics and computer science, we learn that his hobbies include history and philosophy. Descr…
My first job had me programming in Microsoft BASIC for the IBM PC (DOS). BASIC worked well enough, but its limitations were clear. The language was interpreted and therefore slow. More importantly, it wasn't a modern structured language, and instead, relied on line numbers and the GOTO statement. Anyone who has read Dijkstra knew GOTO was a bad thing.
Having learned a structured language in college (PL/I), using BASIC felt unnatural. When a C compiler became available for the PC, I saw a chance to improve and modernize our software. The problem was selling the idea -- a problem made harder because I wasn't fluent in C.
"It would be a staffing problem. Not many people know C, but we can find a lot of programmers who know BASIC," noted one manager.
The argument was strong as my knowledge of C was weak. But I knew that C, by design, was a small language and thus easy to learn. "It has about 30 keywords," I proffered to another manager.
Upon encountering various programming languages during my career, some appealed to me instantly, while others left me cold. I never really understood why, but perhaps by writing about them, I can discern a pattern.
PL/C: This was the first language I learned. Structured, imperative, and procedural, PL/C was Cornell's teaching variant of PL/1, and the language shaped much of my thinking. It was a good language, and I liked it, but it was also an academic language and one I would never see or use again.
Basic (IBM PC): It was hate at first sight. The language relied on line numbers, needed GOTOs, and was interpreted. But it was early in the PC days and I had to use it if I wanted to do anything useful. In time, Basic became a compiled language and eventually evolved into Visual Basic for Windows programmers. But even then, the first version of Visual Basic did not directly support arrays, an omission that convinced me that Basic would forever be a dumbed-down language.
After reviewing some books I considered classics¹, I wondered what tomes were popular nowadays. I was disappointed to learn the #1 best seller on Amazon, in the category of data structure and algorithms, was Cracking the Coding Interview.
Was this a direct result of raising students on "teaching to the test?" Were companies so confused about hiring, they needed to administer a programming puzzle to find a suitable candidate?
The reviews ranked Cracking the Coding Interview highly, and the contents were substantive, not fluff. Yet, glancing over to my bookshelf, I would want candidates to be acquainted with titles like these: More Programming Pearls by Jon Bentley, The Cathedral & The Bazaar by Eric S. Raymond, Algorithms in C by Robert Sedgewick, and a classic-to-be, Joel On Software by Joel Spolsky.
When software development was novel (circa 1980), a popular notion was that the skills required for programming were similar to the skills needed in music and chess. Fi…