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.

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

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)