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

Scala

[Anonymous Coward]

I prefer to use functional programming where it makes sense (most of the time). One reason I like Scala is that it's not pure. You can always write a for loop if you need to. Haskell, is a bit less forgiving.

Re:My answer

[ewibble]

yes,

OK a bit more detail, there are advantage to not having state, or at least making the system deal with it it lead to some really elegant code.

Just like most languages it has it limits, mainly input and output.

I have used haskell and I think it has some really good concepts but is plagued by people using being to terse and cryptic, 1 character names for types are not good yes you can work out what it is doing but you shouldn't have to, and the use of random definable operator like '' makes it unreadable without a reference manual for beginners. A part of good code is being clear, being cleaver isn't usually as important as being understandable. At least the uses I have seen generally been quite cryptic.

If the haskel community want haskel to popular they should make an better effort to make it more understandable.

What is functional programming?

[corporate zombie]

Wow. Really?

Functional programming.

1. Prefer non-mutable data. No more action at a distance bugs. Hand off a reference to your data structure and don't have to care. Replay any data transform at any point as a unique structure.
2. Prefer a defined and well known API often involving transforms that take a function as an argument to provide the predicate (e.g., filter), transform (e.g., map), aggregation (e.g., foldLeft/Right), or whatever building block.
3. Prefer data structures that you can reason about based on a well-known set of patterns. (Best quote ever: "You say `patterns' and everyone is warm and fuzzy. You say `monad' and every loses their f-ing minds.)

Given (2) in a language you'll often see in a language that functions are first-class data.

Functional programming is just (a set of) best-practices. It's scary when the big words are new. Once you use it a bit you'll wonder why when you say, "use a flatMap", folks freak out because all you've said is, "You are transforming the elements of some container into values that are themselves an instance of the same container but you want to flatten everything back from nested containers. [E.g., Container is C with element type A; thus C[A]. You've run a transform that will create C[C[A]] but want to end up with C[A] at the end]." Now you could say that second part but that's a lot of words. Because of points (2) and (3) above we just say, "use a flatMap" (or however you spell `bind` in your language of choice).

Nothing to see here. Please move along. (And yes. I like functional programming. A lot.)

It is great, just don't make a religion out of it

[jma05]

All programming paradigms have useful abstractions to offer. Eventually, they will all come together. Object orientation is great, until one overdoes it in design pattern hell. Likewise with functional programming. There are great many ideas in academic programming languages that will be made more accessible and integrated into mainstream programming languages. Functional programming is a dead end only in the sense SmallTalk was a dead end. People may not use SmallTalk much today, but its ideas live on in nearly every language we use today. Functional programming is here to stay. It won't replace imperative and object-oriented programming, but will add to them.

First and foremost, programming languages are for people, not computers. So if regular programmers who form the bulk of the workforce can't grok them, the languages need to be fixed, not people. Haskell is too hard for most. But it has many wonderful ideas that can be distilled into simpler forms and adopted and integrated elsewhere. Python got list comprehensions from it and perhaps the indentation.

C# is absorbing some features and Java is doing that less elegantly. Scala is a good balance and has already established itself. But people still find the type system complicated. So there are attempts to bring forth a simpler Scala - Kotlin, Ceylon etc.

We all agree that things like compact syntax, first order functions, lambdas, streams, type inference etc that functional languages pioneered, belong in every language. We still haven't sorted out how to make more advanced type systems, provability, strict programming without side effects etc more approachable. We should not need to have this much trouble explaining what a monad is or isn't. We'll get there, eventually.

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?

Re:It depends on the use

[nanolith]

I don't disagree with your assessment. However, if your assessment is valid, then a functional language is still going to be quite foreign to someone who has only been taught object-oriented programming. I agree that we can go deep down the rabbit hole with OOP as well. The minimal interface that has been extracted from the science behind OOP and introduced to programmers in general is a mere shadow of the works of folks like Barbara Liskov.

