Yes, I recognize that is how you see patterns. However, patterns are supposed to be formal elements of real world solutions. They are not simply proven to work, but they can (and should be) proven through formal analysis to have unique properties. I’m happy for you, but it seems to me like you are undergoing a mathematical re-awakening more than anything else. That’s great, but don’t drop what you already learned at the gates just so you can pass through into Heaven.

Software engineering can be *both* intuitively appealing *and* mathematical. Creational patterns allow composition, by definition. Behavioral patterns also allow composition, by definition. Structural patterns also allow composition, by definition. People often misunderstand the GoF design patterns. “Prefer composition over inheritance” is a major principle behind these patterns. Yet, just the other day I was reading a blog that *tried* and *failed* at teaching the most mathematical design pattern of all: Singleton. Someone in the comments stated that the purpose of a Singleton was to create a “pattern of prohibition - to stop a programmer doing something they shouldn’t do by accident by enforcing the primary goals of single point of access”. This is not true, either. Singleton is a mathematical concept. Even in Lisp, there is a singleton: *nil* or the *empty* list (depending on the dialect of Lisp). This is the most natural expression of Singleton possible, and absolutely essential to Lisp: it is the ATOM! of Lisp.

It is true that Singleton has major repercussions on referential transparency, seeing as how it enforces global state at the architectural layer it is defined in. In Lisp, nil is totally referentially transparent, so you can define it at any layer of your architecture you choose. The symbol is global scope, but not many people say it is global state. This is not true. It is a globally-defined state, not a global state. A global state would mean you’ve hardwired something significant into the system that you truly intended as a “pattern of prohibition”. People do this all the time, because they can’t see the consequences of their actions, both intuitively and mathematically!

Take for instance your typical Dependency Injection framework that ends up injecting objects into Controllers and Managers. What is the point in injecting _anything_ into an object with the name “Manager” or “Controller”? Objects named “Manager” or “Controller” are the true prohibition, because they hard-wire state-process decisions and force actions to go through them - you need managerial approval from the Boss component to get work done. This is far from composition, and also far from the goals of inheritance. It’s simply bad system planning and design. The end result is that you have an architecture that responds slowly to maintenance actions, because any assumptions made in the Manager or Controller are going to be impossible to revisit, because they directly impact the whole system. At this point, a “bug” in such a component becomes a “feature”. If you don’t like it, well, too bad!

I could rant for hours about this, and how it is important to understand design and examples of good design BY NAME and why they work, not simply what they are used for. Suffice to say, if you are experiencing a mathematical reawakening, don’t think for a second that design patterns degrade. Instead, I encourage you to unite your intuition with your growing mathematical prowess. Try learning the most intuitive mathematical system of all: Geometry. Hyperbolic geometries, Finite geometries, Infinite geometries, etc. At least, Modern Geometry was the course in college that taught ME the most about systems thinking and how to design programs. At that point, it was clear to me that specification trumps structure, and that understanding the importance of an intuitive and mathematically appealing specification is a loftier goal than understanding design patterns.

Absolutely not. This is a canonical example of how novice functional programmers do not understand the value of patterns. A UML Class Diagram tells you absolutely *nothing* about the pattern. You *have* to see the context that the pattern is being used in. Static representations of patterns don’t work. If that were the case, then it would be a simple matter of stitching together lego building blocks to make applications: Just cut-and-paste patterns! However, that is NOT the case.

Also:
Part of me really loves that Norvig Patterns link, and the other part of me really hates it, too. It just seems like people take concepts as being mutually exclusive: ‘if the pattern isn’t visible, then it *degrades* or ceases to exist.’

I wrote a blog post commenting on an aspect of this stuff a while ago. Warning: the post contains errors, but they’re corrected in the comments.

And historically, DSLs aren’t particularly tied to the FP camp. Smalltalk’s a pure OO language, and DSL creation is very much part of their culture. Many APL applications were actually delivered as embedded DSLs written on top of APL (an array-based language, albeit with some functional attributes). Lisp’s arguably a functional language, and Lispers write a lot of DSLs, but they mostly use macros to do so.

http://norvig.com/design-patterns/img010.gif

Eg. a sort function that takes, say, a lambda function to implement the equality relation can be said to use the Strategy Pattern. The fact that there’s no boilerplate is a merit of the language. Or is there a better terminology for this kind of pattern in functional languages? (’higher order functions’ or similar don’t really suggest the same thing as ‘Strategy’ - but that might just be me…).