Functional programming is a declarative paradigm. One of the strenghts with FP is that side-effects are avoided. It's said that for some problems FP isn't a good fit.

For what common problems isn't functional programming a good fit?

  • Whew! For a moment there I thought you said "is a defective paradigm". Then I came back and checked. – Mark C Oct 11 '10 at 7:40
  • 1
    I think it's more accurate to say that side-effects are isolated (in Haskell anyway) than avoided. Monads do allow for state changes, and one is even named "State". – Larry Coleman Nov 19 '10 at 21:49
  • As Larry Coleman explained, it is not true that functional programming avoids side effects, but that it discouraged their use and, in some languages, it clearly isolates them. Read e.g. Section 7 of research.microsoft.com/en-us/um/people/simonpj/papers/… – Giorgio Aug 21 '14 at 21:20

Applications that are very stateful in nature. Video games are a good example because they model the real world. It makes much more sense to think about modifying the state of the world instead of rebuilding from the previous state every time something changes.

A concrete example would be changing the health of a monster after it gets shot. It's a lot more sensible to simply alter its health than to replace it with an entirely new monster that is the same in every way except now it has less health. These kind of changes make up just about everything in a game world, and doing this in a pure functional manner is not very intuitive. I imagine there may be some significant performance penalties, at least if you're doing it in a purely functional language.

(As a side note, some problems in games are very well suited to functional programming, such as AI. A hybrid functional/imperative language would be an excellent fit for those cases.)

  • 9
    The article The Next Mainstream Programming Languages: A Game Developer's Perspective argues for a pl, specifically for game development, where purely functional behavior is the default, and state change is tracked through types, to avoid bugs. So not everyone believes that the functional paradigm is inherently ill-suited for games programming. – sepp2k Oct 16 '10 at 18:23
  • 1
    @sepp2k, thanks for the link. I'm glad to see the perspective argued from someone who's made real games. – Matt Olenik Oct 16 '10 at 21:45
  • 3
    @sepp2k wait, did I miss something? After reading the presentation more closely, it seems Sweeney was arguing for most of the core engine to be written with purely functional code, and most of the game logic to be written imperatively (or at least allow it) and use STM to help with concurrency. This seems very reasonable to me. – Matt Olenik Oct 16 '10 at 22:07
  • @Matt: No, you're right, he does say the game logic part will contain mutable state. However that doesn't preclude the language from tracking mutability through types (which he proposes in the "musings" section). Of course "tracking state through types" does not equal "functional", so I might have phrased my previous comment a bit too optimistically. – sepp2k Oct 16 '10 at 22:21
  • @sepp2k right, I see what you mean. – Matt Olenik Oct 16 '10 at 22:33

Real-time embedded programming is all about the side effects. Interacting with digital and analog io, timers, serial and parallel ports, everything interesting is done by calling functions with side efffects.

  • 3
    Well, if you just mean the hardware interface I doubt anything other than C/C++ is a good choice. However on the layer on top of that languages like Erlang is used sometimes, specially in telecom systems. Erlang is a functional language designed for critical and fault-tolerant embedded real-time systems. – Jonas Oct 11 '10 at 9:05
  • @Jonas: Erlang might minimize mutation but it is heavily dependent upon IO to pass messages which is, of course, a side effect. – Jon Harrop Dec 27 '10 at 19:36

I'd argue that GUI programming is not a good fit for functional programming. GUIs are generally very stateful, and it's a lot easier to model/manage them using state rather than using a side-effect free. It's certainly possible to use a functional programming language for GUIs...but it's probably not a good idea.

