3 ms·

To the weak of mind, perhaps. I believe that patterns are useful and beneficial in moderation. This requires a degree of understanding that some do not have,

by mullr 19y ago

To the weak of mind, perhaps. I believe that patterns are useful and beneficial in moderation. This requires a degree of understanding that some do not have, leading to pattern hell. The analogies to alcohol are disturbing.

thaumaturgy 19y ago
Admittedly, I haven't read the texts on design patterns, and have only a cursory knowledge of what they're about. So, I'm about to commit the cardinal sin of talking on a subject that I don't know intimately. Near as I can tell, design patterns are just ways of vaguely describing common solutions to common problems. They say, "You might try to solve problem X in some language by creating an object that does Y." In lieu of actually understanding the specific problem they're facing, the inexperienced or less skilled programmer then looks through their dictionary of design patterns, finds something that sounds like it fits, and then proceeds to throw some very generic code at their problem until it goes away. This strikes me as very similar to the problem Feynman discussed in "Surely You're Joking", when he worked as a professor in Brazil and came to realize that, on a national basis, the students had all been taught to memorize entire books of facts, but hadn't done experiments and didn't understand the concepts behind the things they were taught.
- Tichy 19y ago
  I recommend reading a text on design patterns. The Brazil example falls short, because people having no understandings of concepts doesn't invalidate the concepts themselves.
  - thaumaturgy 19y ago
    Design patterns are on my reading list, but these days that list is much larger than my available free time. I agree with you, actually. My point wasn't that the design patterns themselves are wrong, or necessarily bad, it was that (I think) they'll tend to get used in situations where the programmer doesn't understand the immediate problem or solution well enough to deal with it directly. Anecdotally, this came up somewhat recently when the question of whether or not it's "OK" to return early from a function got briefly passed around the net. I noticed a lot of instances where people were coming up with some pretty absurd reasoning to justify always doing it one particular way, the 'textbook' way if you will. Myself, I think it's _sometimes_ OK to return early from a function. It depends on what you're doing. You have to understand the situation you're looking at, and all of the various circumstances around it. So, the idea of "never return early from a function" isn't necessarily wrong, but it does indicate that the programmer probably doesn't really understand what they're doing.
    - Tichy 19y ago
      It's been a while that I read it, but I thought the original "Design Patterns" book was pretty good. You won't find something like the "return early from function" in it. I think it is best to read the original design patterns book, not the language specific clones (ie not "Design Patterns for Java" etc). Most patterns in the book are not that trivial, so I don't think you can apply them without understanding them (in general).

by mullr 19y ago

thaumaturgy 19y ago

Admittedly, I haven't read the texts on design patterns, and have only a cursory knowledge of what they're about. So, I'm about to commit the cardinal sin of talking on a subject that I don't know intimately. Near as I can tell, design patterns are just ways of vaguely describing common solutions to common problems. They say, "You might try to solve problem X in some language by creating an object that does Y." In lieu of actually understanding the specific problem they're facing, the inexperienced or less skilled programmer then looks through their dictionary of design patterns, finds something that sounds like it fits, and then proceeds to throw some very generic code at their problem until it goes away. This strikes me as very similar to the problem Feynman discussed in "Surely You're Joking", when he worked as a professor in Brazil and came to realize that, on a national basis, the students had all been taught to memorize entire books of facts, but hadn't done experiments and didn't understand the concepts behind the things they were taught.

Tichy 19y ago
I recommend reading a text on design patterns. The Brazil example falls short, because people having no understandings of concepts doesn't invalidate the concepts themselves.
- thaumaturgy 19y ago
  Design patterns are on my reading list, but these days that list is much larger than my available free time. I agree with you, actually. My point wasn't that the design patterns themselves are wrong, or necessarily bad, it was that (I think) they'll tend to get used in situations where the programmer doesn't understand the immediate problem or solution well enough to deal with it directly. Anecdotally, this came up somewhat recently when the question of whether or not it's "OK" to return early from a function got briefly passed around the net. I noticed a lot of instances where people were coming up with some pretty absurd reasoning to justify always doing it one particular way, the 'textbook' way if you will. Myself, I think it's _sometimes_ OK to return early from a function. It depends on what you're doing. You have to understand the situation you're looking at, and all of the various circumstances around it. So, the idea of "never return early from a function" isn't necessarily wrong, but it does indicate that the programmer probably doesn't really understand what they're doing.
  - Tichy 19y ago
    It's been a while that I read it, but I thought the original "Design Patterns" book was pretty good. You won't find something like the "return early from function" in it. I think it is best to read the original design patterns book, not the language specific clones (ie not "Design Patterns for Java" etc). Most patterns in the book are not that trivial, so I don't think you can apply them without understanding them (in general).