A very common question I get from experienced programmers is "What does an FP language give me that I don't already have? Can't I just do FP in my language?" This is a great question and I hope I have an equally great answer.
I really sympathize with this question. JavaScript has map, filter, and reduce. Java 8 has the stream library. It seems like every language is adding more and more functional features, including immutable data structures, first-class functions, function composition, destructuring, and sophisticated type systems.
And I agree: You can do Functional Programming in any language.
Functional Programming is just another paradigm. So just like you can do Procedural Programming in any language, or you can do Object Oriented Programming in any language, or Logic Programming in any language, you can do Functional Programming in any language.
But wait. That answers the question, but does it answer the deeper assumptions behind the question?
So let me ask you this: can I do OOP in C? According to my statement above, the answer is "yes". In fact, I've built small object systems in C before. So why would I need an OO language if I can do it in C? I feel like my object system gave me all of the advantages I needed to do OOP. But here's the thing: could I have programmed OOP in C without already knowing OOP? I don't think so.
These paradigms are called paradigms because they are wholistic perspectives about how to approach problems. OOP breaks problems into objects that communicate with messages. FP breaks problems down into data that represents the state of the process being modeled. Procedural breaks a problem into a series of steps that can solve the problem. Each paradigm has a different approach to solving problems. By "doing FP in Java" without already mastering FP, you're implying that FP isn't a paradigm, it's just a set of features (immutable data, pure functions, function composition, etc).
I've seen it many times. People say they're doing FP in JavaScript. What they mean is they sprinkle reduce and map around and they use some pure functions. There's a lot of value in that. But otherwise their code is procedural. They have not learned the paradigm, only the features.
The value of a language that strongly enforces a paradigm is that it immerses you in that approach to solving problems. The more it enforces the paradigm, the more you are forced to attempt solutions using that paradigm. The more functional your language, the more training you get in approaching problems in a functional way. The same goes for OOP and Procedural. In essence, you get more practice because you can't rely on the other paradigms you already know.
So let me say this, more controversial statement: outside of languages labeled functional (Clojure, Haskell, Elm, Scala, Erlang, etc.), I don't see much depth in the functional programming being done. Unless they're already familiar with functional programming by working for a long time in a functional language, programmers are borrowing only little bits of the FP paradigm and missing the best part, which is the change in perspective on approaching problems.
That's not to say it's not possible to learn real FP in JavaScript. But it will take lots of discipline and help. The language won't guide you. You'll need to guide yourself or find someone who will guide you.
Conclusions
All of the paradigms are great because a "point of view is worth 80 IQ points". You can do any paradigm in any language. But it is very hard to learn a paradigm without immersing yourself. And it's hard to immerse yourself in a paradigm without using a language that strongly encourages the paradigm. Until you do that, you might be borrowing features of the paradigm, but you're not approaching the problem in a new way. In short, Functional Programming is not a set of features. If you want to learn it, jump in the deep end and be immersed.
If you're ready to take a dive, please check out PurelyFunctional.tv where I teach Clojure and functional programming.
Rock on!
Eric
Top comments (11)
Elm is a good one to get your feet wet too (and develop HTML5 UIs in the process). Because all your Elm code is purely functional, refactoring is quite safe... make your changes and then fix all the compiler errors, and it probably just works. This reduces the penalty for early mistakes.
Elm is awesome for learning functional programming!
I really want an excuse to use Elm in a real-world context. Still haven't needed it, but still excited about the language.
It's good for applications, maybe less so for content-based websites. (Based on your preact post and concern with deployed size.) Give it a try for some internal tools and see what you think.
I've found that where the difficulty lies in Elm is backwards from most UI frameworks. Most of them are easy/moderate to get going, but become increasingly hard to maintain over time. Elm requires a little bit more effort to get started up front (adjusting to FP mainly), but maintenance difficulty doesn't increase much over time. Maintenance is still work, but not particularly risky work.
We use it production, both internal and customer-facing.
Having many different ways to solve a problem comes with great amount of expertise needed to pick the best one.
I need to try Clojure once more :) Thank you for the reading!
I couldn't agree more! You're welcome!
Yes. You can do it in Go also as it supports closures.
you should have just said "yes" 😂
What a blog that would be! Maybe we could start a new social network where we answer yes or now questions. The UI to answer is just 2 radio buttons. ;)
Yes, programming paradigms are not the same as programming languages. I've been writing a lot about this lately over at mortoray.com/topics/paradigms/
I will read it :) Thanks.