24

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?

Improve this question
3
  • Whew! For a moment there I thought you said "is a defective paradigm". Then I came back and checked.
    – Mark C
    Commented Oct 11, 2010 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
    Commented Nov 19, 2010 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
    Commented Aug 21, 2014 at 21:20

5 Answers 5

Reset to default
18

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

Improve this answer
9
  • 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
    Commented Oct 16, 2010 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
    Commented Oct 16, 2010 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
    Commented Oct 16, 2010 at 22:07
  • 1
    @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
    Commented Oct 16, 2010 at 22:21
  • @sepp2k right, I see what you mean.
    – Matt Olenik
    Commented Oct 16, 2010 at 22:33
18

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.

Improve this answer
2
  • 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
    Commented Oct 11, 2010 at 9:05
  • 1
    @Jonas: Erlang might minimize mutation but it is heavily dependent upon IO to pass messages which is, of course, a side effect.
    – J D
    Commented Dec 27, 2010 at 19:36
12

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

Improve this answer
7
  • -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.
    – J D
    Commented Dec 27, 2010 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
    Commented Dec 27, 2010 at 22:18
  • 1
    Depends who you ask. To most functional programmers, first-class functions are the very definition of functional programming.
    – J D
    Commented Dec 28, 2010 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
    Commented Dec 28, 2010 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
    Commented Dec 28, 2010 at 2:03
5

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

Improve this answer
4
  • 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
    Commented Oct 10, 2010 at 19:49
  • 19
    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
    Commented Oct 11, 2010 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
    Commented Oct 11, 2010 at 20:33
  • 1
    -1: You've listed some application that FP excels at.
    – J D
    Commented Dec 27, 2010 at 19:37
3

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.

Improve this answer
8
  • State-ful applications like GUI applications are actually hard to do in a functional way, or do you have any recommendations?
    – Jonas
    Commented Oct 28, 2010 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
    Commented Oct 28, 2010 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
    Commented Oct 28, 2010 at 17:48
  • 1
    @Jonas: in Haskell, you would use either the IO monad, the State monad, or a combination.
    – Larry Coleman
    Commented Nov 19, 2010 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
    Commented Nov 19, 2010 at 22:01

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