4 ms·

If you have barely touched code in 6 months, you are not a programmer. Moreover, if you haven't bothered to learn design patterns, you probably never were.

dinkumthinkum 13y ago
Something about this bothers me. Let's say Donald Knuth hasn't coded in a year, maybe's he's been busy with this and that ... You consider him not a programmer ... maybe that is too obvious and example but also design patterns ... I have hard time accepting that as well ... I would agree there is something anti-intellectual in being dogmatic against learning them ... but I suppose on some level it depends on what you mean. This can be a contentious topic; are you saying that if you are not friar in the mission of the Gang of Four that you are not a programmer?
- randomapathy 13y ago
  In my attempt at brevity I fear I lost some context. I do however firmly stand by if you are not actively coding, you are not a programmer. What the exact timeline is, I will gladly leave up for debate, but it's not like riding a bicycle - you lose ability over time. As for design patterns, I think we are in agreement (at least in principle) about their worth as a starting point. I am not at all saying that GoF (or any other design pattern text) should be followed. Rather, that anyone seriously considering themselves a programmer should have an understanding of the design patterns that are pertinent to their language/methodology, and hopefully their own opinions on which make sense or not. I likely have too high of a standard for the term programmer, but feel it has been steadily lowered by this type of talk and wanted to at least try to move the bar back up.
  - vacri 13y ago
    but it's not like riding a bicycle Interesting tidbit on this concept. When I was 17 I had a cycling accident where I flew over a car and landed on my hip quite badly. I gave up the bike for ten years (wasn't a huge fan anyway), then eventually thought I better get a bike again. So after not riding for ten years, I had a bike out on a test ride in a side street, and on that first-ride-in-ten-years, I was riding quite happily hands-free. There really is something to not forgetting how to balance on a bike. I decided not to push my luck and resumed a normal pose before I reached the speed bump though...
rayiner 13y ago
Design patterns are weaknesses in the design of programming languages: http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatu...
justinpombrio 13y ago
So, I occasionally hear someone espouse the utility of design patterns. As a Haskellite, I tend not to see the point, and wonder sometimes whether they're all just kludges to, e.g., work around not having first class functions. I've actually written more Java than Haskell, and have taken a (not great) class on design patterns, so I'm aware of these concepts; I'm just yet to see the point. Is there a good explanation of design patterns conducive to a "functional" programmer's point of view? Most importantly, one that doesn't motivate the problem in terms of objects? (Objects in the solution are fine, but if the problem only arises when you use objects I might as well go back to Haskell.) The one pattern I know holds its water is the Visitor pattern.
- nbouscal 13y ago
  I think the observer pattern can be useful as well (though there are definitely alternatives), but for the most part you're right. Factory pattern et al exist to solve problems that are introduced by OO. Get rid of OO and you no longer need to solve those problems, though of course you do still have to solve the problems that OO was introduced to solve in the first place.
- foobarbazqux 13y ago
  Visitor is just a kludge for multiple dispatch.
- tptacek 13y ago
  Yes, you're looking for Norvig's "design patterns in high level languages" presentation, here: http://norvig.com/design-patterns/ http://norvig.com/design-patterns/ Fair warning: it reiterates Rayiner's point upthread.
  - justinpombrio 13y ago
    That is precisely what I was looking for (and from Norvig, no less). Thanks!

dinkumthinkum 13y ago

Something about this bothers me. Let's say Donald Knuth hasn't coded in a year, maybe's he's been busy with this and that ... You consider him not a programmer ... maybe that is too obvious and example but also design patterns ... I have hard time accepting that as well ... I would agree there is something anti-intellectual in being dogmatic against learning them ... but I suppose on some level it depends on what you mean. This can be a contentious topic; are you saying that if you are not friar in the mission of the Gang of Four that you are not a programmer?

randomapathy 13y ago
In my attempt at brevity I fear I lost some context. I do however firmly stand by if you are not actively coding, you are not a programmer. What the exact timeline is, I will gladly leave up for debate, but it's not like riding a bicycle - you lose ability over time. As for design patterns, I think we are in agreement (at least in principle) about their worth as a starting point. I am not at all saying that GoF (or any other design pattern text) should be followed. Rather, that anyone seriously considering themselves a programmer should have an understanding of the design patterns that are pertinent to their language/methodology, and hopefully their own opinions on which make sense or not. I likely have too high of a standard for the term programmer, but feel it has been steadily lowered by this type of talk and wanted to at least try to move the bar back up.
- vacri 13y ago
  but it's not like riding a bicycle Interesting tidbit on this concept. When I was 17 I had a cycling accident where I flew over a car and landed on my hip quite badly. I gave up the bike for ten years (wasn't a huge fan anyway), then eventually thought I better get a bike again. So after not riding for ten years, I had a bike out on a test ride in a side street, and on that first-ride-in-ten-years, I was riding quite happily hands-free. There really is something to not forgetting how to balance on a bike. I decided not to push my luck and resumed a normal pose before I reached the speed bump though...

rayiner 13y ago

Design patterns are weaknesses in the design of programming languages: http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatu...

justinpombrio 13y ago

So, I occasionally hear someone espouse the utility of design patterns. As a Haskellite, I tend not to see the point, and wonder sometimes whether they're all just kludges to, e.g., work around not having first class functions. I've actually written more Java than Haskell, and have taken a (not great) class on design patterns, so I'm aware of these concepts; I'm just yet to see the point. Is there a good explanation of design patterns conducive to a "functional" programmer's point of view? Most importantly, one that doesn't motivate the problem in terms of objects? (Objects in the solution are fine, but if the problem only arises when you use objects I might as well go back to Haskell.) The one pattern I know holds its water is the Visitor pattern.

nbouscal 13y ago
I think the observer pattern can be useful as well (though there are definitely alternatives), but for the most part you're right. Factory pattern et al exist to solve problems that are introduced by OO. Get rid of OO and you no longer need to solve those problems, though of course you do still have to solve the problems that OO was introduced to solve in the first place.
foobarbazqux 13y ago
Visitor is just a kludge for multiple dispatch.
tptacek 13y ago
Yes, you're looking for Norvig's "design patterns in high level languages" presentation, here: http://norvig.com/design-patterns/ http://norvig.com/design-patterns/ Fair warning: it reiterates Rayiner's point upthread.
- justinpombrio 13y ago
  That is precisely what I was looking for (and from Norvig, no less). Thanks!