Programming with pure functions, sometimes known as Functional Programming. All that mathy stuff associated with FP is pretty cool for expressibility and reuse, but it pales in comparison to the value of just using pure functions for as much of the code as is reasonable. With pure functions testing is easy and refactoring becomes very low risk. (Thinking typed FP... not as familiar with untyped.)
This extends to the front-end as well. The Elm Architecture has really taught me a lot in this regard. We have done epic refactors of our code base, fixing early mistakes. And because Elm code is pure, it was a bit of work, but it wasn't risky.
Writing pure functions is an investment in the code base, but it returns big over time.
I don’t think it is short-sightedness as much as inertia. Even if you have felt the benefits first hand, writing pure functions can be really difficult with the tools/languages devs generally use. Most languages expect mutation as a foundational principle. Every line of code is expected to be a side effect. It is going against the grain to do otherwise. And the reason most of our tools are like this is just the happenstance of history’s unfolding.
So then once you resolve to use tools which normalize and expect pure functions, you then immediately have another crisis. You have no idea how to solve problems with pure functions. It’s just different at times.
So I think it is only natural that these difficulties prevent people from giving it a try. I only started to discover the benefits myself pretty recently in my career (6 years ago?). And it wasn’t until even more recently that I began to be able to articulate specifically how it helps.
Fortunately a lot of languages have incorporated functional features. So that helps toward the familiarity of solving problems functionally. For example C# LINQ is a significantly liked feature that is basically lifted straight from FP.
Anyway, i just think it’s hard to do in most of our tools. And changing tools plus learning different ways to solve common problems is too much change at once for most of our teams. It took me multiple tries. Maybe as our tools start to incorporate more FP ideas, as they seem to be doing, the barrier will get smaller.
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.
Programming with pure functions, sometimes known as Functional Programming. All that mathy stuff associated with FP is pretty cool for expressibility and reuse, but it pales in comparison to the value of just using pure functions for as much of the code as is reasonable. With pure functions testing is easy and refactoring becomes very low risk. (Thinking typed FP... not as familiar with untyped.)
This extends to the front-end as well. The Elm Architecture has really taught me a lot in this regard. We have done epic refactors of our code base, fixing early mistakes. And because Elm code is pure, it was a bit of work, but it wasn't risky.
Writing pure functions is an investment in the code base, but it returns big over time.
Is it possible that the average dev shop is just too short sighted to really buy into FP?
I don’t think it is short-sightedness as much as inertia. Even if you have felt the benefits first hand, writing pure functions can be really difficult with the tools/languages devs generally use. Most languages expect mutation as a foundational principle. Every line of code is expected to be a side effect. It is going against the grain to do otherwise. And the reason most of our tools are like this is just the happenstance of history’s unfolding.
So then once you resolve to use tools which normalize and expect pure functions, you then immediately have another crisis. You have no idea how to solve problems with pure functions. It’s just different at times.
So I think it is only natural that these difficulties prevent people from giving it a try. I only started to discover the benefits myself pretty recently in my career (6 years ago?). And it wasn’t until even more recently that I began to be able to articulate specifically how it helps.
Fortunately a lot of languages have incorporated functional features. So that helps toward the familiarity of solving problems functionally. For example C# LINQ is a significantly liked feature that is basically lifted straight from FP.
Anyway, i just think it’s hard to do in most of our tools. And changing tools plus learning different ways to solve common problems is too much change at once for most of our teams. It took me multiple tries. Maybe as our tools start to incorporate more FP ideas, as they seem to be doing, the barrier will get smaller.