Code Sync: Keynote: Gang of None? Design Patterns in Elixir - José Valim | ElixirConf EU 2024
Comments welcome! View the code-sync and elixirconf-eu tags for more Code Sync and ElixirConf EU talks!
26 Likes
Just watching this now - it’s great to see José looking happy and healthy (I can’t be the only one who worries he (and others like Chris) overwork themselves sometimes!)
The only book I have read about design patterns is Design Patterns in Ruby by @russolsen and it is one of my favourite tech books of all time! Russ is an amazing author and very eloquently (and entertainingly!) explains how to apply the patterns. I’ve asked him a few times whether he’d consider doing one on Elixir! In fact if Russ wrote a book about Elixir on any topic I would be the first to buy it!
Wonder what others think about design patterns in Elixir? They’re all functions? 
8 Likes
Just as he goes on after this, just because we use functions in elixir, this doesn’t mean those design patterns disappear magically, we have them in other forms and shapes.
The more I write elixir the more I start to notice these patterns appear naturally. For example I found times when I had some code that resembled almost 1:1 how builder pattern is used and implemented.
In terms of design patterns I think this is where elixir beats any other languages on the market. You have some very good base constructs like behaviors and metaprogramming that allows you to build your ideal design patterns for your business case.
4 Likes
To add to this, Elixir somehow guards against the too-much-abstraction madness as well. People have come to this forum seeking dependency injection (and “reverse” this or that, I no longer remember) but the answer is always much simpler than they expect. And funnily enough some people get actually disappointed by this.
Gang of Four was a precious book for its time but it was ultimately written to address the realities of the programming languages at the time. And even then it was not guaranteed; one could easily argue LISP was already invalidating the need for most of the patterns in the book.
@AstonJ you likely have no interest but I found the ancient “Effective Java” by Joshua Bloch one seriously good book. It combined patterns and good practices with actual everyday Java writing and I learned a lot from it back then. I was literally living paycheck to paycheck back then and still spent the $40 for it and it paid for itself many times over.
Though ultimately “Refactoring” by Martin Fowler still remains the most valuable programming book I ever read. It is a genius demonstration on how to break apart your program on manageable pieces and always be able to break it apart further before it becomes impossible to work with (i.e. it addresses tech debt).
5 Likes
This seems prominent even with people that write in the same programming language. At one of the projects I worked on Android in Kotlin, there was a guy that was using the same architecture for everything he was building without giving much thought to it.
When I showed him examples of how unnecessary a lot of things are in our current context, he literally could not understand how to use it, lately adding everything in the format he knew back again.
3 Likes
I agree - I think patterns will always emerge. I remember when I was reading Russ’s book thinking to myself “ahhh so that’s what that’s called!” not knowing it was a design pattern! 
I’d like to read that one one day as I’ve heard a few people recommend it 
Btw, in case anyone goes to an Elixir conference and thinks they’re seeing double, José has a brother @paulo-valim who has recently started work in Elixir as well (working for @GroxioLearning). I can attest that he is an equally nice guy!
6 Likes
Same boat, especially José’s response times to questions, issues etc. are super human. He continuously impresses me, and so I worry if he does too much 
@russolsen is an A-class human being and A-class writer! I’ve tried to talk him into Elixir… gosh 2015 I think. But he’s firmly happy over in Clojure land as best I can tell, his talks about teaching functional programming etc. are still worth a watch of course.
F.ex. this one:
You could say, he’s… eloquent in Ruby? 
(my 2nd favorite Ruby book just after POODR, happy owner of a signed copy!)
It’s an old book by now but I keep saying that “Functional Programming Patterns in Scala and Clojure” is one of the best books I ever read for my programming style. It shows you one of the classical patterns first in Java, and then how to do it in Clojure or Scala. Love it, made my Ruby (and later my Elixir) a lot better 
1 Like
No surprise some of us thought he had a clone - and it made me chuckle when I learned he had a brother who looks sooo much like him, haha! Who knows, maybe José is actually a clone of Paulo, given Paulo was a scientist/taught science!
I felt a bit better knowing he has a brother looking out for him 
100% agree! Russ is awesome! He always took time out to speak to us and was incredibly encouraging when I told him I was thinking about writing a book (and told me off for keep saying I was nube - tho of course I still consider myself one!)
I hope he’ll return to Elixir one day too - he must have been interested to have joined here (and not long after the forum started). Keep on to him Tobias! If we both badger him he might just have to to shut us up!
I loved that book as well! I won’t repeat what I wrote in my reviews but if anyone’s interested have a look here.
I’ll keep an eye out for it. There’s just so many books I want to read - my list just keeps on growing!
I have a bit of mixed feelings here. For sure GoF design patterns don’t really work in Elixir, but actually they are quite dated and (almost) equally they don’t make sens in may modern OOP languages that are not Java. So while criticizing them and showing that just language constructs can replace them is valid, it’s kind of a low-hanging fruit.
For sure Elixir would greatly benefit from a set of its own design patterns. OOP patterns don’t work here for sure, for reasons Jose very well put in the talk (about three aspects of an object coupled together). On the other hand, functional patterns usually don’t work here too, as they mostly concentrate on strict types and currying - both of which is not really a strength of Elixir. However we would definitely benefit from having establish routes to address for example functions taking 10+ arguments or modules mixing stateful and stateless code. Looking forward what will come out from the initiative that Jose mentioned.
Actually, he kind of hinted that there are already patterns existing in Elixir (Task, Agent etc.), but I think we are really lacking the resource on how to properly use them in an average Phoenix web app.
6 Likes
Great to watch even if you are not using Elixir
2 Likes
The original is for Java. He eventually made a Javascript version as well. So pick whichever you are more comfortable with. It’s a priceless read and it did open my mind to so many new possibilities back then.
1 Like
Just as he goes on after this, just because we use functions in elixir, this doesn’t mean those design patterns disappear magically, we have them in other forms and shapes.
Yes! We have to keep in mind that the GoF book was written a long time ago and a lot of the problems they were trying to solve revolved around the combination of OO and static typing. Fast forward a few decades and languages like Elixir have fewer constraints and the benefit of many years of experience.
But what doesn’t change with the language is that programming challenges come in all sizes and shapes and – no matter which programming language you are using – some of those challenges will be both common and just beyond what is straight forward to code in the language. And then you need a toolkit of known to work solutions.
Unfortunately design patterns went thru a period of insane over use – I actually worked with people who believed with all of their heart that any programming problem could be solved with the proper application of one – or perhaps seven or eight in combination-- of the GoF patterns. The result was write only code. The resulting backlash kind of poisoned the whole idea in many minds.
I do think the functional world would be helped by folks finding and documenting patterns, but, at least in the circles I travel in, we are going to have to find a different word.
9 Likes
Aston! 
2 Likes
Rrrrrrrrrrrusssssss! 
I hope you’ve been keeping well
I’ve not logged into my Twitter account for a long time so have probably missed any important news, any new books on the horizon? If not, any thoughts about writing one about Elixir, maybe a port of Getting Clojure, elixified?
I’m sure any Elixir book you write would be a huge hit, you’ve already got at least two customers lined up - me and @PragTob 
2 Likes
Aaaaston!
So I stopped using Twitter a while ago. You can find me on mastodon tho: Russ Olsen (@russolsen@hachyderm.io) - Hachyderm.io
Good news: I am working on a book. Bad news: It’s not about elixir. I’m not quite ready to talk about it publicly, but it is coming along. But it’s nice to see elixir – and Jose – going strong.
4 Likes
Ah nice! I’m pleased to hear you’re writing a new book, though of course sad it’s not about Elixir. Maybe one day? Perhaps if me and Tobias keep badgering you!?
I should have known you’d have been one of the first to leave Twitter! I’ve only kept my account open to stop someone nicking the name. I can’t in good conscience support such a platform. I’m not on Mastodon myself as I hear it hasn’t really solved some of the issues (just contained them and if anything allowed them to flourish out of sight). My final project is (hopefully) going to be a social network so maybe we’ll have a decent, viable alternative at some point!
I’ll look forward to hearing about your book when you’re ready to share details about it, I am sure it will be a huge success. Thanks for coming on to post, it’s always lovely to hear from you and your thoughts about topics like the one in this thread
2 Likes
Good riddance. My career was already several years in when all that madness took over and I almost quit programming as a result of how these supposed godlike patterns were applied back then (in my case: Enterprise Java Beans and coding in XML).
1 Like
awesome presentation, i really enjoyed it! some loose bag of comments 
:
stuff i edited so it is more convenient as a short citation is "ted; if i mutilated it accidentally beyond its original sense - my apologies!
“Facade pattern”
it’s a side-note, not really related to what José himself is sharing.
facade pattern example illustrates my main issue with this book and this kind of approach in general:
definition of a pattern is so high level it’s not really that useful IMO: “if you have a problem repeating often, you look for a design pattern to solve it”. it’s not about design patterns, it’s about software engineering or engineering in general. following this approach you will call function a pattern, and really anything you repeatedly do is a pattern (because it has reappearing cause). it seems if you will follow such definition of a “programming pattern” you will see patterns everywhere, in great numbers, universally.
perhaps it would be more interesting to focus on conditions and issues which are arising due to specific design decisions behind particular programming languages or frameworks, maybe?
(…) “When you introduce inheritance, you can break object state encapsulation”
i probably misunderstood this part and my comment might be missing the spot?
i would say, in this context, object encapsulation is a feature which manifests during object lifetime, and concerns object usage, object API exposed to a user.
inheritance is not “object runtime” feature, you inherit machinery which “instantiated” gives object life: code behind it, a class etc.
when you inherit a class, you inherit something like object blueprint, and your code is behind API object exposes to its user, and your code has same right to modify and work with state and code you inherited, no? 
Ohh, of course José is going to be saying that
(…) “Go has only composition”
against common opinion, i think it’s not really the case. Go has both composition and another mechanism called embedding.
at data / structure level, embedding looks like a composition, but not at struct methods level.
when you are embedding type within type in Go, methods from a type being embedded start to be accessible from parent type level - parent pretty much inherits those methods.
i think main idea behind it, is to be able to… yes, inherit that code without just copying it, with option to override what you don’t want.
this approach to existing… “patterns” is common in Go i think. something is slightly tweaked, name changes, confusion arises, discussions start, and we debate to what extent, and if, Go is OOP language
“Strategy pattern” / “decoupling is not self-serving”
thank you for this reminder! for what it’s worth, i fully agree nowadays, but it’s still a topic with which i struggle a bit sometimes.
“Interpreter design pattern”
let’s make it official!
i don’t want to create echo chamber with a random, singular anecdote, but i 200% agree with what José says about pattern matching in this presentation. big, big chunk of my love towards Elixir, is related to pattern matching, especially in function heads.
3 Likes
I feel for you. In fact when the publisher came around asking if I’d be interested in writing a book about design patterns my initial reaction was You much be kidding. But on reflection what I came to was 1) DPs are not such a terrible idea in themselves and 2) no idea is foolproof because the fools are so clever.
2 Likes
I wonder if the DPs are bad, or the features of some of the languages implementing them are. I think that static typing + OOP + mutability is a horrible choice of features to be present together in a language and in some sense their features contradict each-other.
You look at a lot of those patterns and a lot of them are oriented about limitations of OOP + static typing and some wacky ways to overcome them, one of the horrible ways being inheritance.
2 Likes
