Keynote: Gang of None? Design Patterns in Elixir - José Valim | ElixirConf EU 2024

[@somewhereatvinland]

EVERYTHING IS CONNECTED! This was such a great talk, thank you for uploading it.

[@Siddharth9092]

The absolute phenomenal quality of José's talks is always a breath of fresh air. This guy is awesome 🙌

[@nedotraxxxx]

Met him in Kyiv some time ago during the conference. Definitely Jose radiates motivation and kindness 🙂

[@apolkk]

He's a beast, i think he should try to write a programming language or so

[@rodrigolj]

00:00 - Code Sync Intro 00:15 - Introduction 04:55 - Design Patterns in Elixir? 10:04 - Mediator Pattern 13:59 - Facade Pattern 15:57 - Strategy Pattern pt.1 21:10 - Interfaces in Elixir? 27:32 - Polymorphism in Elixir 28:45 - Strategy Pattern pt. 2 34:10 - Patterns classifications pt. 1 34:55 - Design Patterns not applicable to Elixir 43:23 - Design Patterns for Polymorphism (Adapter, Decorator, Proxy) 45:00 - Observer pattern 47:16 - Patterns classifications pt. 2 49:18 - Where to go next? 50:46 - Q&A

[@AdolfoNeto]

Thanks! I have used Facade and Strategy in my PhD system code in Java.

[@mircoporetti874]

I’m starting to learn Elixir after working with Java for 10 years and Kotlin for the last 3 years. It’s natural to make comparisons when you step outside the OOP world and it could happen to feel lost. This talk was very useful! Thank you.

[@mcaneris]

Seriously, one of the most valuable talks I've ever listened to. Thanks José.

[@tevoj]

Such a good talk. This should be “pinned” in Elixir’s documentation as a must watch talk.

[@NatanaelSirqueira97]

Very insightful talk José! I particularly appreciated the concept of 'Elixir decoupling objects into three dimensions'.

[@JamesJosephFinn]

Sheer brilliance

[@chrichtonreal]

Brilliant talk!!!!🎉 One question? Where do I get the slides?

[@auraSinhue]

José Valim is one of the minds of our generation

[@elixirfun]

Seen it live, it's very good.

[@awksedgreep]

Amazing work. As a new user of Elixir this has tremendous value.

[@calori1983]

Amazing talk !!! It really nailed the design pattern in Elixir

[@NowahMsT]

If we could pattern match on behaviours it would be a game changing feature. Amazing talk btw

[@jaeyson]

How soon will it be? :)👌🏽

[@payton6_]

Anyone have any more information on 37:23? I would like to read more about that behavior and all of the rules for when that can be optimized. So cool

[@m3ll0f3ll0]

In cases like that where the input isn't dynamic, meaning calling the function always produces the same result, at compile time they are created as variables, rather than being computed every time they are called at runtime

[@raenastra]

There doesn't seem to be an official source that I can find, but I'd be interested too. Compiler optimizations like this are sort of tribal knowledge in functional programming: in this case, it's known because it's a known benefit of immutability

[@pertsevds]

Great talk! I love Elixir (cough, Erlang) pattern matching =)

[@bdarla]

The solution for the Interpreter design pattern is amazing!

[@TrungLê-k8g]

Just come to think of it, what IF we could pattern matching behaviour?

[@jollyjerr]

Wow, great talk.

[@sriramkota]

Fantastic talk.

[@jaeyson]

Where can we get the slides?

[@AsadSiddiquee]

awesome talk. 😊

[@dharma.vibrates]

❤ I am going to learn it 😊

[@laozi6951]

Nice talk

[@alexmid]

good talk

[@MrManafon]

God damn i love listening to this guy speak w

[@markhoo]

👍👍👍

[@kellyaquinastom]

Saw comment about this in a 10 sec. Clip

[@jameskim4274]

This moment, when you seeing Creational patterns category for data-driven language..

[@casybond]

Flyweight example (kzbin.info/www/bejne/l5jOiYimZc12jZosi=3dgU7oj2BqaR4I9N&t=2162) misses the point. Flyweight is used for run-time data, not fixed data as is shown in this video.

