Type classes allow you to externally declare a role a particular type can play, potentially dependent on what other classes it
implements.

Type classes don’t give you nifty method combinators that CLOS has, but CLOS doesn’t give you the static capabilities that
typeclasses do. Two different beasts with different aims, with properties that are imho rather illustrative of their host languages.

-Joanne

Did you heard about Presenter First variation of the MVP pattern? IMHO in non-Web world it’s more natural to create an instance of non-visual component (Presenter class) and after that create a brand new View (or reference an existing View).

Regards,
Igor

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.