Thinking Functional

We have this topic on forum. Maybe it will help.

You may want to have a look at Erlang and Elixir for Imperative Programmers (I haven’t read it, so I can’t really comment).

Personally given that even Erlang/Elixir aren’t “purely functional” I started reading Haskell Programming from First Principles - admittedly an extreme approach but I felt that my brain needed an extreme push (I think Erik Meijer just finally wore me down with his “learn Haskell”).

I am also reading http://haskellbook.com/ plus http://learnyouahaskell.com/ . There is also Erlang book http://learnyousomeerlang.com/.

There was a talk by Morgan Laco at ElixirConf about switching to Functional Programming(/Elixir) when coming from OOP. It might still take a few days before a video version of that talk appears online, however.

I recommend The Little Schemer. It’s not a comprehensive introduction to functional programming, but it will rewire your brain to think recursively, which is the single biggest obstacle to overcome with functional programming. Rewriting the programs into Elixir would make for good exercises.

I’m currently doing SICP in Elixir. Elixir is a lot like Lisp but much easier to mentally parse.

There’s also GitHub - jwhiteman/a-little-elixir-goes-a-long-way: The Little Schemer in Elixir. · GitHub!

Thank you everybody!!!

2014 NDC London,UK
Functional programming design patterns by Scott Wlaschin

as referenced in
From Front End to Full Stack with Elixir and Phoenix by Lauren Tan (ElixirConf 2016)

I think that the main change is that instead of having objects that themselves are responsible for their capabilities, you have data which can be transformed into other data if it has the correct format.

Thinking with transformations is a lot more extensible and flexible than thinking with a hierarchical model of objects.

In an OOP language (a true one like Ruby. In languages that have a difference between primitive types and objects like Java, you might need to use a.equals(b) instead), a comparison like a == b actually calls a method on object a. Which means that the result might be very different than b == a.
And you will need to define those methods in two places.

In a Functional language, you simply state what the result should be between a comparison of these two kinds of objects. In a single place.

I agree with the above, however I have to say something about the following statement:[quote=“Qqwy, post:10, topic:1771”]
I think that the main change is that instead of having objects that themselves are responsible for their capabilities, you have data which can be transformed into other data if it has the correct format.
[/quote]

In Erlang/Elixir one can think of processes as being objects, in fact when OO was being discussed by Alan Kay (one of the fathers of the idea of object-oriented programming) and Stefan Ram, Alan said the following two statements

I thought of objects being like biological cells and/or individual
computers on a network, only able to communicate with messages

OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other
systems in which this is possible, but I’m not aware of them.

Now this sounds a lot like the processes in OTP. I found the info in this really interesting article by James Edward Gray it’s a nice read. I’ve heard many times OO was about message passing and not Classes but I could not fully grasp that concept until I looked at it through Elixir and OTP.