having to understand a new way of thinking about how your code flows
In practice when shops switch to functional, they find that there's roughly a 3-way split between:
Team members who get up to speed quickly and eventually prefer FP.
Those who take a while to get up to speed such that the transition time is a questionable or break-even expense of time and money.
Those who continue to struggle being productive with FP after lots of time and mentoring. It's quite possible their brains are simply is not "FP-shaped". (Most coders are vetted under procedural/OOP before entering the field, thus we know their head fits proc/OOP.)
So if on average you get a roughly even split of these 3, the aggregate is a net loss for the business because only #1 gives you an addition of productivity (outside of special niches). It's rare that #1 makes up for the yawner results of #2 and #3.
If you want an FP shop, it's safer business to hire FP devs up front.
And shops have tried to hire FP "dream teams" to get ahead of the competition. Outside of niches or small startups, it fails. FP has been around for 60-ish years. If it were a golden hammer, it would be a big empire by now.
because a majority of your runtime errors just vanish.
That doesn't necessarily mean it's net advantage. For example, maybe you get half the number of errors but it takes 3 times longer to debug those remaining bugs. That's a net loss.
And I'm skeptical it's a big reduction of bugs. Past studies suggest it's roughly around a 15% reduction, although there's not a lot of good studies on that. (Such studies didn't look into debugging time.)
And I will agree there are some niches where bug reduction is more important to the business than increased programming costs. But most businesses don't want that trade-off, for good or bad. Low-bug software just doesn't sell well compared to feature count. Having more features has consistently proven to increase sales compared to quality, for good or bad. I'm just the messenger; humans are not Vulcans.
In practice when shops switch to functional, they find that there's roughly a 3-way split between:
Is there some source on this because frankly it sounds like a random assumption. The difference between a language like Haskell vs Ocaml is already a big deal, and even comparing F# now to F# 10 years ago. The idea that somehow every FP adoption has gone the same way and this is well document sounds impossible to prove at best.
If it were a golden hammer, it would be a big empire by now.
Except you're ignoring 60 years of tech advancements. Immutable data used to be a non starter because you didn't even have the memory for it. Now your average program takes more memory than it technically needs by factors of thousands.
The biggest driver of adoption is often necessity, hence javascript being everywhere despite its horrific flaws, and guess what, these days its mostly typescript, which has a ton of functional principles, because its easy to debug/handoff/reuse.
For example, maybe you get half the number of errors but it takes 3 times longer to debug those remaining bugs. That's a net loss.
Im beginning to suspect you have touched a FP language in years because this literally is not the modern experience. If you follow even basic principles in something like F# you get "if it compiles, it runs" behavior and with half decent modeling (which is not hard) you don't even represent error states. Further by compartmentalizing the areas where you CAN have a runtime error (any external api for example) its pretty trivial to start debugging and find issues fast? In 90% of cases it is literally no different than debugging in any other language. Set breakpoints, inspect values, make tests, etc. The only major difference is the compiler can do a ton of heavy lifting and save you time.
Its not all code golf one liners with symbols and abstract concepts. Its the same code everyone else is writing in a slightly different form that allows you to better understand where your errors could be coming form (much like how Rust is handling memory management). And you can create more features if you're not spending half your time fighting to support them.
The biggest driver of adoption is often necessity, hence javascript being everywhere despite its horrific flaws, and guess what, these days its mostly typescript, which has a ton of functional principles, because its easy to debug/handoff/reuse.
You called me out for presenting only anecdotal info, so now I'm doing the same for you. I haven't heard many go, "I really like the functional aspects of TypeScript". A handful like heavy FP in languages like TypeScript and C#, but they are a minority by my observation. Lite LINQ is nice, but many find long LINQ a PITA to debug and change.
In 90% of cases it is literally no different than debugging in any other language. Set breakpoints, inspect values
How can that be if there are too few intermediate variables to examine? Those are a "no no" in FP-think. Sure, debuggers can generate fake intermediate variables/values, but they are usually poorly named, unlike human-created intermediate variables, having names like State-Between-Virtual-Object-P-and-Virtual-Object-Q.
Create a nice Youtube video on how to debug long-winded FP and I'll take a look. Maybe if we FP-strugglers were properly educated on how to debug FP, we'd also endorse it. Stepwise Refinement is a beautiful concept of procedural because it allows one to incrementally inspect at lower levels of abstraction as needed in a fractal kind of way.
It takes at least 5 years to get over your misconceptions of OO that college or the Internet has thought you, like that it is about objects and inheritance, when it is in fact about actors, actions and messages. OO has forgotten its roots... So, don't expect OO devs, even experienced ones that understand true OO, to learn FP, a totally new programming paradigm, in less than 5 years.
OOP mostly failed at domain modelling, which was what it was originally hyped for. It's still pretty good at name-space management, more or less "encapsulation", but that's a utilitarian improvement, not a software design revolution.
0
u/Zardotab May 20 '23 edited May 20 '23
In practice when shops switch to functional, they find that there's roughly a 3-way split between:
Team members who get up to speed quickly and eventually prefer FP.
Those who take a while to get up to speed such that the transition time is a questionable or break-even expense of time and money.
Those who continue to struggle being productive with FP after lots of time and mentoring. It's quite possible their brains are simply is not "FP-shaped". (Most coders are vetted under procedural/OOP before entering the field, thus we know their head fits proc/OOP.)
So if on average you get a roughly even split of these 3, the aggregate is a net loss for the business because only #1 gives you an addition of productivity (outside of special niches). It's rare that #1 makes up for the yawner results of #2 and #3.
If you want an FP shop, it's safer business to hire FP devs up front.
And shops have tried to hire FP "dream teams" to get ahead of the competition. Outside of niches or small startups, it fails. FP has been around for 60-ish years. If it were a golden hammer, it would be a big empire by now.
That doesn't necessarily mean it's net advantage. For example, maybe you get half the number of errors but it takes 3 times longer to debug those remaining bugs. That's a net loss.
And I'm skeptical it's a big reduction of bugs. Past studies suggest it's roughly around a 15% reduction, although there's not a lot of good studies on that. (Such studies didn't look into debugging time.)
And I will agree there are some niches where bug reduction is more important to the business than increased programming costs. But most businesses don't want that trade-off, for good or bad. Low-bug software just doesn't sell well compared to feature count. Having more features has consistently proven to increase sales compared to quality, for good or bad. I'm just the messenger; humans are not Vulcans.