Functional programming learning path

I come from an OOP background (Ruby!) and this is what I have done so far and highly recommend

That last one is an excellent look into functional programming

Check out my reviews in each of those threads for more of my thoughts on them too

I am currently reading…

And am loving it as well

Not Elixir. Try Programming Erlang or Erlang Programming for an intro to a gentler functional programming language, which will serve you well if you want to learn Elixir. Or, you can try Haskell until you get overwhelmed by the mathematical theory (do not even consider “Real World Haskell”!)

I’m not sure why Pragmatic Programmers offers a book called Elixir for Programmers when Programming Elixir 1.6 has a skill level rating of intermediate to expert.

They don’t have a book named Elixir for Programmers. Dave Thomas has a video course called that

Looking back at my own personal experience, I’m giving most of the credit to Clojure for busting my OO mindset. However knowing what I know now, I’d choose Racket instead (dealing with the JVM adds an unnecessary element of hassle - OK if you need it; otherwise avoid it). Some reasons for my opinion are detailed in these posts:

New to programming, how should I proceed in learning Elixir? - #18 by peerreynders

Will reading a Haskell book help adopt a functional programming mindset? - #9 by peerreynders

Opinions on Elixir vs. Clojure - #16 by peerreynders

One potential starting point is Realm of Racket as HtDP2e may feel a bit slow for an experienced programmer and SICP with DrRacket may be a bit academic (though Peter Norvig’s Amazon review is an entertaining read).

Then “practice” with something like exercism.io.

Once you feel that Racket has put a big enough dent in your OO mindset double back to Elixir with

Learn Functional Programming with Elixir (Pragprog)

at which point you should be much less tempted to approach Elixir in imperative/OO ways.

PS: Of course, you can try the pure Elixir path as already suggested - but I find that often a well established OO mindset needs to be approached with the equivalent of a baseball bat.

True story →

I’m sure most people here are too young to remember Jerry Pournelle. He was a science fiction author who wrote a column for Byte magazine for many years about his tinkering with computers. In my opinion, they started out as reasonable accounts of exploration by a hobbyist. But over the years they somehow morphed into an almost-knows-nothing guy annoyingly pretending to be an expert (boring accounts of tortuous feats of kludgery to avoid new-fangled tech).

Anyway, after the publication of SICP, there was a corkboard outside Sussman & Abelson’s offices covered with reviews of the book. In a place of honor, dead center with some space around it, was Pournelle’s review which stated “I didn’t understand a word of it.”

Wow I was not aware of this new edition of HtDP, pretty cool!

I also recommend SICP, in my opinion is one of the greatest books in CS. Another one that I like as an introduction to FP is Learn You a Haskell for Great Good.

1. What are you trying to achieve in learning functional programming ?
2. Will you be using Scheme, F#, OCaml, Haskell or Elixir/Erlang or another language ?

In some ways there are 3 levels of functional programming: recursions (and higher order functions), continuations and Functors/Monads. Continuations seem to have fallen out of favor in the recent years.

90% of the time knowing recursion and HOF is sufficient. In fact, most Erlang/Elixir code have minimal recursion instead relying on map/reduce/filter to perform most of the work. You do not need much to start functional programming in Elixir. A shameless plug Functional Programming in Elixir

Agreed, absolutely. I also recommend Abstraction & Specification in Program Design–another one that is about general principles and how to apply them, not about this or that specific language…

Tut-tut.. not so aggressive OO and functional programming have a lot in common. See f.e. what Erik Meijer says here:

I think what sometimes Erlang people say is that Erlang, for example, doesn’t have objects
or something they have actors or you send messages, but I would say, I like to look at 
languages and look at what is common instead of what is different, instead of saying 
“Erlang is different”, I look at Erlang and say “it’s really very similar to objects because if 
I send you a message, you’re an actor, you’re doing a pattern match on that message and
you have some internal state when you have a tail recursion that you can wait for the next 
message”. That’s really just like virtual dispatch, where the pattern match is just looking 
what is my dynamic type. And the parameter that you pass around, the internal state that 
you pass around in that tail recursive loop is like your instance variables. So I would say
there is more commonality than differences, so I would say Erlang has a lot of great properties, 
for example that’s very cheap threads then you can build amazing things because now you can 
use concurrency as a control structure but I would say it is really, for me and I think that’s a 
really positive thing, very close to object oriented programming and dynamic dispatch.

I’m primarily thinking about how class or object-based OO embrace mutability. Functional languages tend to be immutable by default - in BEAM languages one has to employ recursion to emulate mutable state which is used inside processes to give them mutable state.

Now traditional OO uses mutability at the lowest level and usually as a consequence mutability is everywhere. These days “mutability” is the new “goto”. In the past mutability wasn’t largely an issue because the technology we were working with limited us to unshared mutable data - but things got a lot more complicated when threads and multi-cores want and need to share data. Yet a lot of today’s mainstream technology is still rooted in the past world of “unshared mutable data”.

Mutability encourages PLOP (Place-OrientedProgramming) while immutability requires “Programming with Values” - that requires a major shift in mindset.

It is possible to work with immutable objects but it fundamentally changes the nature of methods (and how objects interact) - methods no longer “send a message to change the object’s internal state” but instead methods either return immutable parts of the object or return an immutable version of the original object that differs from the original in some specified way. Immutable objects are about values - not (internal) mutable state.