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

[thogard]

I see lambdas as the opposite end of the pendulum swing from the goto statement.

They have their place but they both lead to lots of confusion with poor coders who are trying to maintain very old code.

Re:It has its uses

[jandrese]

There is certainly value in reducing the amount of state you are managing, but too often it seem like Functional programmers are willing to declare it gone when they've just swept it under the rug. Sure you don't have a variable now, but instead you have the logic tied up in your stack. This is especially true when the language does pattern matches on the parameters to determine which function to call. In the end you have to keep track of that iterator somehow, and I tend to think something like a for loop tends to be clearer than looking through the function headers to figure out how the loop is initialized and when it terminates.

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.

Re:It has its uses

[dcollins117]

They have their place but they both lead to lots of confusion with poor coders who are trying to maintain very old code.

If you're using poor coders to maintain very old code then perhaps the choice of programming style is not your biggest problem.

"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's not that I want to brag I'm old...

[gwolf]

But it seems that I will.

Around ten years ago, I started writing a column for a magazine. My first article was precisely a way to use functional programming for "real" code, using a multi-paradigm language (Ruby).

I didn't jump on the Functional bandwagon first time I saw it; it took me around ten years to understand and embrace what it can do. So we are talking about 20 years of hype. At least.

I am far from proficiently thinking functionally, although I have used it for many interesting things. It is a cool, and very different, way to work. It can make many things faster and simpler, but if you completely bite the bullet and make it your dominant paradigm, it will kill your productivity (with many other things that are not best served by that paradigm.

It has a clear spot under your programmer belt. But it should not be The Only Way to approach a program - unless you are Truly One with the Tao.

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.

Wrong question

[gweihir]

The right question would be "Do you understand functional programming?". And when you see about 99% of all "coders" having no clue, then you could ask the rest why they invested the time.

Re:I like functions...

[mrchaotica]

Yes, it means your functions aren't allowed to have side effects (i.e., all parameters are passed by value and the only result is the value returned to the caller).

Personally, I like it because it's a good way to manage complexity -- kind of like the encapsulation of object-oriented programming, except applied to the verbs instead of the nouns.

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.

Re: Dysfunctional programming

[Anonymous Coward]

Your code must be clean and maintainable, otherwise you won't get shit done for long. You'll just have shitty code.

Re:Functional programming is trendy hipster garbag

[brantondaveperson]

Programming is about translating what you want a computer to do into a set of instructions that the computer understands that mean the same thing.

That is half of what programming is, at most. The other half is, at least, making that set of instructions easily understandable by another human being. Your code will be read thousands more times than it is written, and readability is far more important than your statement suggests.

Re:I couldn't get past "how do you write a game"?

[Dutch Gun]

As a professional videogame programmer, I can assure you that I haven't heard functional programming discussed much at work or among other peers in the industry. Videogames are giant, data-intense state machines, with lots and lots of state to track and manage. My feeling is that it's really not a great fit for functional programming. Traditional object-oriented programming is *heavily* used (C++ is the defacto industry standard language), because that's a reasonable and proven way to encapsulate complex, independently-operating entities into well-behaved packages of data + code.

It's the same reason that the industry doesn't extensively use unit testing for engines and game code (not broadly at least), which may surprise some programmers in other fields. The reason is simple: many game engine tasks can't be boiled down into simple algorithmic data transformations that can be checked and verified by a simple function. For instance, how would one write a unit test to ensure audio is playing correctly, or a graphic shader is working as intended, or a physics engine "looks" correct in realtime interactions? It's not really practical. Thus, videogames tend to rely on integration tests using QA team members to spot anomalies.

In short, not every programming paradigm can be effectively applied to every problem. That's not to say you *couldn't* write a game purely in a functional language, of course. I just don't think you'd be working to FP strengths.