Design Pattern for functional / concurrent programming

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

• Hexagonal architecture (software) - Wikipedia
• The Functional Core, Imperative Shell Pattern – Kenneth Lange

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:

https://github.com/Exadra37/elixir-for-programmers-2_learning

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:

Screenshot from 2022-08-05 20-26-25172×171 3.17 KB

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

Thanks everybody for your replies

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:

Enum.sort(list_of_datetimes, DateTime)

Once you understand what a monad is, you can’t explain it.

That’s why there are such a enormous number of decriptions of monads