Neal Ford writes:
Some contingents in the functional world claim that the concept of the design pattern is flawed and isn’t needed in functional programming. A case can be made for that view under a narrow definition of pattern — but that’s an argument more about semantics than use. The concept of a design pattern — a named, cataloged solution to a common problem — is alive and well. However, patterns sometimes take different guises under different paradigms. Because the building blocks and approaches to problems are different in the functional world, some of the traditional Gang of Four patterns (see Resources) disappear, while others preserve the problem but solve it radically differently. This installment and the next investigate some traditional design patterns and rethink them in a functional way.
In the functional-programming world, traditional design patterns generally manifest in one of three ways:
- The pattern is absorbed by the language.
- The pattern solution still exists in the functional paradigm, but the implementation details differ.
- The solution is implemented using capabilities other languages or paradigms lack. (For example, many solutions that use metaprogramming are clean and elegant — and they’re not possible in Java.)
I’ll investigate these three cases in turn, starting in this installment with some familiar patterns, most of which are wholly or partially subsumed by modern languages.
Neal continues this series in: Functional thinking: Functional design patterns, Part 2
In the lead-in Neal says:
… patterns sometimes take different guises under different paradigms.
What? Expression of patterns vary from programming language to programming language?
Does that mean if I could trace patterns from one language to another that I might have greater insight into the use of patterns across languages?
Not having to relearn a pattern or its characteristics?
Does that sound like a net win?
If it does, consider topic maps as one path to that net win.