12 ms·

I don't agree with the blog post since the same argument could be made for any design pattern. There is nothing wrong at trying to understand things at a higher

by Scea91 12y ago

I don't agree with the blog post since the same argument could be made for any design pattern. There is nothing wrong at trying to understand things at a higher level of abstraction.

stormbrew 12y ago
Well, sure. But reading the GoF book as your introduction to programming wouldn't exactly be all that useful. Once you've actually experienced some programming and seen the patterns live and breathe it becomes a much more useful book. Likewise, if you've never actually worked with monads the high level explanations aren't terribly useful.
kqr 12y ago
I'm probably one of those rare programmers who has never had any real experience with OOP. I can tell you that reading about design patterns makes my head spin. I've been able to understand a few design patterns, but that has been because I've had an actual, practical problem in my code and the design pattern could be applied to solve it. Take as an example the following paragraph from Wikipedia: > The essence of the Mediator Pattern is to "define an object that encapsulates how a set of objects interact". It promotes loose coupling by keeping objects from referring to each other explicitly, and it allows their interaction to be varied independently. Client classes can use the mediator to send messages to other clients, and can receive messages from other clients via an event on the mediator class. I have no idea what that means and how and when I apply it in practise. It's just a bunch of abstract mumbo-jumbo, like an explanation of "what a monad is" will be. So I still hold that the abstract description comes after you learn how to use the thing, not before it.
- NateDad 12y ago
  FWIW, I have done a ton of OOP experience, and I have trouble understanding most descriptions of design patterns. One you see them implemented, you generally think, oh, well, duh, I've done that before. I think the main problem is that most programmers are terrible at explaining things, and should just stick to code examples, because they're usually a lot easier for other programmers to understand.

by Scea91 12y ago

I don't agree with the blog post since the same argument could be made for any design pattern. There is nothing wrong at trying to understand things at a higher level of abstraction.

stormbrew 12y ago

Well, sure. But reading the GoF book as your introduction to programming wouldn't exactly be all that useful. Once you've actually experienced some programming and seen the patterns live and breathe it becomes a much more useful book. Likewise, if you've never actually worked with monads the high level explanations aren't terribly useful.

kqr 12y ago

I'm probably one of those rare programmers who has never had any real experience with OOP. I can tell you that reading about design patterns makes my head spin. I've been able to understand a few design patterns, but that has been because I've had an actual, practical problem in my code and the design pattern could be applied to solve it. Take as an example the following paragraph from Wikipedia: > The essence of the Mediator Pattern is to "define an object that encapsulates how a set of objects interact". It promotes loose coupling by keeping objects from referring to each other explicitly, and it allows their interaction to be varied independently. Client classes can use the mediator to send messages to other clients, and can receive messages from other clients via an event on the mediator class. I have no idea what that means and how and when I apply it in practise. It's just a bunch of abstract mumbo-jumbo, like an explanation of "what a monad is" will be. So I still hold that the abstract description comes after you learn how to use the thing, not before it.

NateDad 12y ago
FWIW, I have done a ton of OOP experience, and I have trouble understanding most descriptions of design patterns. One you see them implemented, you generally think, oh, well, duh, I've done that before. I think the main problem is that most programmers are terrible at explaining things, and should just stick to code examples, because they're usually a lot easier for other programmers to understand.