Having enjoyed SICP immensely and craving a good book on “advanced” programming techniques to hone my skills, I really wanted to like this book, but I too came away from it disappointed.
Like OP says, the code examples can be glossed over because they fail to really illuminate the reason behind doing things this way, and they’re even incomplete - major chunks of implementation are not in the book (but presumably they are part of the downloadable package - I didn’t care enough to download it). The parts that are in the books are simply rather tedious to read through as well. And they are overly mathy/physics-oriented (like some of the worse parts of SICP) which doesn’t really fit with daily practice of most software engineers.
Most of the techniques in the book are useful in a variety of situations, granted. But, like OP indicates, most of these you’ve probably already encountered as features in a programming language or in an ad-hoc implementation for a project. Or you may even have invented some of them independently by yourself. There’s nothing really new here.
Finally, I’m not so sure these techniques will help you prevent painting yourself into a corner - in fact, overuse of these techniques will lead to an inscrutable mess of code. There’s a certain type of disconnect in your code when you make things “extensible” at any point. This will completely obscure the flow of control, making it harder to understand what’s going on and harder to pinpoint the source of a bug. With multiple “layers” contributing to a final result, the bug could be in a layer, or even in the resulting interplay between the layers. Thankfully, the authors do warn for this, but not enough IMO.
in fact, overuse of these techniques will lead to an inscrutable mess of code.
Very much so. I left a whole bunch of stuff out of the review going on about this. It’s mind-boggling that it is not addressed in the book that is ostensibly about “design”. I have implemented a few systems with extensibility and, at best, only a small number of users actually made use of them. For most, the abstractions were confusing. Dynamic/static typing makes no difference here: it can be a maze of macros or a tower of types. In either case, you’re probably going to end up with a mess.
It would be hard for me to agree more with the final paragraph. This book is full of powerful ideas, and yet I found it to be largely out-of-touch with the everyday practitioner. Shame that the authors couldn’t bridge the gap.
This was easily the most frustrating thing about the book. When I finished it, I thought about what Guy Steele said in the foreward, and the blurbs on the back from people like Rich Hickey and thought, “did these people actually read this?” Because it is simply not good, despite the fact the techniques are really good to know. (And Curtis Hanson spent a bunch of time working at Google, so there is certainly industry experience behind the authorship.)
Well, Guy L. Steele is probably a personal friend of the authors (with him having co-written the Lambda Papers with Sussman), and if a friend asks you to write a foreword to their book it’ll be hard to say no. And of course, you’re not gonna badmouth a book in the book’s foreword.
And Rich Hickey certainly likes the ideas in the book, as some of them (the ones he specifically calls out - metadata and dynamic dispatch) are built-ins in Clojure, and he’s big on an “additive” style of programming in general.
I think the book describes some great ideas, but should have gone through many more iterations to be a worthy successor to SICP. The expectations were simply too high.
I guess SICP, like many other great academic books, matured slowly by starting as some rough lecture notes and getting more polished year after year, before publication.
I enjoyed reading the book, but the code is presented out of order - functions are used before they are presented for the reader, so typing the code as you go doesn’t really work.
In any case, the techniques portrayed are beautiful.
Having enjoyed SICP immensely and craving a good book on “advanced” programming techniques to hone my skills, I really wanted to like this book, but I too came away from it disappointed.
Like OP says, the code examples can be glossed over because they fail to really illuminate the reason behind doing things this way, and they’re even incomplete - major chunks of implementation are not in the book (but presumably they are part of the downloadable package - I didn’t care enough to download it). The parts that are in the books are simply rather tedious to read through as well. And they are overly mathy/physics-oriented (like some of the worse parts of SICP) which doesn’t really fit with daily practice of most software engineers.
Most of the techniques in the book are useful in a variety of situations, granted. But, like OP indicates, most of these you’ve probably already encountered as features in a programming language or in an ad-hoc implementation for a project. Or you may even have invented some of them independently by yourself. There’s nothing really new here.
Finally, I’m not so sure these techniques will help you prevent painting yourself into a corner - in fact, overuse of these techniques will lead to an inscrutable mess of code. There’s a certain type of disconnect in your code when you make things “extensible” at any point. This will completely obscure the flow of control, making it harder to understand what’s going on and harder to pinpoint the source of a bug. With multiple “layers” contributing to a final result, the bug could be in a layer, or even in the resulting interplay between the layers. Thankfully, the authors do warn for this, but not enough IMO.
Very much so. I left a whole bunch of stuff out of the review going on about this. It’s mind-boggling that it is not addressed in the book that is ostensibly about “design”. I have implemented a few systems with extensibility and, at best, only a small number of users actually made use of them. For most, the abstractions were confusing. Dynamic/static typing makes no difference here: it can be a maze of macros or a tower of types. In either case, you’re probably going to end up with a mess.
It would be hard for me to agree more with the final paragraph. This book is full of powerful ideas, and yet I found it to be largely out-of-touch with the everyday practitioner. Shame that the authors couldn’t bridge the gap.
This was easily the most frustrating thing about the book. When I finished it, I thought about what Guy Steele said in the foreward, and the blurbs on the back from people like Rich Hickey and thought, “did these people actually read this?” Because it is simply not good, despite the fact the techniques are really good to know. (And Curtis Hanson spent a bunch of time working at Google, so there is certainly industry experience behind the authorship.)
Well, Guy L. Steele is probably a personal friend of the authors (with him having co-written the Lambda Papers with Sussman), and if a friend asks you to write a foreword to their book it’ll be hard to say no. And of course, you’re not gonna badmouth a book in the book’s foreword.
And Rich Hickey certainly likes the ideas in the book, as some of them (the ones he specifically calls out - metadata and dynamic dispatch) are built-ins in Clojure, and he’s big on an “additive” style of programming in general.
I think the book describes some great ideas, but should have gone through many more iterations to be a worthy successor to SICP. The expectations were simply too high.
I guess SICP, like many other great academic books, matured slowly by starting as some rough lecture notes and getting more polished year after year, before publication.
I enjoyed reading the book, but the code is presented out of order - functions are used before they are presented for the reader, so typing the code as you go doesn’t really work.
In any case, the techniques portrayed are beautiful.