FP has yet to have this generational winnowing. It is still fresh and academic. We can build people up to understand this, or we can pull these concepts down to their most basic versions that are still useful. I suspect that both will have to happen before the industry can meet in the middle with FP. We are seeing this happen already as mainstream languages are adopting bits and pieces of functional concepts. I think it's more likely that we will see functional applications of OOP, such as in languages like Scala, than OOP superseded by FP. That's okay. There are already plenty of examples of non-mutable objects with copy-on-write semantics. We are seeing functions treated more and more like first-class objects. There are examples of the FP-as-style movement taking off.

I believe that we should teach higher math in high school and even as a requirement for engineering or information systems disciplines. Currently, most universities top out bachelor degree seeking students specializing in these disciplines to calculus, differential equations, and linear algebra if they are lucky. It would be nice to see abstract algebra and some category theory taught as well. When I advise people genuinely interested in pursuing software development as a career, I strongly recommend that they minor in mathematics so they can have the opportunity to take these more advanced classes.

That being said, there's nothing that prevents people from studying this for self-improvement. Learning either or both OOP and FP will fundamentally change the way that one organizes software. I'd love to see high school kids exposed to these concepts and the mathematics behind them. Then again, I'd also love to see high school kids taught how to build their own CPUs from 74-series logic ICs. Understanding the theory of computation at an intuitive level will do incalculable good for most of these kids through the rest of their careers. If I were to teach a class to high school level students, it would be along this line. I can guarantee that they will never look at a computer, embedded device, or "smart" device the same way again.

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:Functional Programming Considered Harmful

[dgatwood]

It needs to be done and done well. Very tempting. But alas, just like drug use, there's only so much any sane person can write about the subject, because anyone who knows functional programming well enough to fully explain why it is harmful is probably mentally damaged beyond the point of being able to understand why it is harmful. :-D

The thing is, functional programming is a good paradigm for students to be exposed to in school. Briefly. It forces you to think about data flow through your program, and forces you to think about your software as a giant state machine and visualize how the states change as your software does work. It is not the only way to teach that concept, but it is a halfway decent way. And once you pick up those concepts, you'll start to understand why singletons are so useful (approximately the polar opposite of functional programming, but often the software equivalent of the data you'd be passing around in a functional world).

So basically, there's a time and a place for everything, and it's called college. But just like with drugs, if you continue to do significant amounts of functional programming after that, don't be surprised if the rest of us ask what you're smoking. Functional programming as a real-world paradigm tends to be almost invariably a disaster, because it neither fits the way we think about problems (human thinking is almost entirely procedural) nor the way machines do work (computers are inherently procedural). It can provide useful extensions to procedural programming languages that serve specific purposes (e.g. closures), but calling functional programming useful for that reason is akin to calling a diesel-electric freight train a perfect commuter car that saves fuel because a Prius is also hybrid hydrocarbon-electric.

About the only space where functional programming techniques might really make sense is when working in a massively multithreaded environment, e.g. creating really efficient implementations of certain massively parallelizable functions (such as FFTs). But for the most part, that functional programming is limited to creating components that are then utilized as small (but performance-critical) parts in what is otherwise on the whole still procedural (or OO) software.

Outside of those very limited scopes, though, the theoretically ivory-tower-pure, zero-side-effect functional programming model is pure garbage. Real world systems don't just have side effects; they are side effects, whether you're talking about storing data on disk, sending it over a wire, drawing it on the screen, reading data from a keyboard, or whatever. The notion of treating all of those "side effects" as some giant state object that mutates as it gets passed around is fundamentally antithetical to real-world use of the data, because state must be stored to be useful. And the entire notion of passing around the complete state of real-world software is so far beyond infeasible that the concept is utterly laughable. Cell phones have a gigabyte of RAM, not a petabyte. There's simply no way to write something like MS Word in a pure functional language, because it would take all the computing resources on the planet to barely run a single instance of it.

