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.

Re:It has its uses

[Z00L00K]

Strong typing with static declarations may seem to be cumbersome to many but the good thing with the strong static typing is that you get slapped already when compiling and not late during execution when an obscure obnoxious condition is fulfilled. Of course unit testing should capture even obscure obnoxious conditions but since not every test is updated when the code is updated then it's easy to miss.

However sometimes lambdas are also useful - but they shall be used with care. There's no golden solution that can capture everything, instead different parts of an application shall be implemented in different ways to get the most effective solution. It will of course mean that developers have to know more than one programming language and paradigm.

Re:It has its uses

[RightwingNutjob]

It ain't f'ing unnecessary. If it's a spaghetti or gotos it'll be a spaghetti of inheritances or a spaghetti of lambda's. At some point, the complexity of the task the program is executing requires complex code. Goto's can be done so that they're easy to understand. So can inheritance. So can lambda's. But you've got to be aware of the fact that some things are just plain hard to understand because they're hard, no matter how good of a communicator the programmer is.

"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.

Re:"Like"?

[lucm]

What I really don't get in this write-up is the insinuation that a focus on (purely) functional programming is a "recent trend".

There is a new area where functional programming does shine, and it's large scale analytics. Sometimes when you think about solving a specific problem, you can go about it in a few different ways, but almost every time if your solution later needs to be parallelized (i.e. running on a Hadoop cluster) the functional programming way will be easier to adapt.

For instance, let's imagine a situation where you have a small e-commerce website and the marketing team wants to know what are the most common sequences of pages visited by users. You could write a quick & dirty python script that parses the logs and creates a hash of every possible sequence, then you could use that to "rank" sequences by time, browser, location, etc. Or you can play the fancy card and use something like Petri nets in a map-reduce-ish kind of way. Both approaches work.

But then your small website becomes a big success, and grows and grows and grows, and one day your script runs out of steam. So you figure, let's run that bitch on a big Hadoop cluster. Well guess what, a script that is map-reduce friendly will be a lot easier to adapt for that.

I'm not saying every single situation warrants for this kind of thinking. But that qualifies as a kind of problem that is fairly new for mainstream programmers.

 

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.

Functional is useful when not pure

[PhrostyMcByte]

The best functional programming to me, is the kind being integrated into various primarily procedural languages. I use it daily in C# at work, and find it invaluable in performing complex transformations on data. Python, C#, etc. have the best of both worlds -- the choice to use whatever is best for your situation.

I'll expand further, maybe to start an interesting conversation because I'm sure someone will disagree: purely- or mostly-functional languages are the original hype-driven languages. A lot of people say they're amazing, but don't actually do anything useful with them. Sure, some are making great apps with them, but they're clearly the exception. At the end of the day most of the people I've talked to who preach about how awesome their favorite functional language is have only gone skin-deep. Their experience is limited to the academic or experimental, and has never gone into the practical.

The few times I've tried to really master these languages, I've been left with no epiphanies. I've found it extremely useful for some problems, like data processing mentioned above. But for most everything else, it doesn't get me anything useful. On some level it is nice having the flow of immutability -- it "feels" right, like you've discovered something special. The same way adding an extra layer of abstraction on top of something might feel. But when I'd look back on it and ask myself what I gained from having it, there's really very little to be found. It is, mostly, a dogma.