Ask Slashdot: Do You Like Functional Programming? (slashdot.org)

An anonymous reader writes: Functional programming seems to be all the rage these days. Efforts are being made to highlight its use in Java, JavaScript, C# and elsewhere. Lots of claims are being made about it's virtues that seem relatively easy to prove or disprove such as "Its use will reduce your debugging time." Or "It will clarify your code." My co-workers are resorting to arm-wrestling matches over this style choice. Half of my co-workers have drunk the Kool-Aid and are evangelizing its benefits. The other half are unconvinced of its virtues over Object Oriented Design patterns, etc.

What is your take on functional programming and related technologies (i.e. lambdas and streams)? Is it our salvation? Is it merely another useful design pattern? Or is it a technological dead-end?
Python creator Guido van Rossum has said most programmers aren't used to functional languages, and when he answered Slashdot reader questions in 2013 said the only functional language he knew much about was Haskell, and "any language less popular than Haskell surely has very little practical value." He even added "I also don't think that the current crop of functional languages is ready for mainstream."

Leave your own opinions in the comments. Do you like functional programming?

Comments

It has its uses

[RightwingNutjob]

but I'm skeptical about functional as the hammer for every nail. Generics and lambda expressions in C++ can make some niche problems disappear entirely by making the compiler do all the work for you, Scheme and Lisp and the like are useful for some very narrow and very academic use cases. As the go-to tool in the tool box? Not so much.

Re:It has its uses

[beelsebob]

There's two big things that have come out of the recent move towards more functional programming which are really important.

1) People are understanding that reducing the amount of state that any particular bit of code carries reduces the complexity of working with it. Less state means more testability, more easy reasoning about the code, more clarity, more easy debugging, and fewer edge cases to consider. That's not to say that you should never has state, as pure functional programming would have you believe, but reducing state dependance pretty much helps make your code better universally.

2) People are realising that inheritance is not the be-all and end-all of modelling code that the OOP world would have you believe. They're realising that inheritance is what screws up type systems, and makes them hard to work with. They're realising that deep inheritance hierarchies often lead to complex code which is tricky to understand exactly what code is going to execute when, and where you're going to jump to when you're reading it. Again - this isn't to say you should never use inheritance, but people are realising that composition can work equally well, or better, and that using it over inheritance has some substantial benefits.

As to the bandwagon of "write javascript, it's a functional language, that makes it brilliant". Fuck off... That's just yet another of the latest fads towards pascal on trains; nodeHaskell; and reactMonkey. I'll happily sit here continuing to write ancient languages, but trying to apply some of the concepts from FP to make my code simpler and more readable.

"Like"?

[eyenot]

I don't get what you mean by "like".

Procedures are procedures, period.

Sometimes it's helpful to have some procedure (or subroutine) store some value in some location before popping the stack.

What I really don't get in this write-up is the insinuation that a focus on (purely) functional programming is a "recent trend". That implies that the majority of today's coders have no fucking idea how coding has progressed through the last few decades (which I've been there to see firsthand).

That's the only interesting thing about this article.

It depends on the use

[nanolith]

Functional programming languages like Haskell, ML, and Gallina can be very beautiful. The problem is that they have a steep learning curve that has less to do with the syntax of the language and more to do with the semantics. If one is well versed in category theory or has spent a significant amount of time working with functor spaces, monoids, and monads, then it's much easier to understand a non-trivial application written in Haskell than the equivalent object hierarchy in an object-oriented language. The up-front cost is greater in terms of study and learning the semantics, but the end result is significantly more powerful.

I love functional programming. I went from C++ to Haskell and C as my go-to languages for personal projects. However, in my professional work, I tend to factor long-term language popularity into my decisions. So, I'm more inclined to use languages like Java, C#, Go, Python, and Ruby when I'm paid to write software. I have to consider the total cost of ownership in my professional work, and part of that cost is finding people to maintain it years from now.

I think that FP has an elegance that makes it a worthy model, and I hope that some day, FP becomes more popular than OOP. But, I'm old enough to understand that technical superiority rarely wins out to popularity. Popularity matters. This sort of calculus is one of the reasons why FP has not gained much traction despite all of the buzz.