Design Pattern for functional / concurrent programming

I’d recommend checking out posts from Functional Programming Design Patterns | F# for fun and profit

This talk on Micropatterns by Cameron Price is also worth a look https://www.youtube.com/watch?v=9uvp4h7gXHg

Like @scottming mentioned

This book is excellent and sort of on the topic Designing Elixir Systems with OTP: Write Highly Scalable, Self-Healing Software with Layers by James Edward Gray, II and Bruce A. Tate

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.”

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.

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***.

I’ve been writing elixir for 3 years, and the patterns I find most useful are the ‘CRC pattern(token base)’ and ‘Functional core, imperative patter’, the world of Elixir is almost everywhere CRC, Ecto.Changeset, Plug.Conn, Absinthe blueprint and so on, Bruce has a book on this topic: Designing Elixir Systems with OTP: Write Highly Scalable, Self-Healing Software with Layers by James Edward Gray, II and Bruce A. Tate

For functional core pattern, there is a screencast with Ruby language: Functional Core, Imperative Shell

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

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

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)

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!

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