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

[Dutch Gun]

Few "in the OOP world" (whatever that means) promotes inheritance as the end-all-be-all these days. I think that went out of style fifteen or twenty years ago. The notion of eschewing inheritance whenever possible has its own Wikipedia entry, and was described in detail in the famous "Design Patterns" gang of four book.

That being said, there's a time when reality can intrude on "theoretically" clean designs or programming paradigms. Functional programming and unit testing are things you don't see widely used in the videogame development world, at least that I've seen. Not all paradigms and patterns apply to all types of problems. Ultimately, I think that's the most valuable thing I've learned over time. Use the tools and techniques most appropriate to the problem at hand you're trying to solve. Religious wars over programming techniques and methodologies are for pedantic fools.

Re: It has its uses

[Anonymous Coward]

Lambdas are simple and nice. It's just overhyped and people get confused because hype generates fanboi noise that hide the actual facts.

One good use of Lambdas is to implement the GOF strategy pattern. You can do it without Lambdas, but it's really verbose and hard to read in Java due to the amount of interface and one time use classes and objects simply to define a processing strategy. Lambdas make it much more concise and simple.

Its important for frameworks to allow others to specify processing "strategies". Some frameworks like Spring use such techniques very extensively. When you use a framework you want others to write less code and reduce boilerplate, so people who write frameworks find Lambdas awesome. When I write frameworks and engines I get irritated by the sheer amount of boiler plate to do strategy pattern and comment the code so that people can understand my code. Good code should be self readable and strategy pattern on Java isn't readable to less savvy programmers.

For users of the frameworks it's just a few lines less code which they "cut and paste" anyway and many don't see why they have to spend time learning Lambdas so they can save a few lines here and there.

I think Lambdas are a good feature to make coding in Java more elegant. Coding elegance has a long pay off and inflict short term pain to change which is why people who don't understand hate it. They hate it even more at the level of hype something with so little immediate value gets forced fed to them.

I woul agree that if you have less than 5 years left in your coding career, Lambdas are a waste of time.... but hey think of the children!

Re:It has its uses

[Big Hairy Ian]

Religious wars over programming techniques and methodologies are for pedantic fools.

Us Pastafarians would disagree! We prefer to write Spaghetti Code :D

Dysfunctional programming

[FrankHaynes]

seem to be the prevalent choice on the web these days.

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

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

[Jeremi]

When I was learning about functional programming in college, I got about as far as learning about the avoidance of side effects, at which point I started asking myself, "how would one write a video game in an FP language if you're not supposed to e.g. update the player's on-screen position in response to a keystroke"? The answer I got was to either generate an entire new game-state for each update (which seemed unwieldy), or work around the problem using monads, which admittedly I never really understood. I went back to procedural programming since that looked like the more straightforward way to implement the kinds of programs I wanted to write.

My question now is, do people ever actually write video games using functional programming? And if so, how would an FP-based arcade-style video game realistically handle things like updating the state of the player and the monsters at 60fps, as the game progresses?

Hard stuff is, in fact, hard

[fyngyrz]

I would add to this that reducing the complexity by turning everything into separate functions tends to also increase what I call "opacity by non-locality."

Not only are some things hard, some things benefit from having the logic right there in front of your face; not in a header, not in some function elsewhere, not in a library.

Benefits in both comprehension, and so ease of construction, but also in execution time and smaller executables depending on just how smart the language is in constructing its own executables.