I like differentiate the paradigms on a much more fundamental level:
Imperative programming describes the "flow of control" (think flowcharts) where program execution moves computation forward by manipulating values in place (PLOP - Place-Oriented Programming)
Object-Oriented Programming is a flavour of imperative programming where the "description" is partitioned into a set of classes, each responsible for the initialization of data instances (objects) while also collecting the functions (methods) relevant to the management of these data instances. Ideally these classes are"discovered" by exploring their collaborations and identifying their responsibilities (CRC).
While conceptually method calls are often seen as "an object receiving a message" what really is happening is that program execution (flow of control) moves computation forward along the method calls between collaborating objects whose behaviour is largely governed by their own mutable data.
Functional Programming advances computation by creating new values through the transformation of existing values (value-oriented programming). A functional program's description focuses of the "flow of values" (not to be confused with dataflow programming) rather than the "flow of control" .
When learning functional programming my personal advice is to avoid doing so in a multi-paradigm language - familiarity-bias will tend to push you towards solving problems in the way you already know how, undermining the learning effort.
Also in my observation when "learning to program" it seems to be easier to transition from functional to imperative rather than the other way around (which doesn't imply learning to program in a functional way is inherently harder - it's just that the imperative way of thinking can get in the way, so it has to be "unlearned" first).
For just gaining FP experience have a look at Racket. The 5 Student Languages of How To Design Programs 2e were created with it. It comes with the DrRacket Programming Environment. One warning though - it may initially require battling some parentheses-noia. Typically it's worth sticking with it - though occasionally the unthinkable happens (ultimately this lead to pyret being developed as a teaching language; DCIC). The Little Schemer, 4e; Realm of Racket
If you already have experience with the idiosyncrasies of the Java ecosystem then Clojure is another option. However the same "parentheses-phobia" caveat applies here. I would not recommend Scala as it suffers from the "multi-paradigm curse". In this particular case the community includes two factions: "I'd rather be programming in Haskell" vs "A better Java". It's beneath the former to deal with the code of the latter while the latter couldn't deal with the code of the former even if they wanted to - this is code written in one and the same language!
I imagine that the risk could be mitigated by working through Functional Programming In Scala but from what I've heard that is quite a slog (companion).
If you're interested in transpilation and don't mind fiddling with some tooling, check out ReScript. It's essentially OCaml dressed in JavaScript's clothes. Now OCaml has plenty of imperative escape hatches but it's pretty clear when you let the mantle of FP slide. Keep an eye open in case there is another run of the OCaml MOOC.
I like differentiate the paradigms on a much more fundamental level:
Imperative programming describes the "flow of control" (think flowcharts) where program execution moves computation forward by manipulating values in place (PLOP - Place-Oriented Programming)
Object-Oriented Programming is a flavour of imperative programming where the "description" is partitioned into a set of classes, each responsible for the initialization of data instances (objects) while also collecting the functions (methods) relevant to the management of these data instances. Ideally these classes are"discovered" by exploring their collaborations and identifying their responsibilities (CRC).
While conceptually method calls are often seen as "an object receiving a message" what really is happening is that program execution (flow of control) moves computation forward along the method calls between collaborating objects whose behaviour is largely governed by their own mutable data.
Functional Programming advances computation by creating new values through the transformation of existing values (value-oriented programming). A functional program's description focuses of the "flow of values" (not to be confused with dataflow programming) rather than the "flow of control" .
When learning functional programming my personal advice is to avoid doing so in a multi-paradigm language - familiarity-bias will tend to push you towards solving problems in the way you already know how, undermining the learning effort.
Also in my observation when "learning to program" it seems to be easier to transition from functional to imperative rather than the other way around (which doesn't imply learning to program in a functional way is inherently harder - it's just that the imperative way of thinking can get in the way, so it has to be "unlearned" first).
For just gaining FP experience have a look at Racket. The 5 Student Languages of How To Design Programs 2e were created with it. It comes with the DrRacket Programming Environment. One warning though - it may initially require battling some parentheses-noia. Typically it's worth sticking with it - though occasionally the unthinkable happens (ultimately this lead to pyret being developed as a teaching language; DCIC). The Little Schemer, 4e; Realm of Racket
If you already have experience with the idiosyncrasies of the Java ecosystem then Clojure is another option. However the same "parentheses-phobia" caveat applies here. I would not recommend Scala as it suffers from the "multi-paradigm curse". In this particular case the community includes two factions: "I'd rather be programming in Haskell" vs "A better Java". It's beneath the former to deal with the code of the latter while the latter couldn't deal with the code of the former even if they wanted to - this is code written in one and the same language!
I imagine that the risk could be mitigated by working through Functional Programming In Scala but from what I've heard that is quite a slog (companion).
If you're interested in transpilation and don't mind fiddling with some tooling, check out ReScript. It's essentially OCaml dressed in JavaScript's clothes. Now OCaml has plenty of imperative escape hatches but it's pretty clear when you let the mantle of FP slide. Keep an eye open in case there is another run of the OCaml MOOC.
Another one to watch for is Functional Programming in Erlang
This has to be one of the most most insightful replies I've read💯✨
Thanks for taking time to share your insights 🙏❤