I'm going to challenge you right there. First, note that using aspects of functional programming doesn't immediately necessitate you do nothing but functional programming and use nothing but "functional" languages.
Consider a piece of poorly refactored C++ spaghetti you've been tasked with understanding. The same variables mean different things at different times... code assuming vectors have the appropriate length, then later normalizing them in place, and then later yet changing their direction... state being repeatedly accumulated and adjusted in different branches... how do you start cleaning this code up to understand it?
One of the first things in my hat is to start using a more functional style. I sprinkle around the const keyword on local variables like a madman, helping catch all code with side effects to local temporaries. Variables are split in twain, with vectors and their normalized versions being forced to have different labels. But therein lies the advantage: I no longer have to track "x means y except after z when it means y2", but can drastically simplify to "x means y" -- something I can usually encode in the variable name, easing pressure on my feeble memory. Moreover, since the constants stick around, I can paint a better picture of "before and after" much more quickly than through the pinhole of stepping (usually in one direction only) through more procedural code, simply by slapping a breakpoint at the end.
While I'm still not using nor desiring to use functional languages as my bread and butter, integrating functional styles into otherwise procedural code quite frequently helps save my time and sanity outright, even on those occasions when it feels stilted and unnatural compared to the procedural versions.
I'm going to challenge you right there. First, note that using aspects of functional programming doesn't immediately necessitate you do nothing but functional programming and use nothing but "functional" languages.
Consider a piece of poorly refactored C++ spaghetti you've been tasked with understanding. The same variables mean different things at different times... code assuming vectors have the appropriate length, then later normalizing them in place, and then later yet changing their direction... state being repeatedly accumulated and adjusted in different branches... how do you start cleaning this code up to understand it?
One of the first things in my hat is to start using a more functional style. I sprinkle around the const keyword on local variables like a madman, helping catch all code with side effects to local temporaries. Variables are split in twain, with vectors and their normalized versions being forced to have different labels. But therein lies the advantage: I no longer have to track "x means y except after z when it means y2", but can drastically simplify to "x means y" -- something I can usually encode in the variable name, easing pressure on my feeble memory. Moreover, since the constants stick around, I can paint a better picture of "before and after" much more quickly than through the pinhole of stepping (usually in one direction only) through more procedural code, simply by slapping a breakpoint at the end.
While I'm still not using nor desiring to use functional languages as my bread and butter, integrating functional styles into otherwise procedural code quite frequently helps save my time and sanity outright, even on those occasions when it feels stilted and unnatural compared to the procedural versions.