Enough languages that are popular today have accrued important ideas from functional programming that the disparity is much lower now than it used to be. Going from C to Haskell is a big jump, but I was shocked at how similar Ruby and Common Lisp are. Even C++ and Java have lambdas now. JavaScript is popular and pervasive and has blatant roots in Scheme. Once you learn how to compose functional iterator methods like map, filter, etc, the inferiority of for loops becomes blatant (eg this is why I have little interest in go).
There are FP options these days that aren't shrouded in mathspeak. JavaScript calls it a "function" rather than a "lambda", Elm calls it "union types" rather than "algebraic data types" gist.github.com/evancz/06fe634245a...
FP has a basis in math, making it declarative and immutable. It turns out that most of the problems that most of us have with most of our programs simply disappear when we write code in a way that is congruent with this constraint. As evidence, I present the popularity of React.js
I think it's because state management is becoming one of the biggest issues in modern development. Debugging large applications with tons of distributed state is a huge challenge. Isolating and controlling state in a functional, immutable way makes this a much more manageable problem.
I'm getting into FP via Elm and Elixir. Both are quite accessible and have helpful communities. Elm is a gem, I think. Static typing and Elm architecture (not to mention whitespace, bracket forest-free environment, elm-format, helpful compiler and a good handful of other things) feel like a cure to the front-end madness. I'm still wrapping my head around Elixir, but -- damn -- is pattern matching nice :)
Because many programming problems are easier to model as a series of data transformations, as opposed to a set of mappings of real-world objects. React and Elm show that it's intuitive for creating stateful UI apps. Phoenix (Elixir's web framework) shows that a typical web app can be represented as a pipeline of functions transforming the received connection. We have chained functions (commands) on terminals for as long as I could remember.
What Josh Cheek mentioned really rings true for me: "FP has a basis in math, making it declarative and immutable. It turns out that most of the problems that most of us have with most of our programs simply disappear when we write code in a way that is congruent with this constraint."
Furthermore, over the years I've built very very large applications in a functional programming style, and I've found almost no need for class abstractions and inheritance.
Personally, I've really enjoyed Javascript. Objects, Arrays, and functions are all that's needed to build very expressive, bug-resistant, massive applications.
1) We now have machines with enough resources to support it.
2) People have begun to notice how much "best practice" software engineering is just complete and utter rubbish, and have latched onto functional programming in desperation, as if it could save them from the cesspools they helped create.
Many functional languages enforce usage of exactly the types a function needs with no implicit casting which makes it harder to make mistakes. I work in the .NET world and love F#. I heard that one team moved their business application from C# to F# and for 6 months got no bug report of any kind. That's how powerful FP can be.
The pushback I get from seasoned C# devs is that they don't know F# and FP. Or rather they don't want to invest in another language (let alone paradigm).
I've seen this before when VB/VB.NET developers didn't want to learn C# back 10yrs ago. Though this time around is more than just syntax.
I believe as more C#/OOP devs see FP/F#'s power, they will convert. I'm one of them. I've seen the light, and it's good.
FP knowledge is kind of universal. You can write pure code in just about any language.
The experience I herein describe is from my time with Haskell.
In FP you don't modify anything yourself, you just tell the compiler how to make convert data from type a to type b.
My mindset is that every program only converts some data into a different representation, be it input from the user and some database that is being converted into an HTML document or just some input that is converted to it's base64 representation.
Especially if you adhere to Unix philosophy you end up writing little "subprograms" that just do a simple job like base64.
FP then gives you a huge set of readily available functions to achieve exactly that.
It also forbids you to do anything impure, so you end up with small little functions that transform some a to some b and bs to cs. Then you just call them along the lines of foo(bar(baz)) and return the result to the user.
Why is this so popular you ask?
Well, it makes a lot of things disappear: race conditions, irreproducible behaviour, unintended side-effects just to name a few.
It also makes a lot of things easier.
There is for example the maintenance. You can easily replace a function that does not perform as it should and, once it works, it probably keeps on working forever.
How about testing? If you have a high unit-test coverage then you have actually tested everything that could go wrong because there are no side-effects in pure functions.
If you profile your application you see how long each function takes and how often it's called. This makes it easy to find a bad performing function and simply rewrite it, if possible, or reduce it's usage or the way it's used.
Adding a feature is as easy as adding the new functions and putting a call to them somewhere. You cannot break any of the existing parts of the program if you do not touch them due to the complete lack of side-effects.
Just for the FP people some corrections:
Yes, there are side effects, for example IO, but you either have some Monads do the job or abstract over them using e.g. the interact function in Haskell.
FP is super useful for distributed computing. Managing state across hundreds of servers is a nightmare and forcing devs to reduce state and side effects to the barest minimum turns out to work pretty well in this domain.
I think one reason functional language features are making their way into languages is just because they're shorter for a lot of situations! If a programmer is used to using functional features on lists, having to jump back into using for loops feels like such a hassle, so it makes sense that they would implement those features.
It's not all laziness though, it often goes with being more 'expressive', closer to a human explanation of what you're trying to do.
Some developers like to geek out on hard-looking FP concepts and then follow up with a talk describing what they learned (or think they learned).
This creates the appearance that the presenter is smart and therefore FP must be useful.
Having said that, I am intrigued by FP (I've been doing FP with Scala for almost 2 years) and I find it hard but addictive. I do believe FP is valuable and I want to know more!
FP is is a collection of simple, orthogonal concepts and rules that all work naturally together to model and solve problems in amazingly concise ways. The semantics of FP (and pure FP in particular) makes programs highly verifiable by a tool/compiler.
Others are doing great covering the actual practical reasons, which inevitably apply to some situations and not others. What applies universally is the psychology part of it, e.g.:
it's a shiny new toy (many of us fell in love with programming because of the joy of learning new concepts)
popularity is a positive feedback loop (gee, I'd better try to do something with FP because everyone seems to be talking about it)
egotistical programmers love explaining arcane concepts to all the plebs who've never heard of them (do you have a few minutes to talk about our Lord and Savior the Maybe Monad?)
those same egotistical programmers have convinced a fair number of people that it's a magical solution to all bugs (there's no side effects! sometimes side effects are accidental and cause bugs! remove all the side effects and there won't be any more bugs!)
My own reason for switching to Rust from C++ is a philosophical one: I believe that objects in reality do not have inherent functions. Functions are either emergent or they are imposed on the object. Since I don't program for a living and just as a hobby, I can code in whatever language I want to, after all.
So much of modern development boils down to receiving data from one system, transforming the data in some fashion and then passing it on to another system. FP is better suited to this than OOP because FP embraces data rather than trying to abstract it away all the time. Big ironclad static OOP languages like C++, C# and Java work well if you are writing a thick client in which you are in control of all the external interfaces, but in this world of microservices and REST APIs this kind of application is becoming increasingly rare.
In short, FP is not a silver bullet, it is just better than OOP for the kinds of problems we are trying to solve today.
Like it has been stated, FP is based much more on being a math language. That makes it Grade in the classrooms for teaching people how to write provable coding. We are getting to the point in our society where the kind of software we write cant really have mistakes, and proofing allows us to minimize errors to a much more acceptable level. Plus it stops people from using iteration over recursion, and that is OK in my book!
Parallel programing is a huge deal too: I'm working with analytics using Apache Spark + Scala over Hadoop, so FP it's not a option in my case.
I don't have the theorical basis of FP, but I really like the way code feels, much more organized using a functional aproach. Even using other tools, I pretend to mantain a functional aproacch whenever is possible.
Many people have mentioned about the multi-cores being a catalyst in encouraging the use of functional programming in the industry today. This is definitely one of the big motivating factors. But I think a more basic reason why FP is becoming more popular is the fact that we are developing more and more complex software these days and FP gives us the right tools to reason about our programs.
You can also learn a whole variety of programming languages here: hackr.io/
Using pure functional programming and decoupling the side-effecting parts of your program from the "pure" ones, you get the power to prove the correctness of your programs just like in mathematics. Richard Bird has written a great book Pearls of Functional Algorithm Design: Richard Bird: 9780521513388: Amazon.com: Books on this subject, where he mentions the following:
My aim in writing these particular pearls is to see to what extent algorithm design can be cast in a familiar mathematical tradition of calculating a result by using well established mathematical principles, theorems and laws.
This is the power of equational reasoning through composition of the powerful patterns of computation.
What's with all the unnecessary Rust hate? Rust borrows a lot from FP (algebraic data types, pattern matching, closures) while solving a novel problem (memory safety without a garbage collector).
I'm a functional programming convert because I've seen the benefits first-hand.
Professionally I've gone from C, to C++, to Java, to Scala and most recently to JavaScript. Typically over the lifetime of a project an ever increasing share of the engineering effort will be spent on maintaining the codebase and paying down technical debt, until adding new functionality grinds to a halt. However, one of the most complex projects I've worked on was in Scala, and it was virtually bug-free. As in, I could count the number of known bugs on one hand. In my experience, almost all bugs come from either 1) unintended side-effects, or 2) inconsistencies caused by duplication of state and data at runtime. By adopting side-effect free code and data immutability, you trade a bit of discipline and a new way of thinking for massively reduced complexity and increased reliability and testability.
I've come to realize you can apply functional programming principles in almost any language, even C, and modern JS is in fact a great language to do so in. As with all things, moderation is best and you don't have to buy into FP 100% to see the benefits of it. If you've done frontend JS before, just applying for example the principles of something like React+Redux (single source of truth, state is read only, state changes are through pure functions) you can easily see benefits in any moderately sized codebase.
My company decided to move to Scala (Akka + Spark) for the new products. We were super happy with our C#.NET stack (at least I thought so) and we had a lot of super bright engineer with plenty experience in the field. The move was very bold and it took us longer time than we expected from start to deliver.
For someone like me, with couple years of experience with JS/Python/C# it was super hard - I was finding myself being able to write maximum couple lines of code a day (super frustrating).
I believe, that modern approach of 'fast data' fully suits functional programming idea. There are lots of things I won't be doing with FP - like GUI apps (Desktop/Mobile), but it's super efficient for data processing when time to process can grow exponentially with amount of data.
This is a bit of a side comment. I did a lot of Java and Python development in the past (I still do a lot of Python). With regards to FP, you see some developments in the JVM world (Clojure being my favorite), but hardly anything in Python.
I am amazed on how FP is gaining roots on the JavaScript world (this includes languages that compile to JavaScript, like Elm). I would say that it has gained enough critical mass that it will stay (as enough people can see the advantages).
I still follow lots of Python stuff and it is impressive how some high-profile members of the community there still think FP is just a academic thing.
My point is that some of the most interesting things in elegant and high-quality software development are happening around JavaScript (even if not in JavaScript). Especially FP, but not only: think for example all the stuff around transpiling.
This is one of the reasons that while I am a very seasoned Python programmer, I decided to self-train into JavaScript. That was a bit surprising: just a couple of years ago, I would think it would be ridiculous that anything interesting would happen around JavaScript.
I wrote an article about this topic 6 months ago. It's not so much about what has changed with languages, but rather what has changed with the world that is driving adoption of functional programming. Functional programming uses immutable constructs, which are easier to reason about (for humans), and safer in terms of concurrency, and in general. Lots of other reasons - you can read about them in my article.
"Elixir - Erlang didn't change, the world did"
So what happened? The world changed, and continues to change:
Moore’s law ends,
I am sitting in front of a 16 core SMP computer,
It has more memory than I could ever use,
It is fast,
I am writing simple networked services,
Reliable code, not just features, differentiates,
Scalability is standard, and not special.
A lot of people think that object oriented programming is dead and the future is functional programming. I would understand that. Functional programming does have some very nice features such as pure functions. This allows developers to write safer code and works very well with concurrency. Many OOP language recently adopted various aspects for functional programming such as C++ and Java's Lambdas for they make writing certain parts of applications much easier. So it seems that functional programming can co-exist with other paradigm, which is good. This gives programmers more flexibility and design choices.
So why is functional programming gaining popularity? Because it allows developers to model their application in a different manner and write safer code thanks to their persistent data types.
Cause we are getting bored of OOP, objectifying the world etc.. FP is like a breath of fresh air. Haskell is a bit hardcore for myself but I've found functional JS to be pretty tasty
I think it's because state management is becoming one of the biggest issues in modern development. Debugging large applications with tons of distributed state is a huge challenge. Isolating and controlling state in a functional, immutable way makes this a much more manageable problem.
Bingo! :-)
I'm getting into FP via Elm and Elixir. Both are quite accessible and have helpful communities. Elm is a gem, I think. Static typing and Elm architecture (not to mention whitespace, bracket forest-free environment, elm-format, helpful compiler and a good handful of other things) feel like a cure to the front-end madness. I'm still wrapping my head around Elixir, but -- damn -- is pattern matching nice :)
Because many programming problems are easier to model as a series of data transformations, as opposed to a set of mappings of real-world objects. React and Elm show that it's intuitive for creating stateful UI apps. Phoenix (Elixir's web framework) shows that a typical web app can be represented as a pipeline of functions transforming the received connection. We have chained functions (commands) on terminals for as long as I could remember.
What Josh Cheek mentioned really rings true for me: "FP has a basis in math, making it declarative and immutable. It turns out that most of the problems that most of us have with most of our programs simply disappear when we write code in a way that is congruent with this constraint."
Furthermore, over the years I've built very very large applications in a functional programming style, and I've found almost no need for class abstractions and inheritance.
Personally, I've really enjoyed Javascript. Objects, Arrays, and functions are all that's needed to build very expressive, bug-resistant, massive applications.
Immutability makes everything easier as well.
1) We now have machines with enough resources to support it.
2) People have begun to notice how much "best practice" software engineering is just complete and utter rubbish, and have latched onto functional programming in desperation, as if it could save them from the cesspools they helped create.
I know I should not but I completely LOLd at this.
Many functional languages enforce usage of exactly the types a function needs with no implicit casting which makes it harder to make mistakes. I work in the .NET world and love F#. I heard that one team moved their business application from C# to F# and for 6 months got no bug report of any kind. That's how powerful FP can be.
I've heard similar stories.
The pushback I get from seasoned C# devs is that they don't know F# and FP. Or rather they don't want to invest in another language (let alone paradigm).
I've seen this before when VB/VB.NET developers didn't want to learn C# back 10yrs ago. Though this time around is more than just syntax.
I believe as more C#/OOP devs see FP/F#'s power, they will convert. I'm one of them. I've seen the light, and it's good.
FP knowledge is kind of universal. You can write pure code in just about any language.
The experience I herein describe is from my time with Haskell.
In FP you don't modify anything yourself, you just tell the compiler how to make convert data from type
ato typeb.My mindset is that every program only converts some data into a different representation, be it input from the user and some database that is being converted into an HTML document or just some input that is converted to it's base64 representation.
Especially if you adhere to Unix philosophy you end up writing little "subprograms" that just do a simple job like base64.
FP then gives you a huge set of readily available functions to achieve exactly that.
It also forbids you to do anything impure, so you end up with small little functions that transform some
ato somebandbs tocs. Then you just call them along the lines offoo(bar(baz))and return the result to the user.Why is this so popular you ask?
Well, it makes a lot of things disappear: race conditions, irreproducible behaviour, unintended side-effects just to name a few.
It also makes a lot of things easier.
There is for example the maintenance. You can easily replace a function that does not perform as it should and, once it works, it probably keeps on working forever.
How about testing? If you have a high unit-test coverage then you have actually tested everything that could go wrong because there are no side-effects in pure functions.
If you profile your application you see how long each function takes and how often it's called. This makes it easy to find a bad performing function and simply rewrite it, if possible, or reduce it's usage or the way it's used.
Adding a feature is as easy as adding the new functions and putting a call to them somewhere. You cannot break any of the existing parts of the program if you do not touch them due to the complete lack of side-effects.
Just for the FP people some corrections:
Yes, there are side effects, for example IO, but you either have some Monads do the job or abstract over them using e.g. the
interactfunction in Haskell.FP is super useful for distributed computing. Managing state across hundreds of servers is a nightmare and forcing devs to reduce state and side effects to the barest minimum turns out to work pretty well in this domain.
I think one reason functional language features are making their way into languages is just because they're shorter for a lot of situations! If a programmer is used to using functional features on lists, having to jump back into using for loops feels like such a hassle, so it makes sense that they would implement those features.
It's not all laziness though, it often goes with being more 'expressive', closer to a human explanation of what you're trying to do.
Some developers like to geek out on hard-looking FP concepts and then follow up with a talk describing what they learned (or think they learned).
This creates the appearance that the presenter is smart and therefore FP must be useful.
Having said that, I am intrigued by FP (I've been doing FP with Scala for almost 2 years) and I find it hard but addictive. I do believe FP is valuable and I want to know more!
FP is is a collection of simple, orthogonal concepts and rules that all work naturally together to model and solve problems in amazingly concise ways. The semantics of FP (and pure FP in particular) makes programs highly verifiable by a tool/compiler.
Others are doing great covering the actual practical reasons, which inevitably apply to some situations and not others. What applies universally is the psychology part of it, e.g.:
My own reason for switching to Rust from C++ is a philosophical one: I believe that objects in reality do not have inherent functions. Functions are either emergent or they are imposed on the object. Since I don't program for a living and just as a hobby, I can code in whatever language I want to, after all.
So much of modern development boils down to receiving data from one system, transforming the data in some fashion and then passing it on to another system. FP is better suited to this than OOP because FP embraces data rather than trying to abstract it away all the time. Big ironclad static OOP languages like C++, C# and Java work well if you are writing a thick client in which you are in control of all the external interfaces, but in this world of microservices and REST APIs this kind of application is becoming increasingly rare.
In short, FP is not a silver bullet, it is just better than OOP for the kinds of problems we are trying to solve today.
Like it has been stated, FP is based much more on being a math language. That makes it Grade in the classrooms for teaching people how to write provable coding. We are getting to the point in our society where the kind of software we write cant really have mistakes, and proofing allows us to minimize errors to a much more acceptable level. Plus it stops people from using iteration over recursion, and that is OK in my book!
I have started writing a series of blogs which describes advantages of functional programming. If you are interested you can visit the link here.
Would you like to cross-post your articles on dev.to?
Sure. I have posted my article on dev.to as well. You can visit it here
Parallel programing is a huge deal too: I'm working with analytics using Apache Spark + Scala over Hadoop, so FP it's not a option in my case.
I don't have the theorical basis of FP, but I really like the way code feels, much more organized using a functional aproach. Even using other tools, I pretend to mantain a functional aproacch whenever is possible.
Many people have mentioned about the multi-cores being a catalyst in encouraging the use of functional programming in the industry today. This is definitely one of the big motivating factors. But I think a more basic reason why FP is becoming more popular is the fact that we are developing more and more complex software these days and FP gives us the right tools to reason about our programs.
You can also learn a whole variety of programming languages here: hackr.io/
Using pure functional programming and decoupling the side-effecting parts of your program from the "pure" ones, you get the power to prove the correctness of your programs just like in mathematics. Richard Bird has written a great book Pearls of Functional Algorithm Design: Richard Bird: 9780521513388: Amazon.com: Books on this subject, where he mentions the following:
My aim in writing these particular pearls is to see to what extent algorithm design can be cast in a familiar mathematical tradition of calculating a result by using well established mathematical principles, theorems and laws.
This is the power of equational reasoning through composition of the powerful patterns of computation.
What's with all the unnecessary Rust hate? Rust borrows a lot from FP (algebraic data types, pattern matching, closures) while solving a novel problem (memory safety without a garbage collector).
The "hype" around Rust is completely warranted.
I'm a functional programming convert because I've seen the benefits first-hand.
Professionally I've gone from C, to C++, to Java, to Scala and most recently to JavaScript. Typically over the lifetime of a project an ever increasing share of the engineering effort will be spent on maintaining the codebase and paying down technical debt, until adding new functionality grinds to a halt. However, one of the most complex projects I've worked on was in Scala, and it was virtually bug-free. As in, I could count the number of known bugs on one hand. In my experience, almost all bugs come from either 1) unintended side-effects, or 2) inconsistencies caused by duplication of state and data at runtime. By adopting side-effect free code and data immutability, you trade a bit of discipline and a new way of thinking for massively reduced complexity and increased reliability and testability.
I've come to realize you can apply functional programming principles in almost any language, even C, and modern JS is in fact a great language to do so in. As with all things, moderation is best and you don't have to buy into FP 100% to see the benefits of it. If you've done frontend JS before, just applying for example the principles of something like React+Redux (single source of truth, state is read only, state changes are through pure functions) you can easily see benefits in any moderately sized codebase.
My company decided to move to Scala (Akka + Spark) for the new products. We were super happy with our C#.NET stack (at least I thought so) and we had a lot of super bright engineer with plenty experience in the field. The move was very bold and it took us longer time than we expected from start to deliver.
For someone like me, with couple years of experience with JS/Python/C# it was super hard - I was finding myself being able to write maximum couple lines of code a day (super frustrating).
I believe, that modern approach of 'fast data' fully suits functional programming idea. There are lots of things I won't be doing with FP - like GUI apps (Desktop/Mobile), but it's super efficient for data processing when time to process can grow exponentially with amount of data.
This is a bit of a side comment. I did a lot of Java and Python development in the past (I still do a lot of Python). With regards to FP, you see some developments in the JVM world (Clojure being my favorite), but hardly anything in Python.
I am amazed on how FP is gaining roots on the JavaScript world (this includes languages that compile to JavaScript, like Elm). I would say that it has gained enough critical mass that it will stay (as enough people can see the advantages).
I still follow lots of Python stuff and it is impressive how some high-profile members of the community there still think FP is just a academic thing.
My point is that some of the most interesting things in elegant and high-quality software development are happening around JavaScript (even if not in JavaScript). Especially FP, but not only: think for example all the stuff around transpiling.
This is one of the reasons that while I am a very seasoned Python programmer, I decided to self-train into JavaScript. That was a bit surprising: just a couple of years ago, I would think it would be ridiculous that anything interesting would happen around JavaScript.
I was wrong.
I wrote an article about this topic 6 months ago. It's not so much about what has changed with languages, but rather what has changed with the world that is driving adoption of functional programming. Functional programming uses immutable constructs, which are easier to reason about (for humans), and safer in terms of concurrency, and in general. Lots of other reasons - you can read about them in my article.
"Elixir - Erlang didn't change, the world did"
So what happened? The world changed, and continues to change:
Moore’s law ends,
I am sitting in front of a 16 core SMP computer,
It has more memory than I could ever use,
It is fast,
I am writing simple networked services,
Reliable code, not just features, differentiates,
Scalability is standard, and not special.
tomjoro.github.io/2017-01-31-world...
A lot of people think that object oriented programming is dead and the future is functional programming. I would understand that. Functional programming does have some very nice features such as pure functions. This allows developers to write safer code and works very well with concurrency. Many OOP language recently adopted various aspects for functional programming such as C++ and Java's Lambdas for they make writing certain parts of applications much easier. So it seems that functional programming can co-exist with other paradigm, which is good. This gives programmers more flexibility and design choices.
So why is functional programming gaining popularity? Because it allows developers to model their application in a different manner and write safer code thanks to their persistent data types.
Because of Javascript, I think.
And people like the advantages like being able to avoid doing things that you aren't supposed to happen because of function purity and immutability.
And lastly, because it's cool! :tada:
Also, it's data-driven. It's focused on the flow of the data. And you know all the craze about data science these days.
Cause we are getting bored of OOP, objectifying the world etc.. FP is like a breath of fresh air. Haskell is a bit hardcore for myself but I've found functional JS to be pretty tasty
Everything else in computing from the 70s is coming back in style with a new wrapper, so why not? ;)
Mainly because it's now very underrepresented and underused,and slowly rises where it should be,on the same parity as OOP.
Is it because devs are tired of being guilt-tripped for not following OOP best practices?
Because a lot of us miss PHP3.