Tech Book Face Off: The New Turing Omnibus Vs. Patterns of Software
I'm churning through tech books now, finishing off a bunch that I had started a while back, but couldn't find the time to finish until now. The pair that I'll look at here are a couple of older books that I picked up through recommendations on blog posts. The first one, The New Turing Omnibus: 66 Excursions in Computer Science by A.K. Dewdney, is a survey of 66 topics in a wide range of areas of Computer Science. The second book, Patterns of Software by Richard P. Gabriel, is about advice and experiences on a variety of topics in software development. Whereas NTO is of a strictly technical nature, Patterns of Software has much more of the human aspect of working with computers and software. Let's see how these older books hold up today.
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:
 | 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)
The miscellany chapters could honestly been grouped into the other categories, and the three computer graphics chapters were just as much algorithms or data structures as anything, so nine categories would have been sufficient. That's fairly inconsequential, though, because the topics were presented completely haphazardly anyway. The chapters would go from Karnaugh Maps to the Newton-Raphson Method of finding roots to minimum spanning trees without any ceremony whatsoever, leaving the reader grappling for a solid structure to hold on to.
Each chapter is a brief 5-7 page discussion on the given topic followed by two or three problems related to the topic as practice for the reader. These problems commonly explored points glossed over in the text. The topic discussions read like blog posts and don't give more than a cursory introduction to the sometimes deep and complex subjects they are covering.
I had high hopes for this book, considering the glowing recommendation that Jeff Atwood gave it back in 2007 on Coding Horror, but I just couldn't get into it the way he did. I found the treatment of the topics that I had already learned in much more depth, mostly from studying in college, to be tedious and unremarkable. The remaining 25% of the topics, mostly on the theory of computation and automata, was quite difficult to understand from the short expositions given, and I would have to do more extended studying with a book like the Introduction to the Theory of Computation to get enough of a handle on the subject to answer the more difficult end-of-chapter problems.
I may not have been the right audience for this book, but I had a lot of trouble figuring out who the right audience would be. The material was so superficial that I didn't find any additional insights or valuable practice from any topics I already knew about, and those topics that I had little exposure until now were nearly completely opaque from the text. It was weird. The book didn't seem to fit for either a novice or a (moderate) expert on any of the topics, and the fact that related topics were strewn throughout the book, separated by completely unrelated topics, made it even more frustrating and less helpful. Maybe if you were using it as a supplement while studying some of the broader subjects for extra practice, it would prove to be of some use, but I'm not even convinced of that. I have to give this book a solid "no" at this point. There are much better books out there on the subject areas covered here.
Patterns of Software
This was an odd book, and not at all what I expected. I had expected a book relating advice to the reader on how to design and develop software. What it is instead is an extended comparison of Christopher Alexander's work on patterns in architecture to patterns in programming followed by speculations on programming languages, advice on learning to become a good writer, and a significant part of Richard P. Gabriel's life story. It was a strange mishmash of things that didn't quite hold together as a cohesive book.
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
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.
We must be careful to strike the right balance when coding so that we don't unnecessarily obscure things that should be simple and easy to understand just for the sake of abstraction. Sometimes it's better to lay out a process linearly so that it can all fit on the screen at the same time instead of slicing and dicing to the point where the poor sap who has to debug the code needs to chase the flow of execution through dozens of functions and variables across tens of files. This insight gets at one of the themes of the book on making code habitable:
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.
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.
0 Response to "Tech Book Face Off: The New Turing Omnibus Vs. Patterns of Software"
Post a Comment