131–140 of 162 posts
Earlier quoted context omitted.
Same opinion. I always recommend it to my programming students. Also, The Pragmatic Programmer is good, for topics both about programming and beyond programming per se.
A lot if the advice in these books has become widely accepted, so if you might not find that much new in them if you've already worked at a tech company for a bit.
SICP (w/ Brian Harvey's CS61A lectures) influenced how I approach abstraction _a lot_. Its "baby brother" _How to Design Programs_, with its design recipe approach, ingrained testing and iterative refinement in me early on. _Head First Design Patterns_ is a great influence too when it comes to OO-abstraction, for good and bad.
Earlier quoted context omitted.
> Design patterns exist because common solutions to problems exist, not because OO has serious problems Implementation-recipe design patterns only need to exist (or, rather, only need to be part of the active, day-to-day awareness of more than a small number of programmers per language) when the target language does not support implementing the common solutions as reusable code modules because doing so would require…
Can you provide an example of how a language like C++ or Java would require a "design pattern" when another language wouldn't?
Earlier quoted context omitted.
Design patterns exist because common solutions to problems exist, not because OO has serious problems. I understand both paradigms and Lisp is hardly free of design patterns. Every time you pass a lambda to a higher order function you're using a strategy pattern. If you only see design patterns as problems with OO, you're missing the point of design patterns. All languages have design patterns. Common design pattern…
Here's some old school thought leadership on dynamic languages and design patterns using actual data. Specifically Peter Norvig looked at all the examples in books like Design Patterns and found that: 16 of 23 patterns are either invisible or simpler, due to [...] http://norvig.com/design-patterns/design-patterns.pdf
Earlier quoted context omitted.
Are Design Patterns really so out of fashion with the youth of today that nobody here mentions Design Patterns as their answer? Because it is mine, for better or worse. It took me from understanding OO to understanding how to build large systems with OO, writing maintainable code and using proper encapsulation. A much deeper work than Code Complete (though the latter is worth reading too). I have used functional lang…
I'm nearing 50 so I'm hardly a youth. http://www.perlmonks.org/?node_id=133399 does a very good job of explaining why Design Patterns is a book to be careful with. By contrast Code Complete won't steer people wrong. See https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo... for a cautionary tale about how a pursuit of OO purity can result in great verbosity, hiding intent behind a barrage of patterns. Result…
Earlier quoted context omitted.
Design patterns exist because common solutions to problems exist, not because OO has serious problems. I understand both paradigms and Lisp is hardly free of design patterns. Every time you pass a lambda to a higher order function you're using a strategy pattern. If you only see design patterns as problems with OO, you're missing the point of design patterns. All languages have design patterns. Common design pattern…
Design Patterns is about typing out boilerplate code by hand to solve a problem, because the language doesn't have the expressivity to encode the same solution directly. When it does have the expressivity, the underlying rendering of the pattern hasn't gone away; just the manual boiler-plate for producing it. For instance, if you're working in assembly language, then you might sometimes benefit from a "while loop des…
True but equally sad that you must use Lisp to hide ugly Lisp because naked lambda's are so ugly. Yet the point remains, whether hidden behind a macro or not, design patterns still exist in Lisp and every other language and always will.
Earlier quoted context omitted.
Design patterns exist because common solutions to problems exist, not because OO has serious problems. I understand both paradigms and Lisp is hardly free of design patterns. Every time you pass a lambda to a higher order function you're using a strategy pattern. If you only see design patterns as problems with OO, you're missing the point of design patterns. All languages have design patterns. Common design pattern…
That's true. I think the GP's point was probably that some GoF patterns, specifically, just exist to work around language deficiencies. My go-to example for that is the visitor pattern; something that's trivial in Haskell or Lisp is ridiculously heavyweight in C++ or Java.
Earlier quoted context omitted.
Design patterns exist because common solutions to problems exist, not because OO has serious problems. I understand both paradigms and Lisp is hardly free of design patterns. Every time you pass a lambda to a higher order function you're using a strategy pattern. If you only see design patterns as problems with OO, you're missing the point of design patterns. All languages have design patterns. Common design pattern…
> Design patterns exist because common solutions to problems exist, not because OO has serious problems Implementation-recipe design patterns only need to exist (or, rather, only need to be part of the active, day-to-day awareness of more than a small number of programmers per language) when the target language does not support implementing the common solutions as reusable code modules because doing so would require…
False. Lisp has macro's and can abstract anything syntactically, yet still has commonly recurring design patterns such as with-X macros. You misunderstand what a design pattern is if you think new language features can remove the need for them.