3 ms·
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 j
by 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 agoI 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 agoVisitor is just a kludge for multiple dispatch.
- tptacek 13y agoYes, 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 agoThat is precisely what I was looking for (and from Norvig, no less). Thanks!