Using functional programming in most real-world environments, then, cannot possibly do anything but cause brain damage, because the whole functional paradigm is wrong for the problem space. It is like cutting the grass on a football field using only a single pair of nail clippers—theoretically possible, but completely infeasible. To that end, although I wouldn't say that functional programming is inherently considered harmful, it should be approached with approximately the same level of skepticism as goto statements, and for approximately the same reason. When used correctly, in a very limited way, it is a powerful tool to have in your toolbox that can seriously improve your software. When overused or misused, it is a black hole that consumes infinite amounts of programmer time while emitting very little.

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:My answer

[Rockoon]

1 character names for types are not good

Says who?

All localized variables and types in my programs have 1-character names, and its for multiple good reasons including that because you can see that something is only 1 character at a glance, that therefore you know for sure that it doesnt have much if any outer scope with that very same glance.

Re:It has its uses

[silentcoder]

The value of a lambda is greatly reduced in a language like python (though it supports them) where functions are first-class objects - when you can store functions and pass them around as variables the benefits of named functions hugely improve and much of what a lambda does can be done more cleanly by using data structures.

So, for example, by storing functions as values in a dict you can build complex structures of execution without using any conditional codes . A long cluster of nested if-statements can be reduced to a single dictionary accessor. This is one of the standard ways to the common python-challenge of implementing Conway's game of life without using any if statements.

This, in fact, was what I found most annoying working in Ruby as opposed to python - the fact that functions are not first-class objects force you to use things like lambdas even where more elegant solutions may otherwise have been available.

Re:It has its uses

[silentcoder]

I would argue that OO remains the best paradigm we have for constructing data presentation - especially when the data represents something that exists in the real world (or a reasonable facsimile as in GUI programming or video-game dev). Functional programming on the other hand - is often the best paradigm we have for data processing, especially big data processing. Use them each in their own domains and break these rules-of-thumb whenever it makes sense to.

Re:It has its uses

[TheRaven64]

This needs moderating up. Talk to an Ocaml programmer and a Haskell programmer about what makes a functional language and you'll see very different opinions and these two are languages that were actually designed as functional languages: the bits that end up in other languages are a tiny subset.

Coming from the Haskell side, I see functional programming as programming without side effects and with monads. You can implement monadic constructs in other languages, but it rarely makes code cleaner. Just having higher-order functions doesn't make a language a functional language any more than having structs makes C an object-oriented language.

If the question is 'do you think using higher-order functions simplifies the expression of some algorithms' then the answer is obviously 'yes': programmers have a lot of tools to choose from and most of them are useful at least some of the time.

Poorly understood?

[fyngyrz]

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

You may have misunderstood the previous poster's use of "poor coder."

I read it as "unfortunate coder", not "incompetent coder."

I could certainly be wrong. Perhaps clarification will be forthcoming.

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.

structs and fundamental OO

[fyngyrz]

Just having higher-order functions doesn't make a language a functional language any more than having structs makes C an object-oriented language.

Structs do, however, make the critical aspects of an object oriented approach practical in c. They can carry data, function pointers, etc., and they can be passed around.

I've been writing my c code like that since the 1980's. There are significant benefits.

Re: It has its uses

[Anonymous Coward]

This was the subject of Brian W. Kernighan's paper: Why Pascal is Not My Favorite Programming Language, where he analyzes converting software tools to Pascal. His conclusion summarized the problems I was having in being forced to use ADA for DOD. Of course in the DOD's case, they deliberately closed the language, and that's why C passed it by.

      9) There is no escape.

This last point is perhaps the most important. The language is inadequate but circumscribed, because there is no way to escape its limitations. There are no casts to disable the type-checking when necessary. There is no way to replace the defective run-time environment with a sensible one, unless one controls the compiler that defines the ``standard procedures.'' The language is closed.

People who use Pascal for serious programming fall into a fatal trap.

Because the language is so impotent, it must be extended. But each group extends Pascal in its own direction, to make it look like whatever language they really want. Extensions for separate compilation, Fortran-like COMMON, string data types, internal static variables, initialization, octal numbers, bit operators, etc., all add to the utility of the language for one group, but destroy its portability to others.

I feel that it is a mistake to use Pascal for anything much beyond its original target. In its pure form, Pascal is a toy language, suitable for teaching but not for real programming.

http://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html