Functional programming is a programming paradigm where programs are constructed by applying and composing functions.
Some of the most popular programming languages include Haskell, Clojure, Scala, Erlang, F#, Rust, etc.
Have you ever tried Functional programming?
Do you prefer it over Procedural or OOP paradigms?
What are some practical examples you have built with it?
Latest comments (58)
Scala is the only real solution for FP, other languages are either just mix and hence mess up with FP with OOP such as python or Javascript functional capabilities; or are pure functional and hence almost useless except in academia such as Haskell. But Scala under the hood, solved many problems, to become a practical object-functional language. Scala is not just a new syntax plus compiler, it's a collection of new ways to speak to computers, you will find any language phenomena in Scala and once you learn it, it will be canonical to your programming thinking.
I like FP. But on the other hand OOPs strong position in software development is not an accident. We have benefitted a lot from Encapsulation, Abstraction especially when many teams work on parts of large application. I still couldn't visualize the same happening with FP where 100s of developers work together for a product across multiple teams. Maybe it's because of my lack of experience with large projects on FP.
With OOP I think its easier to consume libraries without knowing too much detail under the hood. It could be one reason for the huge ecosystem that Java OR Dotnet produced.
However, more and more functional features will get into the mainstream languages like Java and C#. Already it's happening.
I think successful future languages will be combining the features of OOP and FP in right proportion. Success and adoption of Rust is an example. Rust makes a nice balance of OOP features and FP features.
Great insight, thanks 🙏❤
I don't know what it is? And why it is?
I haven't tried full-on functional programming with monads and using the effect type everywhere (like Redux actions, but everywhere).
However, I love "functional-light" programming. This means using function composition, point-free style, map/reduce, recursion and functional utility functions (like the ramda.js functions) where appropriate.
Other things like pure functions, decoupled code, parameterization, etc. are considered clean code whether you use FP or not. So functional programming didn't help me here.
I find it enhances my "normal programming", but doesn't replace it. Sometimes, imperative code is simpler and easier to understand than code using composition and recursion. In the end, that's the important thing. After all, imperative programming and functional programming are mathematically equivalent (so to speak), right?
Maybe after I practice Haskell and monads more I'll find functional programming much better. But that hasn't happened yet.
Thanks for sharing this insight 👍😉
Oop,is the best paradigm among all programming concept.
You can easily write code here, and if you have a good way of thinking in real life, you can develop algorithms in a great way by transferring them to coding.
Thanks for the input 👍😉
For example, whenever I want to write code or when I am stuck, I always think about how this happens in real life. Then with some of my software basics (variable,loops,arrays, and etc.) I pass them into code so I'm glad I wrote nice code and made something that works.
My pleasure
I am huge fan and I think every developer should learn it in a language that does it well so that we can become better programmers in all languages. Functional programming is easier to test, reuse, and reason about, according to John Hughes Why Functional Programming Matters. I agree. The more you stick to FP for a good deal of your code in a large codebase in an imperative language the easier these things will be too.
Thanks for the input 🙏❤
Functional programming is generally less performant and harder to debug. Functions are expensive unless inlined by compiler. OO is also unperformant due impart to its massive heap use and tendancy to over abstract. Procedural programming, when done properly, will always outperform the other two methods. In my experience, procedural programs are also easier to reason about, debug and maintain. People who flock to oo or functional styles seem to be simply trying to take shortcuts instead of developing a mastery of their craft.
It depends. Most compiled langs can be made performant enough, regardless of their paradigm. But you are correct that over-using certain parts of certain paradigms can certainly slow things down.
However, it's a difficult argument to be made against functional programming. Since the "recent" advancements in FP, from the last ~3 decades of bleeding edge research, has made FP incredibly fast. Haskell, the crown jewel of FP, is ridiculously fast. So much so that it is surprising to people who haven't used FP for a while. Since only a few decades ago - everyone knew that FP was very slow and inefficient.
The reason behind this sudden change, is clear. The papers written on this topic show a clear, strong, and impressive effort in making FP fast. They often lovingly call haskell "25 years of hard work" for papers like these, and it really shows. Incredibly passionate papers like these, demonstrating the strength of formal computer science in practice, is truly refreshing. The best part is that all of this is already implemented in GHC! And research is still ongoing towards greater horizons!
There's more examples of FP being fast other than Haskell (ex: Rust) but I think I've made my point. Moving on to debugging. I suppose it depends? The entire goal of FP is to make things easier to reason about by having formal and pure semantics. Most functions are functions in the same sense as mathematics. There's no tricks and traps. The goal of having "formal semantics" that is "clear to the programmer's eyes" is not unlike the goal of procedural programming. Both do a good job at having explicit semantics. But FP goes the extra way to make functions pure - which truly makes things easier to reason about.
But then, when it comes time to do some impure shenanigans - which is certainly necessary in any practical sense - It may get a bit hairy during debugging depending on what kind of code you write. I myself find it delightfully simple to find exactly what's wrong in my Haskell code compared to, say, my Java/Python/Typescript code. But I also know it is very easy to make non-pure Haskell code extremely difficult to debug (by using outdated concepts). But let's not forget that Haskell is a very extreme example. Many FP languages such as rust, the ML family, clojure actually make it just as easy to debug.
Procedural has the advantage of being foundationally simple with no tricks and traps, which I adore. There's a certain elegance in simplicity that I like. But FP also makes sure that its semantics, even the abstract ones, are explicit and clear - a steep contrast to OOP and its seed of inherent implicit mutability.
This is insightful 👍😉 thanks 🙏❤
Great insight! Thanks 🙏❤
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 🙏❤
I've been spending a lot of time lately working with Elixir. It's a really cool language, and it definitely has me thinking a lot more about recursion and immutability.
I haven't built anything big with it yet, but working in another paradigm has made me question the ways I've been writing code in other languages. I think my JavaScript has improved as a result of me learning Elixir.
Thanks for sharing 🙏❤
We use Elm: dev.to/lucamug/elm-6m8
Thanks for the share! It's an awesome read 👍📚
I use it all the time when creating DSLs with Kotlin. By having higher-level functions, extension function and lambdas with receivers, you can make some very cool syntax. I detail more about it here: theonlytails.com/blog/data-goblin
Thanks for the share! 🙏❤
For about a year I'm writing production Java code using style which I call Pragmatic Functional Java. As name suggests, it's based on FP concepts. In particular, monads are used to represent special states. The approach doesn't assume choosing one paradigm over the other. Instead it's a hybrid of FP and OO, where both paradigms complement each other.
Overall, approach works surprisingly well. Code is more readable and significantly more reliable.
Awesome insight, thanks 👍😉
Hi everyone,
I am Eben, I am new to programming and software engineering, I am keen and here to learn from the expert in the house. I am here to also learn the industry best practices.
Thanks
Welcome to DEV 🙏❤
Lots of awesome folks in this community 😉👍
I use FP pretty much exclusively now. But I don't use the category-based variety that is commonly observed in Haskell. What I use in F# is more like typed python. It is very straight-forward. Wrote about it here.
I am also interested in Clojure. I wish for some aspects of its map data structure in F#. I also like the elegance of everything being a list (its lisp-ness). In playing with it, I discovered that at times I need types in my programming. So I'm keeping an eye on Spec to see what happens after alpha. Also hoping Clojure will get ported to .NET Core or whatever MS calls it going forward. (It currently has a legacy .NET Framework port.)
Interesting insight 😉👍
Thanks for the share 🙏❤
Not per se, but I definitely use that paradigm a lot in the context of Vue. Computed properties are definitely an amazing new(-ish) way of rendering front-ends!
Thanks for the share! 🙏❤