Is there a functional-programming equivalent to the Gang of Four Design Patterns book? That is, is there a book that explains and gives examples of how commonly-needed code structures are implemented functionally? I think seeing that would give me a better idea of how to go about using in practice the functional concepts whose theory I understand.
+4
A:
The patterns movement started because object-oriented programming was often turning into "spaghetti objects" : a confusing maze of twisty little interacting objects that looked all the same. Patterns were an attempt to restrict the chaos into a set of known channels -- kind of like what Structured Programming did for procedural programming: reject arbitrary gotos and branches for a restricted set of well behaved control structures.
Functional programming doesn't have this problem. There's already a pretty small set of functional patterns that are usually built into functional languages: map, apply, reduce, recursion, etc., and are covered in any book on functional programming. Functional programming IS a restricted style of programming, so it didn't need to grow a set of restricted conventions to limit the chaos.
Steven D. Majewski
2010-05-28 15:49:55
Design Patterns sorta seem to be more Java-driven than anything else, I think. I'm probably speaking heresy, but outside of the singleton idea, other design patterns don't seem to grip me as useful.
Paul Nathan
2010-05-28 15:56:07
The ones that ape `map` and `iterate` with objects are useful (Strategy and Iterator maybe? I can't remember the names.) Factory also shows up in functional languages much slimmed down, often just as currying.
Nathan Sanders
2010-05-28 16:03:38
@Paul - The original Design Patterns book by the Gang of Four, provided implementations mostly in C++, there are 23 patterns, some of which java borrows are Builder, Factory, Iterator, and Observer. It is required reading so I suggest that you go get a copy or at least google it a bit.
crowne
2010-05-28 16:10:31
But you see, when I try to *do* functional programming, it gets messy; I work myself into corners out of which I don't know how to get, and it seems like I'm doing ugly things that aren't right. When I try to use functional programming's restricted set of tools to build a medium-sized application, I find that I need guidance on how to do it well.
JasonFruit
2010-05-28 16:17:29
@JasonFruit: Well, (1) I don't think there is any single source like that for functional programming, BUT (2) I don't think Design Patterns really fills the "how to build a medium-sized application" need for OO programming either. That thinking tends to give a crappy medium-sized app (as without Design Patterns), except that it has "explosion at the Pattern Factory" all over it.It may be a language problem. OO languages tend to emphasise namespacing and access control, which are useful for structuring larger apps. Functional languages, less so, even though ML dialects do have those features.
Nathan Sanders
2010-05-28 16:28:54
@JasonFruit: take a look at Python's Twisted framework or javascript's node.js. Although they are both Object Oriented languages, those frameworks are both event driven with extensive use of callbacks. When you look at the examples, they seem oddly inverted from the usual way of procedural programming. Is it this sort of inversion that is giving you problems ? ( Because, other than that, I usually think of functional programming as being cleaner and easier. What sort of "ugly things" ? )
Steven D. Majewski
2010-05-28 17:23:11
Steven --- that's exactly the sort of thing I mean. You're probably right to suggest that the best way to learn to structure sizable functional apps is to look at sizable functional apps. I'll dig into Twisted --- I'm a lot stronger with Python than JavaScript.
JasonFruit
2010-05-28 18:15:02
@JasonFruit - When doing FP, just break your problem up into simple parts, and design in an iterative fashion. So, figure out how to get a simple version of your app working, then you can work on trying to improve on it. In FP this is easier to do than OOP, as you should have very few global or mutable variables that will be affected.
James Black
2010-05-29 00:53:20
That is to say, do it until you can do it well. Sounds like coding to me.
JasonFruit
2010-05-29 02:59:20
+1
A:
The GoF patterns were written for problems with OOP, and when you change paradigms then the patterns can be shown as not being an issue.
For example, with AOP I believe it was 15-18 of the 24 patterns were obsolete as the solution becomes trivial to solve.
James Black
2010-05-28 15:50:57
+2
A:
The Little Schemer and its sequels, the Seasoned Schemer and the Reasoned Schemer, are not precise equivalents of Design Patterns, but functional programming is not the precise equivalent of OO. The patterns tend to be lower-level, at the individual function level.
So the Schemer books tend to be lower level. Also, they're tutorials, not catalogues.
- The Little Schemer covers the basics of recursion and higher-order programming.
- The Seasoned Schemer is more advanced variations on the same.
- The Reasoned Schemer covers creation of an embedded DSL (Prolog, essentially).
I've only read a little of the Little MLer, but I think it covers abstract data-types: how to program with them.
For all the other "functional design patterns" I know, I've picked up from other people, read in papers, or seen in existing code. But if I think of a more concentrated source, I'll add it here.
- Monads are an important design pattern, probably the only thing in functional programming I would not feel funny calling 'design pattern'. It's very general, so reading the implementations of this pattern is equivalent to reading a whole family of OO design patterns. All About Monads' Catalog of Standard Monads is the best list I know of.
Nathan Sanders
2010-05-28 15:52:36
+3
A:
Edward Yang recently wrote a blog article describing the general relationship between the Gang of Four patterns and the patterns typically used by Haskell programmers.
http://blog.ezyang.com/2010/05/design-patterns-in-haskel/
You might try starting there.
However, as of this point I am unaware of any book on functional design patterns. In general this seems to be a difference in culture. In the programming languages community, the need for a design pattern is often seen as the equivalent of a 'bad code smell' in its own right and is something to be encapsulated behind a higher order function, a macro-based facade, or even a new language feature, rather than enshrined and stylized.
In some sense, we just have one pattern: replacing other patterns with an appropriate EDSL or combinator set.
Edward Kmett
2010-05-28 20:29:10
" . . .the need for a design pattern is often seen as the equivalent of a 'bad code smell' in its own right . . ." Yes, I suppose the Design Patterns book is often viewed as a cookbook, where I've always looked at it as a source of friendly admonitions from practical programmers. The cookbook approach has always seemed to me to be a sign of an unthinking programmer. I'll read Yang's post.
JasonFruit
2010-05-28 22:53:27
That was an interesting article, even though --- as you said --- it's not exactly what I was looking for. He explains very briefly how the problem addressed by each pattern is handled by functional programming constructs, but I'd like to see an answer to the question, "How are common programming challenges solved by experienced functional programmers?"
JasonFruit
2010-05-29 02:56:23