[@jmlandi]

Yes, that is why is he using as example of design pattern that doesn’t apply to the language

[@richmorin424]

Fine presentation, if similar to previous observations... Edited from ChatGPT: "Peter Norvig demonstrated in a 1996 presentation that many of the design patterns described in the classic book Design Patterns by Gamma et al. either become simpler or disappear entirely when implemented in dynamic languages like Lisp and Dylan. He argued that these patterns compensate for the lack of certain features in languages like C++."

[@Remindor]

IMO, the ability to co-locate state and logic is one of the main benefits of OOP as it helps to design modules that are cohesive and loosely coupled. The main anti-patterns of OOP are inheritance and pass-by-reference. This is because of 'spooky action at a distance' whereby the state mutation is difficult to trace because the same object reference was held in many different parts of the code. These issues are easily avoided. Ideally, you should aim to pass around information/messages by value instead of passing objects/instances to each other. My main problem with pure FP is that interactions between functions often involve passing around a large amount of state. A lot of unrelated state ends up traversing through unrelated functions. You end up having to invent technical abstractions to manage, split, group and otherwise distribute your state efficiently to where it's needed but this makes logic chains long and difficult to follow. If you want to catch a taxi from A to B, you don't need to bring your own car seat, petrol or steering wheel; the taxi driver is responsible for that. You just give them the message of where you want to go and you trust that they have all the tools and materials (the state) to do their job properly. The taxi driver controls the state. If you don't like the way the taxi does its job, you can substitute it for an Uber or a Bus or a Train... You don't have to worry about whether or not your steering wheel will also fit the Bus. Why do you want to force the taxi to use a particular steering wheel? As a user, shouldn't your primary concern be to reach your destination within a reasonable time? Why concern yourself with the taxi's implementation details/state? Do you need to know what kind of fuel it requires? No. Those things are not relevant to your goal. If you have to bring your own chair, steering wheel and petrol to catch a taxi, it causes tight coupling because you need to know what brands and sizes of steering wheels, chairs and petrol are allowed for that particular taxi... You want to replace the taxi with a bus? Too bad, your steering wheel is too small for the bus... Time for a complete refactoring. Tight coupling. Now you need to call a factory in a different part of the country to manufacture a steering wheel of the right size. The bus' responsibilities are not well defined because a lot of coordination must happen on the outside to supply it with the state it needs to do its job; low cohesion.

[@abadongutierrez]

I like Elixir, I think Jose is a great developer, but I also think this talk is very simplified to make look functional programming (with Elixir) as the best solution to everything, which it is not.

[@Deemo_codes]

I think you've misinterpreted the talk. Its not saying that elixir is the best and should be used for everything, it's saying that the design patterns that have been laid out in the GoF book apply in elixir as much as they do in OO languages. With some exceptions because the separation of state and behavior means some problems described in the book don't occur in FP languages

[@martycrow]

This is interesting for techies mostly under 50, but for anyone older involved in the public policy space and not a digital native, this sounds like a solution looking for a problem. And in the provessing iof releasing the 'anti-parrtern thinking into the world we will end up with a bigger and worse problem than we have rampaging across out Tech for Good spaces.

[@pertsevds]

What "public policy" and "not a digital native" has to do with programming patterns? Did ChatGPT wrote this comment for you?

[@martycrow]

@@pertsevds "Did ChatGPT *write* " not 'wrote'. Ask someone older to explain it to you. And the other thing.

[@pertsevds]

@@martycrow English is not my native language.

[@WilsonSilva90]

Maybe you just want to vent.

[@rumble1925]

​@@martycrow If you're not involved in software you obviously don't understand the problems that we face when writing code. So I don't think you have any idea if the "solution is looking for a problem", just yapping.

[@michaelG1122]

Java, Javascript, Python, .Net, C/C++ - they all just work with IDEs, debuggers etc. Elixir and Beam - not so much, it is nothing but constant struggle to get anything done. The language server in VS Code for Elixir is a joke.

[@pookiepats]

Gleam