I am a junior Rubyist and actually learning Elixir for fun. While I was learning some OOP design patterns for my job, I was wondering: “What about Elixir, functional and concurrent programming?”
I always see things about the Gang of Four, OOP, popular stuffs like that, but for FP, I came across this image:
I know design patterns came to resolve some common problems in OOP, but I suppose FP isn’t perfect and some problems can occur as well
Can anyone shed some light on this subject? And share some resource if needed?
There are design patterns, but they are different.
One video I liked when switching from Ruby to Elixir is…
OTP is also a guide to good design with processes. It is worth learning.
The FP side of Elixir and Erlang is pragmatic, You can have side effects everywhere, and You don’t have some tools others FP languages may have, like monad, functor.
UPDATE: Oh, by the way your image comes from this talk
I get what you’re saying and you’re not wrong per se, however, these are abstract patterns that one can use in Elixir, they’re not enforced at the type level, nor do we have syntactic sugar for some of them.
for the boring real-world software I write I do not feel the need for monads and the other fancy stuff.
reduce and flat_map and frieds take you a long way.
And using lists like [1,2,3] ++ [] ++ [4] is nearly a monad isn’t it?
As for design patterns, the picture you posted is correct (Its from Scott Wlaschin, right? https://fsharpforfunandprofit.com/). But there are some helpful architectural patterns, like
Oh don’t get me wrong, I didn’t mean you need them. They may be very useful if it’s your kink, but I wouldn’t dare say one should learn about them to write elixir code. I was just pointing out that the abstractions are usable in Elixir, even without typeclasses and friends, because they are just abstractions.
But yeah, far better to learn OTP concepts, and indeed basics of reduce and friends ans recursive functions, than wasting time on abstract algebra (unless it’s your kink).
This video course really resonates with how like to organize my code in OOP and that I ported to functional Elixir.
My repo from following the course:
So, for design patterns I like to use one that groups things by action performed on a resource, be it in OOP or Functional.
In OOP I was using the Resource Action Pattern, that lends well to functional Elixir, but requiring some adaptations to use distributed Elixir and Elixir processes, that I will borrow from the video course above:
So, @pragdave encourages us to separate the implementation from runtime considerations (OTP), and that was the missing bit in my Resource Action Pattern port to Elixir.
The Resource Action Pattern requires that the code for each resource to be split to his own file by action. For example, if you have the Product resource, then you will have lib/impl/products/add/product_add.ex, lib/impl/products/modify/product_modify.ex, etc. .
This approach as worked very well for me along the OOP years. At a glance I can see which resources a project has, and which actions are performed on them just by opening a folder. No need for reading docs, and it makes easier to onboard new devs to the project.
Friendly reminder that while Elixir is considered a functional language, the lack of auto currying makes the majority of functional programming patterns very cumbersome to use and functional composition(h = g ∘ f) is very rare in idiomatic elixir code, and thinking of elixir as a functional language like the others sets the wrong expectations. Sure, they’re good as inspirations, but I don’t find much value in them in Elixir other than having the vocabulary to understand why flat_map is called flat_map.
I find the philosophy of Clojure, ie the idea of data > functions, and thinking of data transformations rather than function compositions, is more helpful(see Ecto’s Changesets, Plug’s Conn, Ecto’s Multi and so on for inspiration). I unfortunately don’t have a list of resources right now, I’d like to compile some at some point or write down my opinions sometime, but I just wanted to point that out
One video I liked when switching from Ruby to Elixir is…
I just finished the video, didn’t understood everything but I keep some keywords and concepts for the future!
OTP is also a guide to good design with processes. It is worth learning.
Thanks for the link, it took me time to understand the relation between Application, Supervisor, GenServer, and other stuff, I bought Programmer Passport: OTP for that, didn’t finished yet but at least I have some basic to understand what people are talking about.
From what I understand from this conversation is “functional principle” aren’t that important in Elixir and I should focus on OTP then application architecture since all functionals concepts arent “compatible” (sorry for the wording) with Elixir.
Thanks everybody for the conversation and links, I kept some keywords for more research!
I understand the sense that the image is trying to convey, but I don’t think it’s particularly fair: the left-hand side are concepts and the right-hand side are implementations.
If the left-hand side was also implementations, it would just be “objects, objects, objects, yep objects again, objects etc”.
If the right-hand side was also concepts, it would have lots of things (some of which have already been mentioned) - monads, pattern-matching, etc.
Some of the right-hand side wouldn’t even be different - for instance, it seems totally reasonable to call this an example of the strategy pattern, where Enum.sort accepts a module that defines a compare/2:
My first steps towards functional programming were in haskell. Never really did get it. Thats why I like Elixir, its a functional language that I can understand as a programming-craftsman. Imo using patterns like monads builds a wall around your code, which makes onboarding “craftsmen” nearly impossible (like you said, everyone that gets the code cant explain it).
I’d really like to see an example were using monads gives that much of a benefit over the Elixir way (tagged tuples, lists, with, …) that justifies the brainf***.
Bit of a rant, sorry. Skip if you are not in the mood for one.
I would challenge even that. I worked with Java for 8-9 years and I worked with it in its heyday (and I dropped it when it became too crazy and “programming” in Java was 80% writing XML and 10% writing .properties files). The other 10% you maybe wrote some Java.
Those “patterns” helped only insofar as everyone was using them and thus onboarding in other people’s code was accelerated and made easier. They didn’t help with much else otherwise. They were like 90% social norms and 10% legitimately helpful ways of manipulating data via standardized code that made it future-proof-ish.
I also believe the entire “patterns” wording is quite unfortunate and does not at all capture the idea. “Dependency inversion” is just “don’t just pass one of the 17 implementations of this contract as a parameter to the using function, you idiot, use configuration!” and nothing else. “Factory pattern” is more or less “you don’t know the internal invariants of this data structure so please use a dedicated creator function for it and don’t try to be clever by directly setting the fields yourself”. Etc.
These should be common sense and should not be called “a pattern”; more like “an engineering guideline”.
That whole terminology only serves to make guys in suits-and-ties feel special and label themselves as consultants and bill insane sums of money for scratching their beards in meetings. Change my mind. (It’s going to be hard because I’ve seen how they work, closely, several times in my career, and was not impressed. Of course it could also be bad luck, sure.)
On topic: for FP I think #1 principle would be: make the thing you want to manipulate composable and pipe-able (reference: Ecto.Query, Ecto.Multi, Stream). Make it so you can manipulate the thing and accumulate / modify state captured inside of it. Make it so this can be done by any function abiding to a certain contract. Finally, invoke a function that actually “executes” what this thing represents (like Repo.transaction actually does all the DB operations accumulated inside an Ecto.Multi; while at the same time Ecto.Multi.insert function does nothing but put a state/command inside the Ecto.Multi that says “OK, when this Multi gets executed, we want to create this DB record”).
I have very small amount of failures in my career (although they make up for it being hugely embarrassing! ) and the “patterns” thing very rarely clicked with me, or most teams I ever worked with for that matter. People just organically and iteratively find what works best for their project. Stuff like “hexagonal architecture” or “functional core, imperative shell” are in general very good ideas and are emergent properties of most projects. I do like them but they too are not universally applicable.
It does not give you a long list of patterns that you can name and say that you know. But it does give some very practical step-by-step guidelines with examples of how to design software with Elixir.
Like OOP design patterns, the book’s content is better consumed as ideas that you can safely ignore in some situations but can help you work toward simpler, more extensible/testable/maintainable code.
Some things probably apply in every situation I can think of, for example: “Try to keep the bulk of your complexity in modules with as-pure-as-possible functions and keep your process machinery (Genservers, etc.) as thin as possible.”
(It’s going to be hard because I’ve seen how they work, closely, several times in my career, and was not impressed. Of course it could also be bad luck, sure.)
