I've been dabbling in functional programming for a couple years, for fun.
What I see as the big win of functional programming over object-oriented programming is immutability, recursion, succinct syntax, pattern matching, higher-order functions, code-as-data, separation of behavior from data, and referential transparency.
When I see functional programming done in C++, it makes me sad. The syntax is awkward, immutability in C++ isn't there, recursion is a non-starter, pattern matching can be very awkwardly mimicked with lambdas and traversing a selection vector, higher-order functions are anemic, code-as-data is extremely limited, separation of behavior from data requires strict discipline, as does referential transparency.
The biggest cons against functional programming is that it tends to have a much bigger memory footprint over C++, say anecdotally on average about x4. (Your mileage may vary, based on your particular program.)
I've looked at the various how to do functional programming in language XYZ (where XYZ is one of: C++, Swift, JavaScript, Rust, Scala, Lisp, Scheme, and others), and I'm disappointed in those languages compared to functional programming first functional programming languages like OCaml, Haskell, F#, or Elm.
Yes, I include Lisp and Scheme in the "bad list". I haven't tried Clojure which adds functional programming to Lisp. Lisp programmers who haven't used a functional programming language may have trouble grokking that sentence, since Lisp has the interesting position of being a general general purpose programmer's programming language. Lots of power there! And unlike C++ token substitution macros made by The Devil™, Lisp macros are magically awesome.
Applying functional programming techniques in non-functional programming languages doesn't seem like a big win, to me. Other developers in the language will probably consider the functional programming techniques to be non-idiomatic and out of place.
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.
I've been dabbling in functional programming for a couple years, for fun.
What I see as the big win of functional programming over object-oriented programming is immutability, recursion, succinct syntax, pattern matching, higher-order functions, code-as-data, separation of behavior from data, and referential transparency.
When I see functional programming done in C++, it makes me sad. The syntax is awkward, immutability in C++ isn't there, recursion is a non-starter, pattern matching can be very awkwardly mimicked with lambdas and traversing a selection vector, higher-order functions are anemic, code-as-data is extremely limited, separation of behavior from data requires strict discipline, as does referential transparency.
The biggest cons against functional programming is that it tends to have a much bigger memory footprint over C++, say anecdotally on average about x4. (Your mileage may vary, based on your particular program.)
I've looked at the various how to do functional programming in language XYZ (where XYZ is one of: C++, Swift, JavaScript, Rust, Scala, Lisp, Scheme, and others), and I'm disappointed in those languages compared to functional programming first functional programming languages like OCaml, Haskell, F#, or Elm.
Yes, I include Lisp and Scheme in the "bad list". I haven't tried Clojure which adds functional programming to Lisp. Lisp programmers who haven't used a functional programming language may have trouble grokking that sentence, since Lisp has the interesting position of being a general general purpose programmer's programming language. Lots of power there! And unlike C++ token substitution macros made by The Devil™, Lisp macros are magically awesome.
Applying functional programming techniques in non-functional programming languages doesn't seem like a big win, to me. Other developers in the language will probably consider the functional programming techniques to be non-idiomatic and out of place.