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?

Frank Shearar
  • 16,643
  • 7
  • 48
  • 84
Jonas
  • 14,867
  • 9
  • 69
  • 102
  • 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 07: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 http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/mark.pdf – Giorgio Aug 21 '14 at 21:20

5 Answers5

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.

AShelly
  • 5,793
  • 31
  • 51
  • 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 09: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 Dec 27 '10 at 19:36
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.)

Matt Olenik
  • 3,377
  • 1
  • 19
  • 20
  • 9
    The article [The Next Mainstream Programming Languages: A Game Developer's Perspective](http://lambda-the-ultimate.org/node/1277) 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
  • 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 Oct 16 '10 at 22:21
  • @sepp2k right, I see what you mean. – Matt Olenik Oct 16 '10 at 22:33
  • @sepp2k: That was over 4 years ago but nothing became of it. I assume he realised his mistake? – J D Dec 27 '10 at 19:43
  • @Jon Harrop, why make that assumption? That was a long term reach goal for (presumably) rewriting the Unreal engine. No small task, especially when you have to keep up with market demands and improve the product. – Matt Olenik Jan 19 '11 at 19:37
  • @Matt Olenik: Occam's razor. – J D Feb 05 '11 at 17:58
  • Pure functional languages are lazy. They don't rebuild the world from the previous state. They work differently under the hood. – Amir Karimi May 10 '16 at 17:10
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).

mipadi
  • 7,493
  • 36
  • 35
  • -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 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. – J D Dec 28 '10 at 00: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 02: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 02:03
  • @mipadi: "...even impure FP languages encourage this style". Lisp is an obvious counter example because it could not even express that style of programming due to the lack of tail call elimination (pure code would stack overflow) and, yet, it is considered by every functional programmer outside the Haskell community to be the mother of all functional programming languages. OCaml also does little to encourage purity and even has mutable strings and literals for mutable arrays. Erlang, although immutable, is entirely reliant upon message passing which is a side effect. And so on... – J D Dec 28 '10 at 13:43
  • So what you really meant was "purely functional programming is not good for GUIs". I doubt anyone would disagree: Haskell is not good for much. But is functional programming (with the conventional definition of using first-class functions, e.g. callbacks) bad for GUI programming? Microsoft obviously think it is good because they just added first-class functions to .NET specifically for this purpose. I think FP is good for GUIs because I find F# to be good for our GUIs. YMMV. – J D Dec 28 '10 at 13:46
5

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

Branimir
  • 554
  • 4
  • 8
  • 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
  • 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 Oct 11 '10 at 02: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](http://www.janestcapital.com/yaron_minsky-cufp_2006.pdf) – Jonas Oct 11 '10 at 20:33
  • 1
    -1: You've listed some application that FP excels at. – J D Dec 27 '10 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.

Peer Stritzinger
  • 158
  • 4
  • 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
  • @Larry: Is there even any useful GUI-library for Haskell? F# is the only functional languages I know about that has good interoperability with a decent GUI framework (WPF). – Jonas Nov 19 '10 at 21:58
  • 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
  • @Larry: In 2010 I'm looking for a more modern GUI framework than wxWidgets and GTK with a declarative layout and databindings and so on. F# has very good support for WPF but it's still hard to do it in a functional way. It's something I really missing in the functional world. I have heard that the Actor Model is a good fit for GUI frameworks. I hope we will get a functional GUI framework in the future, but I don't think we are there yet. – Jonas Nov 19 '10 at 22:08
  • @Jonas: The Haskell community is still working out the best way to fit GUI's into their paradigm. There are a few projects being actively worked on. I'd check back in another year or so. – Larry Coleman Nov 19 '10 at 22:39