Could someone provide a learning path for functional programming for who came from oops background.? Thanks in advance
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 
7 Likes
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.
7 Likes
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.ā
3 Likes
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.
- What are you trying to achieve in learning functional programming ?
- 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
1 Like
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.
2 Likes
I started my path with Programming Elixir and I have to say that the first chapters gave me a really good introduction to Recursion, Pattern Matching and the use of Tuples.
The Functional Programming Fundamentals lectures from Erik Meijer do a really good job of explaining the foundations of FP usually making direct comparisons between Haskell and C#.
My day to day work requires C# and I have been very happily adapting concepts learned from Elixir into it. I recently hit a wall on āhow much moreā could I exploit C# as a FP language and Functional Programming in C# has been revealing. To an extent it feels like āC# the Good Partsā.
While I have personally not delved into Racket, it seems like it would be the best point of entry regardless of your previous experience. 
Seems like you are just about ripe to branch out into F#.
4 Likes
Yes! but I have been glancing too much at other languages and been delaying learning F# which I could maybe use regularly. 
This MOOC, thought by Erik Meijer, is pretty good (archived, but material is still available): https://courses.edx.org/courses/course-v1:DelftX+FP101x+3T2015/course/
It uses Haskell, so thereās an emphasis on static typing as well, but thatās hardly a drawback.
1 Like
This might be for you: https://fsharpforfunandprofit.com. Aside from anything else, Scott Wlashinās site has some excellent material on functional programming in general.
3 Likes
Thank you both for the recommendation! 
Language Lust - eh? Just came across this: Programming Languages, Part A
2 Likes
Well, maybe this book Bought it this month, god only knows when Iāll get around to reading itā¦
1 Like
ML and Racketā¦ everything Iām looking forward to cover the basics 
.
This looks really interesting, specially because it mentions:
New examples featuring the ARM and x86 64-bit architectures
Just wondering how the book reconciles a āhigh level languageā and the computerās architecture. I personally didnāt get āprogramming computersā until I learned Assembly and saw C being compiled into it, before that everything was so confusing 
.