As noted in another answer, games are often easier to manage by tracking state, and while you can write a game in a functional language, it's often easier and more efficient to do so in a "stateful" language (i.e., an object-oriented language).

  • -1: You're talking about purity and ignoring the use of first-class functions, e.g. callbacks in GUI code are much easier with impure FP languages than with OOP languages. – Jon Harrop Dec 27 '10 at 19:40
  • 4
    @Jon Harrop: First-class functions aren't unique to functional programming languages. I still argue that the FP style isn't a good fit for GUIs. – mipadi Dec 27 '10 at 22:18
  • 1
    Depends who you ask. To most functional programmers, first-class functions are the very definition of functional programming. – Jon Harrop Dec 28 '10 at 0:22
  • @Jon Harrop: Most functional programmers would say that functional programming is a method of describing programs as the composition and evaluation of mathematical functions. First-class functions are an important part of this paradigm, but first-class functions alone do not a functional programming language (or functional program) make. The functional programming paradigm strives to minimize the use of state and mutable data structures, and even impure FP languages encourage this style. FP is as much about a style of programming as it is individual features like first-class functions, and... – mipadi Dec 28 '10 at 2:02
  • ...I don't find that this paradigm is especially amenable to GUI programming -- object-oriented languages are a better fit for GUIs, generally speaking. – mipadi Dec 28 '10 at 2:03

Data-driven business applications. User interface and simple data operations don't need FP.

  • 2
    And any other data/view application, really. The majority of games are all about state and changing it, and so don't translate well to a functional style. – Jon Purdy Oct 10 '10 at 19:49
  • 18
    Really? I always thought that FP would be specifically good for this. Isn't like 99% of what those apps do selecting, aggregating, and projecting data? That's basically filter, reduce and map. Throw in some sort, partition, groupBy. After all, the most widely used programming language for writing such applications is Excel, which is a functional language. – Jörg W Mittag Oct 11 '10 at 2:16
  • 3
    Data-driven business applications and applications with simple data operations sounds like a very good fit for FP and I have heard that FP is popular for such things. E.g. see Adventures f a functional programmer on Wall Street – Jonas Oct 11 '10 at 20:33
  • 1
    -1: You've listed some application that FP excels at. – Jon Harrop Dec 27 '10 at 19:37

You can't easily dismiss any problem set for not suited for functional programming per se.

Much depends on the actual language used for functional programming and its features.

One example is the already mentioned Erlang for realtime embedded-systems.

State-fullness is also not a good criterium against functional programming, there are several successful ways implemented in functional programming languages to deal with this.

Side effects are also often mentioned against functional programming. Every program that is not totally solipsistic has side effects. So every real world FP language has some way to deal with this, its only a matter how elegantly to encapsulate the world side effects.

There is no need for arbitrary side effects like global variables at all.

But there are problem sets that make it easier to get into functional programming because they don't twist your familiar way of looking at the problem as much. But once you manage to think functional more and more problem sets are open to less side-effects.

Even when programming C it is always a good idea to reduce arbitrary side effects like global variables as much as possible.

  • State-ful applications like GUI applications are actually hard to do in a functional way, or do you have any recommendations? – Jonas Oct 28 '10 at 16:05
  • If you have some kind of process/thread abstraction (e.g. like in Erlang) you can pass your state around in a process. – Peer Stritzinger Oct 28 '10 at 17:42
  • 3
    GUI applications are usually built around an event loop. You can write a event loop pretty well in a functional language. If its more complicated you'll probably add some threads/processes for background processing. But if you have some kind of process/thread abstraction (e.g. like in Erlang) you can pass your state around in a process easily. Continuations might also come in handy. I think its just getting used to doing stuff in a functional way to even get a handle on GUI's. One reason GUI programming is considered hard today is that most toolkits are not intended for functional usage. – Peer Stritzinger Oct 28 '10 at 17:48
  • 1
    @Jonas: in Haskell, you would use either the IO monad, the State monad, or a combination. – Larry Coleman Nov 19 '10 at 21:51
  • 1
    @Jonas: that depends on your definition of useful. The wikibook example uses wxHaskell, while Real World Haskell uses gtk2hs. I haven't tried either as my Haskell app is command line-based. – Larry Coleman Nov 19 '10 at 22:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.