I bought the new one, but haven't read it yet. Apologies to Nicolas for misspelling his name.
Also apologies to I. Elephant if questioning his knowledge came off bad. I think I was taking a shortcut rather than explaining myself. Mostly I was considering this comment: "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." It isn't an issue of embedding a particular pattern into a language as that pattern, but the language having a certain style that can avoid any need for that pattern in the first place. -austin Austin Haas Pet Tomato, Inc. http://www.pettomato.com Johannes Nel wrote: > code complete is prob one of the best books on design (not patterns) i > have ever read. is the latest version even better than the old one? > > On 11/10/05, *Austin Haas* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > 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] <mailto:[email protected]> > > http://osflash.org/mailman/listinfo/osflash_osflash.org > > > > _______________________________________________ > osflash mailing list > [email protected] <mailto:[email protected]> > http://osflash.org/mailman/listinfo/osflash_osflash.org > > > > > -- > j:pn > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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
