Just watched the videos - interesting stuff and I do think there’s a higher level language lurking in Elixir. These experiments hopefully help guide extracting the right one.
I am surprised though that @pragdave states “design patterns are crap”. As a card-carrying Hillside Group member such a blanket statement probably has to offend me ;-).
(If he meant - the original GoF design patterns are crap because written for a crap language - for a fun read, pick up the Design Patterns Smalltalk Companion - I’m ok with that, of course)
We are uncovering better ways of developing software by seeing how others have already done it.
Kevlin Henney
Patterns are an aggressive disregard of originality.
Brian Foote
IMO too many “pattern consumers” have very selective memories. Each pattern catalog entry has multiple sections:
Intent
Also Known As
Motivation
Applicabitity
Structure
Participants
Colloaboration
Consequences
Implementation
Known Uses
Related Patterns
Before applying a pattern it is crucial to understand the full implications of the “Applicability” and “Consequences” sections as use case constraints could easily turn a pattern into an anti-pattern.
Patterns aren’t gold standards. They merely record “this approach has worked for us when we faced this particular problem within our specific context”.
Design Patterns are not crap. They just shouldn’t be used by people in the way they are.
They are treated by most developers as recipes: “I need a to implement a xxx pattern”.
But they aren’t. Instead, they are a naming system. Once you’ve written code, you can say “oh, look, that’s like a strategy pattern.” You could then refer to it as such as a short cut when talking with other developers.
Next time you meet an architect, ask them about Christopher Alexander or A Pattern Language. I’ve never met one you knows what I’m talking about…
I did, but he was called Chris Alexander so it doesn’t count ;-). One thing that is interesting, though, is that Chris has long since moved beyond patterns to something he calls, I think, “unfoldings” - more dynamic than patterns, as patterns didn’t bring him what he thought they’d bring. I find it strange that “the patterns community” seems to have ignored that bit; patterns are seen as something Moses brought down from the mountain just as, say, Smalltalk-80 was. They got handed to the community and froze in place while people looked at it in awe while the original creators moved on. One of the things on my todo list is re-read Chris’ Nature of Order and see how we can bring the patterns community forward. It’s a somewhat more manageable task than trying to figure out what Kay and friends would’ve done to Smalltalk if they’d stayed another four decades at PARC
I do disagree with the characterisation of patterns as merely descriptive, post-hoc tools to name things. I do think they are a really good way to write down known solutions and share them forward especially because of, as @peerreynders correctly remarks, their rich contextual content. At least, that’s the way it should be. Too often, people boil down their patterns to “problem A → solution X” but that’s called a subroutine library, not a design pattern
Also, my apologies for the way I apparently managed to sidetrack this thread. Maybe someone with forum-fu should split it off so we can get back on track.
