On Wed, Feb 8, 2012 at 12:48 PM, Paul M Foster <paulf@xxxxxxxxxxxxxxxxx> wrote: > Um, yeah. It's very "meta". > > (That's what I love about "The C Programming Language". It's a little > over half an inch thick in paperback, explains the whole language > clearly and concisely, and has barely been revised since 1988. I'm not > sure you could ask for more in a technical book.) "The C Programming Language" is an exemplary language book -- it's well-laid-out, and you can pick it up as a complete novice and end up with enough of a grounding to get you going. I don't share quite your level of distaste for Design Patterns, or the GoF book. I found it pretty useful to read through, and was introduced to some interesting ways of solving problems I had seen before. Minus Singleton ;) I also found reading through the first part of the book to be pretty enlightening. It's more than possible that a lot of the benefit that I got from the book came from the experience-level I was at when I read it -- I hadn't worked on any systems that I couldn't fit entirely in my head at the time. Most of the problems I've had with code that "uses" design patterns have been with code where the authors used the patterns in a prescriptive manner -- like they were looking for ways to fit their problem into a neat architecture that they didn't need and didn't understand. I don't think they were (or are) meant to be used in that manner, they're supposed to be part of a shared language for high-level patterns used to solve particular families of architecture issues when they're needed. Letting the existing names and implementations and suggested use-cases of design patterns dictate your codebase is a recipe for disaster. I also happen to agree with the idea that the existence of design patterns can be a language-deficiency smell, but hey, we don't always get to work with the languages we prefer to work with. Anyhow, that's my two cents. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
