In my judgement Haskell as a first exposure to functional programming (FP) would be a mistake for most people.
Having to wrestle with recursion is par for the course with FP but with Haskell you also have to concurrently deal with purity, static type checking and laziness—all powerful stuff for sure—which can quickly ramp up the challenge to painful levels.
Clojure is what worked for me but I'd only recommend that to people who are already familiar with the idiosyncrasies of the Java ecosystem.
The point here is to internalize that just because something isn't easy doesn't mean it's difficult (just different) and that easy doesn't imply simple or vice versa. Simple doesn't complect while easy often does.
Michael Feathers
@mfeathers
OO makes code understandable by encapsulating moving parts. FP makes code understandable by minimizing moving parts.
15:27 PM - 03 Nov 2010
Fall back on this anytime FP feels different enough to seem difficult—you're just not familiar enough with it yet.
Imperative programming describes the "flow of control" (think flowcharts) where program execution moves computation forward by manipulating values in place (PLOP - Place-Oriented Programming)
Functional Programming advances computation by creating new values through the transformation of existing values (value-oriented programming). A functional program's description focuses on the "flow of values" (not to be confused with dataflow programming) rather than the "flow of control" .
I would go as far as saying that value-oriented programming is often what is meant when people talk about functional programming.
This paper makes the case that it is often easier to learn FP before imperative programming as opposed to the other way around. This could go some way towards explaining why people who became familiar with imperative programming first, claim that imperative programming is more natural—it really is a case of what you were familiar with first.
One language that has been extensively used to teach FP is Racket; together with something like the "The little Schemer" it can be used as an introduction moving towards value-oriented programming (Systematic Program Design).
Personally I found Erlang to be a good way to learn FP (syntax notwithstanding), unfortunately some learning opportunities seemed to have dried up. Elixir could be a good substitute as long as you are vigilant and not let its Ruby-ish syntax guide you to more imperative implementation patterns.
Elm has already been suggested—these days I would tend more towards ReScript as that can also be used server side. I'd combine it with an exercism track to become familiar with it.
I would vote for Elm over Rescript for learning functional programming basics. The backend Rescript landscape is very early days and I wouldn't take it into consideration when choosing between Elm and Rescript. For backend, I would learn more established backend functional languages as my first exposure to backend functional programming.
Thank you so much for the detailed answer! This clarified a lot of misconceptions about FP, I'll definitely look into all the resources provided, I was using functional programming without even knowing it, I now understand why it seems more readable, because it's more predictable. Thank you again for your time 🙏
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In my judgement Haskell as a first exposure to functional programming (FP) would be a mistake for most people.
Having to wrestle with recursion is par for the course with FP but with Haskell you also have to concurrently deal with purity, static type checking and laziness—all powerful stuff for sure—which can quickly ramp up the challenge to painful levels.
Clojure is what worked for me but I'd only recommend that to people who are already familiar with the idiosyncrasies of the Java ecosystem.
Exhibit A:
Transcript
The point here is to internalize that just because something isn't easy doesn't mean it's difficult (just different) and that easy doesn't imply simple or vice versa. Simple doesn't complect while easy often does.
Fall back on this anytime FP feels different enough to seem difficult—you're just not familiar enough with it yet.
Exhibit B:
Transcript
This highlights why FP seems so different:
Imperative programming describes the "flow of control" (think flowcharts) where program execution moves computation forward by manipulating values in place (PLOP - Place-Oriented Programming)
Functional Programming advances computation by creating new values through the transformation of existing values (value-oriented programming). A functional program's description focuses on the "flow of values" (not to be confused with dataflow programming) rather than the "flow of control" .
I would go as far as saying that value-oriented programming is often what is meant when people talk about functional programming.
The Structure and Interpretation of the Computer Science Curriculum
This paper makes the case that it is often easier to learn FP before imperative programming as opposed to the other way around. This could go some way towards explaining why people who became familiar with imperative programming first, claim that imperative programming is more natural—it really is a case of what you were familiar with first.
One language that has been extensively used to teach FP is Racket; together with something like the "The little Schemer" it can be used as an introduction moving towards value-oriented programming (Systematic Program Design).
That said both in Clojure and Scheme the parentheses can take some getting used to; for most people it just takes some determination and persistence.
Personally I found Erlang to be a good way to learn FP (syntax notwithstanding), unfortunately some learning opportunities seemed to have dried up. Elixir could be a good substitute as long as you are vigilant and not let its Ruby-ish syntax guide you to more imperative implementation patterns.
Elm has already been suggested—these days I would tend more towards ReScript as that can also be used server side. I'd combine it with an exercism track to become familiar with it.
An earlier, very similar comment of mine.
I would vote for Elm over Rescript for learning functional programming basics. The backend Rescript landscape is very early days and I wouldn't take it into consideration when choosing between Elm and Rescript. For backend, I would learn more established backend functional languages as my first exposure to backend functional programming.
Thank you so much for the detailed answer! This clarified a lot of misconceptions about FP, I'll definitely look into all the resources provided, I was using functional programming without even knowing it, I now understand why it seems more readable, because it's more predictable. Thank you again for your time 🙏