I think that all Nicolasse was saying is that in other languages, such as Ocaml and Lisp, "Design Patterns" is not an especially relevant book. I mean no offense at all, but it sounds like you aren't very familiar with these other types of languages to see why this is so. Correct me if I am wrong.
Peter Norvig, addressing this topic says, "Dynamic Languages have fewer language limitations. Less need for bookkeeping objects and classes. Less need to get around class-restricted design." (http://www.norvig.com/design-patterns/ppframe.htm) I also want to second some of the books that others have mentioned, and add my own: 1. "Code Complete" -- it's been a while since I read this one, but if we were hiring, I would make it a mandatory read. 2. "Pragmatic Programmer" -- great advice about automating everything you do, and why Actionscripters really need to learn an additional language. 3. "Structure and Interpretation of Computer Programs" -- videos based on the book here: http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/ -austin Austin Haas Pet Tomato, Inc. http://www.pettomato.com The Irrelevant Elephant wrote: > Nicolas Cannasse wrote: > <loads of stuff I didn't particularly agree with ;-)> > > I thought I'd try to thrash this out a little. I'm really still > learning about patterns and how to apply them to my software most > effectively, and whilst I can understand your queries; I can't fathom > the source of the belligerence. It's obvious that you aren't a big fan > of OO development, however I think you're a bit keen to "throw the baby > out with the water". Or maybe you're just bitter that few people here > are bothered with functional programming ;-) > > >>I don't know exactly what I should think about Design Patterns. It's >>true they're in general good solutions to model the problems in a >>classic OO language with inheritance, but they are not so much useful in >>other kind of languages (for exemple Functional ones). This is mainly >>due to the fact that OO creates its own set of problems that are only >>partly answered by using Design Patterns. > > > This is the kind of thing I'm talking about ;-) Of course any style of > development spawns it's own "problems" (for want of a better word); > however patterns are /not/ "a mechanism to circumvent problems caused by > OOP". I can only assume you haven't read /that/ much into patterns as > inheritance features much less than other techniques, composition for > example. > > >>The need for the programmer to constantly reuse these patterns create >>the "code bloat" pattern, also sometimes called the "Java disease" :) >>It's when your code grows faster in complexity and number of >>abstractions than it grows in number of features. > > > I guess you've had a bad experience then? Part of the trick to using > patterns effectively is also (a) deciding if you need to use a pattern > at all and (b) learning to apply patterns to particular "problems" in > your software (rather than blindly building your software around patterns). > > >>I guess that a better programming language should embed the most often >>used patterns so they become a lot more natural to use (for instance you >>will not have to learn them). > > > Maybe in some respects, but patterns aren't meant to be concrete > implementations. That's kinda the whole point. Obviously a > language/platform can provide support for certain patterns (for example, > providing support for the commonly used Observer/Observable pattern) - > but it would be wrong for a language to assume responsibility of the > implementation of patterns at large. > > >>However I still think that OO design patterns are useful since they can >>bring some common vocabulary and methology where before everybody was >>using its own way of encoding objects relationships. > > > Yes, this is indeed another reason patterns are useful. My business > partners are not developers; one is a designer and one is a > part-developer-mostly-designer - but we can (and do) talk using a common > vocabulary. Because we have also adapted the use of CRC cards > (http://c2.com/cgi/wiki?CrcCard) into our development process, we can > also identify patterns whilst our cards are laid out on the floor, > before we even start cutting code. > > Horses for courses. > > _______________________________________________ > osflash mailing list > [email protected] > http://osflash.org/mailman/listinfo/osflash_osflash.org > _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
