I'm curious to hear opinions from the community why is functional programming not more widely used, while it seems that adaption is increasing thanks to languages like Elixir; there is still the question of what is required for critical mass.
For further actions, you may consider blocking this person and/or reporting abuse
Oldest comments (19)
For one thing, OOP is still dominant in a ton of settings. People spend years learning OOP practices in college and bootcamps, so that's just what people use.
That could change if the institutions creating new programmers adapt their curriculum.
I've also read before that functional programming is really inefficient in most spaces. As computers have become more powerful, this is less of an issue, but it's still something people think about.
The institution impact is actually an interesting topic, now days with how fast the industry moves those programs can quickly become irrelevant, talking from personal experience; pretty much the bulk of what was covered when I was in university is no longer relevant or useful.
Efficiency
I know that used to be the case with purely functional programming languages, and I'm curious if with more modern languages or even iterations of older languages this efficiency problem still holds true.
In earnest I think there is a good case to advocate for functional programming, specifically for problems that are very data-centric.
Mostly adoption is driven by need. Many devs have checked out FP, probably in their language of choice, and like the idea but without a huge obvious benefit or need it solves, they'll stick with their existing paradigm.
I myself have picked up a few FP techniques in JS/TS but see no real benefit of full adoption. Still, I teach the concepts to new Jrs in the hope they'll use them when they simplify things.
I think many JS devs easily pick up .map() and .reduce() but find less benefit in full-on function composition techniques - at least on the server side.
Would you say that the language support and features is a big deciding factor here? There is a huge difference between applying some FP concepts and truly designing/implementing applications using FP
For example you can do FP with PHP, but with so many trade-offs and considerations that might make adoption very difficult and not really valuable for the developers.
The biggest factor for my team is the pressure of forward progress. The amount of time needed to teach a dev Haskell and a whole different approach to development isn't worth it from a business perspective.
On the other hand, I can teach any dev to use specific FP techniques in their existing languages in a couple hours.
Until there's a real use case where a fully FP language is the best and fastest tool for the job, or until some other languages become better at true FP development, this is where we land.
We could change this but it goes back to academia where we teach (incorrect) OOP as classical inheritance. It's hard enough to get Jrs to stop typing "class" or thinking in that way.
The beauty of software development is that there's more than one way to solve a problem. I think FP is a methodology like anything else - has its pros and cons, practitioners, skeptics, hard-line followers.
Personally, I tend to use a combination - OOP, FP, Procedural. Depends on the situation.
Probably because oop has a shallower learning curve, but also has limited depth; after a point it doesn't scale very easily.
Eventually people search for something different and find themselves looking at functional programming.
As other people have said it's not that anything is right or wrong, it's just what it is. And if you're trying to make FP more the norm at your workplace don't start with the theory; I think it's easier to just let people use something like ramda or just get started with something.
People are using FP all the time, without realizing it, and they're still productive. You don't need to know about Functors to do an
Array.map(), for example.Here's a great recent talk by Richard Feldman trying to answer this question: youtube.com/watch?v=QyJZzq0v7Z4
Amazing thanks for the link
I gave my students an introductory challenge to one of my courses in JavaScript which was to code the split method from scratch (without existing methods). Just for the sake of curiosity I did it in imperative, declarative and functional (recursive). JavaScript performances for the functional one were terrible. And I'm so sad to say that because I am a functional enthusiast. It is great that JavaScript tries to be a multi paradigm language but sometimes it is not for the best. Of course I'm talking about JavaScript here because it is my main language but there are some others that try to follow that path as well.
My main takeaway here is that just because the language can allow you to use a functional approach it doesn't necessarily mean it is well suited for that type of paradigm.
One of the reasons I have fell in love with elixir so much, is that seems just right in terms of performance, developer usability/happiness and size of the community.
Depends on how you define functional programming.
Elaborate, how would you define it? and is there a definition where you would say that is indeed the norm or at least more common than typically perceived?
I would define it as strictly based on lambda calculus e.g. referential transparency, immutability and no side effects (to do io you would be forced to use monads). There are not a lot of languages according to this definition. There are a lot of functional-ish languages. But not everybody would agree with this definition, that is why I'm asking
// , Why does it depend on how you define functional programming?
A good argument by Paul Chiusano: If Haskell is so great, why hasn't it taken over the world?.
Essentially most code is for interacting with the messy external world and FP isn't that much better compared to OOP and procedural.
Being primarily a problem-solver, I'm waiting for a problem that is best solved with FP. So far, all problems have been solved using other languages, techniques and paradigms. I'm open to FP and am slowly working through some FP languages on Exercism.
// , Much of it has to do, I suspect, with a person's ability to think mathematically.
Back when programming was more the province of mathematicians, scientists, and government researchers, the field attracted more people with higher levels of ability in deductive reasoning. These would be the kind of people for whom books like "Proving Programs Correct" would have few surprises for them.
I suspect that the popularity of the other kinds of programming languages may be related to a shift in demographics. Even the phrase "programming language" lends itself to more procedural thinking about code, rather than the older view of programming languages as a kind of low-context notation.
I'm disappointed to see you use the term "critical mass," because it seems to imply that this is something that may change seriously through marketing or developer advocacy. "Raising awareness" and all that...
I think that fundamental demographic changes will not be overcome by marketing, at least not in a span of time less than a decade, because the constraints on those changes are much "stickier".
I'll add a couple of rays of hope in this, though. The first is that CryptoCurrency requires formal verification. The second is the dark storm coming for the world of computer and data security in the coming decades, which wash out systems which will rely on "best" practices rather than mathematical proofs.
I can tell you this. It is not because OOP is "easier" by any means. I have hundreds of hours in learning all the different design patterns needed just to browse my organizations server repo. There are so many complex ways of approaching problems with OOP. Functional programing is pretty confusing especially if your coming from OOP which most are but just like with learning the countless design patterns, currying will come to you with some due attention. Looking at a lambda calc equation i believe is much more clear then peering over a diagram of how classes inherit and utilize composition.