![]() | VS. | ![]() |
The New Turing Omnibus
With the new edition published in 1993, this is definitely an older computer science book. That can be okay, if the author sticks to the more timeless aspects of computer and software design. For the most part, this is the case in NTO, but a few of the chapters—especially the ones on VLSI computers and disk operating systems—are definitely dated and nearly beyond usefulness. The topics vary far and wide, though, and are generally grouped into eleven subject areas with the following breakdown:
- Analysis of Algorithms (8)
- Applications (7)
- Artificial Intelligence (5)
- Coding and Cryptology (3)
- Complexity Theory (6)
- Computer Graphics (3)
- Data Structures (6)
- Automata and Languages (5)
- Logic and Systems Design (9)
- Theory of Computation (9)
- Miscellany (5)
Patterns of Software
Throughout the first part on how Alexander's books—the most well-known being A Pattern Language—relate to programming, Gabriel quotes Alexander extensively, to the point where I almost felt like I was reading Alexander more than Gabriel. He also did not spend enough time tying all of these quotes into programming and software, so much of the time I was left wondering if the book was just a review of Alexander's works.
Gabriel did have some insights into programming that resonated well, such as
Maintaining compressed code requires understanding its context, which can be difficult. The primary feature for easy maintenance is locality: Locality is that characteristic of source code that enables a programmer to understand that source by looking at only a small portion of it. Compressed code doesn't have this property, unless you are using a very fancy programming environment.
Habitability is the characteristic of source code that enables programmers, coders, bug-fixers, and people coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently.This idea of habitability is a worthy goal, and Gabriel returns to it often in the context of Alexander's architecture patterns:
What Alexander seems to be saying is that if we try to use modular parts (solid building blocks not easily molded to the current circumstances), then the overall structure of the thing built with them may become overly constrained by their shape. In programming, if a set of large abstractions does nearly the right thing, it is tempting is [sic] to use them and to bend the structure of the surrounding program to fit them. This can lead to uninhabitable programs.It seems like much of modern software development has become exactly this, where we as programmers have been reduced to searching for and slapping together all of the packages we need to meet the given software requirements. In this process of moving towards extreme reuse, something has been lost in software development, and this is speaking from a perspective more than twenty years after this book was written, with reuse being much more common and extensive than it was then. This thing that has been lost is Alexander's "quality without a name."
Both Alexander and Gabriel spent a lot of time trying to define this quality without a name, but neither succeeded very well. Gabriel critiqued Alexander's choices in descriptive words, like "simple" and "cohesive," but while he was right that the word choices did not do the concept justice, he did not do much better in clarifying what the quality was. Even more troublesome than defining it, Alexander found that he couldn't replicate this nameless quality by enumerating the patterns of architecture. It's not something that you can create simply by combining known good patterns in a building.
This difficulty of codifying quality is true for almost anything we do. It's as true for architecture as it is for programming as it is for every form of craftsmanship, and it seems obvious that this would be so. We can't package up and mass produce quality that simultaneously exhibits beauty, elegance, efficiency, and function. Reaching the point where you can produce things of such a high level of quality takes decades of experience, creativity and experimentation. Most people will never reach the level of craftsmanship where their work is elevated to an art form.
It was frustrating that Gabriel danced around that conclusion for most of the book, but never really committed to it. He did spend a fair amount of time on silly tangents, like the chapter where he claimed that the development of programming languages was at an end, and C was the ultimate answer. That prediction looks mighty short-sighted today.
The rest of the book, detailing Gabriel's struggles through college and running a software business, was sometimes interesting and sometimes not, but it didn't have much to do with the first half of the book on patterns and code habitability. In general, his writing was quite repetitive and disorganized. He would introduce a new topic or part of a story by giving away the conclusion as if it was a stand-alone statement, and then proceed into an extended discussion on it. A few pages later I would realize he was talking about the details of a story that I had thought was just an isolated observation and we had moved on. This writing style was quite disorienting, and the constant repetition of certain observations or narratives, each time stated as if it was the first, became fairly annoying.
Between the sparse real insights and disjointed structure of the book, I can't recommend Patterns of Software at all. The software development advice can easily be had in much better books without the extended and largely irrelevant fluff. It's unfortunate. I feel like I really struck out with this book and The New Turing Omnibus, but sometimes that happens. Maybe the next couple books I read will be much better.