G'day all.
Quoting Donn Cave
Well, maybe not Patterns, but wouldn't there be important skills relating to patterns in a more general sense? Like "fold", for example, seems to be a pattern, with several standard implementations and no doubt countless others to suit particular applications.
This is actually an excellent illustration of what patterns actually are. Patterns are a form of engineering experience. When we see the same form of code or data turning up multiple times, we abstract it and give it a name so we can reason about it independently of any application that we find it in. This is exactly the same as category theory. The point of category theory is to spot patterns in mathematical structures, and then abstract them away from those structures, and give them names so we can reason about them independently. The only real problem with patterns (apart from the hype) is that some people have the mistaken impression that Design Patterns == Gang of Four Book. The patterns that GoF documented were not meant to be an exhaustive list, nor were they meant to apply to non-OO languages. (The plethora of "modern C++"-style headers which encapsulate a lot of the GoF patterns are good examples.) Some patterns have different names in other languages. What GoF calls "factory method", for example, a Haskell programmer would call "smart constructor". What they call "flyweight" we call "memoing" or "hash consing". And some patterns are trivial in some languages but hard in others. In Haskell, forward iteration is trivial (we call it a "lazy list"), but it has to be manually added in Java. In C, global mutable state is trivial, but has to be manually simulated in Haskell. Cheers, Andrew Bromage