For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
Rachel Fazio -
dev.to staff -
Akash Pattnaik -
dev.to staff -
Top comments (38)
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.
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.:
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.
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!
Probably the more interesting question is why people pick up Functional Programming 60 years after Lisp was invented. Probably the hype of "new" languages like Rust and the atrocity of Javascript finally made people reconsider their options.
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.