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
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:
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
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.
- 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
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”.
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.
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#.
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.
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.
Thank you both for the recommendation!
Language Lust - eh? Just came across this: Programming Languages, Part A
Well, maybe this book Bought it this month, god only knows when I’ll get around to reading it…
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 .