On 11/10/05, Austin Haas <[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]
> http://osflash.org/mailman/listinfo/osflash_osflash.org
>
_______________________________________________
osflash mailing list
[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
