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

Поділитися
Вставка
  • Опубліковано 27 гру 2024

КОМЕНТАРІ • 55

  • @Siddharth9092
    @Siddharth9092 7 місяців тому +63

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

    • @nedotraxxxx
      @nedotraxxxx 7 місяців тому +3

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

    • @apolkk
      @apolkk 3 місяці тому +2

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

  • @mircoporetti874
    @mircoporetti874 6 місяців тому +14

    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.

  • @rodrigolj
    @rodrigolj 7 місяців тому +45

    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
      @AdolfoNeto 7 місяців тому

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

  • @somewhereatvinland
    @somewhereatvinland 16 днів тому

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

  • @mcaneris
    @mcaneris 7 місяців тому +12

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

  • @tevoj
    @tevoj 4 місяці тому +1

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

  • @chrichtonreal
    @chrichtonreal 7 місяців тому +5

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

  • @NatanaelSirqueira97
    @NatanaelSirqueira97 7 місяців тому +16

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

  • @elixirfun
    @elixirfun 7 місяців тому +3

    Seen it live, it's very good.

  • @awksedgreep
    @awksedgreep 7 місяців тому +2

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

  • @auraSinhue
    @auraSinhue 7 місяців тому +6

    José Valim is one of the minds of our generation

  • @calori1983
    @calori1983 7 місяців тому +2

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

  • @bdarla
    @bdarla 8 місяців тому

    The solution for the Interpreter design pattern is amazing!

  • @NowahMsT
    @NowahMsT 7 місяців тому +2

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

    • @jaeyson
      @jaeyson 7 місяців тому

      How soon will it be? :)👌🏽

  • @payton6_
    @payton6_ 7 місяців тому

    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
      @m3ll0f3ll0 7 місяців тому

      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
      @raenastra 6 місяців тому +1

      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
    @pertsevds 7 місяців тому +8

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

  • @TrungLê-k8g
    @TrungLê-k8g 7 місяців тому

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

  • @jollyjerr
    @jollyjerr 7 місяців тому

    Wow, great talk.

  • @jaeyson
    @jaeyson 7 місяців тому

    Where can we get the slides?

  • @sriramkota
    @sriramkota 7 місяців тому

    Fantastic talk.

  • @dharma.vibrates
    @dharma.vibrates 7 місяців тому

    ❤ I am going to learn it 😊

  • @AsadSiddiquee
    @AsadSiddiquee 7 місяців тому

    awesome talk. 😊

  • @MrManafon
    @MrManafon 7 місяців тому

    God damn i love listening to this guy speak w

  • @laozi6951
    @laozi6951 7 місяців тому

    Nice talk

  • @kellyaquinastom
    @kellyaquinastom Місяць тому

    Saw comment about this in a 10 sec. Clip

  • @alexmid
    @alexmid 7 місяців тому

    good talk

  • @markhoo
    @markhoo 7 місяців тому +1

    👍👍👍

  • @jameskim4274
    @jameskim4274 7 місяців тому

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

  • @casybond
    @casybond 4 місяці тому

    Flyweight example (ua-cam.com/video/agkXUp0hCW8/v-deo.htmlsi=3dgU7oj2BqaR4I9N&t=2162) misses the point. Flyweight is used for run-time data, not fixed data as is shown in this video.

    • @jmlandi
      @jmlandi Місяць тому

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

  • @richmorin424
    @richmorin424 4 місяці тому

    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
    @Remindor 5 місяців тому +1

    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
    @abadongutierrez 7 місяців тому +3

    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
      @Deemo_codes 5 місяців тому +5

      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

  • @michaelG1122
    @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.

  • @martycrow
    @martycrow 7 місяців тому +2

    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
      @pertsevds 7 місяців тому +11

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

    • @martycrow
      @martycrow 7 місяців тому

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

    • @pertsevds
      @pertsevds 7 місяців тому +7

      @@martycrow English is not my native language.

    • @WilsonSilva90
      @WilsonSilva90 7 місяців тому +1

      Maybe you just want to vent.

    • @rumble1925
      @rumble1925 7 місяців тому +1

      ​@@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.