2009/3/11 Mark Spezzano
I’m very familiar with the concept of Design Patterns for OOP in Java and C++. They’re basically a way of fitting components of a program so that objects/classes fit together nicely like Lego blocks and it’s useful because it also provides a common “language” to talk about concepts, like Abstract Factory, or an Observer to other programmers. In this way one programmer can instantly get a feel what another programmer is talking about even though the concepts are fundamentally abstract.
Because Haskell is not OO, it is functional, I was wondering if there is some kind of analogous “design pattern”/”template” type concept that describe commonly used functions that can be “factored out” in a general sense to provide the same kind of usefulness that Design Patterns do for OOP. Basically I’m asking if there are any kinds of “common denominator” function compositions that are used again and again to solve problems. If so, what are they called?
You might find it useful to read the original works upon which the whole "design pattern" economy is based, namely Christopher Alexander's books (http://www.patternlanguage.com/leveltwo/booksframe.htm?/leveltwo/../bookstor...). I liked "Notes on the Synthesis of Form", which predates his pattern language stuff. My $0.02: design patterns became popular in the imperative language community precisely because such languages lack the formal discipline of functional languages. Alexander came up with the notion of a pattern language in order to bring some kind of discipline and abstraction to observed regularities in architecture, urban design, etc. By definition such a language cannot have anything close to formal semantics, any more than a natural language lexicon can have formal semantics. Alexander's writing is very interesting and thought provoking, but I'm not sure it has much to offer the world of functional programming. Programmers used Alexander's ideas to try to bring some order to both specifications and programs. A pattern language is a natural for trying to describe a real-world problem one is trying to solve. Imperative programmers also used it to describe programming patterns. Implementations of things like Observer/VIsitor etc. are ad-hoc, informal constructions; the equivalent in a functional language is a mathematical structure (feel free to fix my terminology). I don't think one needs design patterns for Haskell; it has mathematics and more-or-less formal semantics. Who needs "Visitor" when you have "For All"? Although design patterns may still be useful for describing a real-world problems I suspect one would be better off dumping the notion of design pattern, the better to avoid cognitive dissonance when trying to think in purely functional terms. Cheers, -gregg