4 ms·

No doubt functional programming has its place and is very powerful for many types of problems. Just curious, how do you maintain your lovely side-effect free st

by SeanDav 16y ago

No doubt functional programming has its place and is very powerful for many types of problems. Just curious, how do you maintain your lovely side-effect free structure while programming a GUI or other heavily event-driven environment? I have a genuine interest in the answers to this as it is one of the things putting me off learning an otherwise very interesting paradigm.

Swizec 16y ago
GUI isn't really the place to do functional programming imho. But check out node.js for the rest of your pain. It is very event driven and can easily be coded completely side-effect free due to closures.
barrkel 16y ago
Functional programming is a good conceptual fit for data binding in UIs, while functional reactive programming is its application to event streams. I've found the former more practical than the latter, so far.
jerf 16y ago
GUIs themselves aren't the problem; the problem is that all GUI toolkits are written imperatively and since you don't want to rewrite your GUI from scratch you have to end up interfacing your functional program to a huge hunk of imperative code. But it is important to be clear that the problem is actually just the impedance mismatch between the functional code and any huge hunk of imperative code, not special to the problem of GUIs. Functional has some interesting and even good answers to the problem of GUIs, but they all look way klunkier in practice than they "actually are" in some sense because they still have to work through those imperative toolkit bindings. For a clean answer to function + event-driven, see Erlang, which will blow pretty much any other attempt to solve the problems Erlang solves out of the water. Functional doesn't have a problem with event-based, functional blows imperative and OO out of the water at event-based. (Partially because it's a lot easier to write sophisticated runtime like Haskell's or Erlang's that can transparently deal with sync issues that drive imperative programs crazy.) Not enough people are good enough at both OO and functional for this to be commonly understood. You'll know functional languages have entered the mainstream to stay when someone writes a useful functional GUI.
- anghyflawn 16y ago
  This is all true, but, in any case, whatever happened to MVC? After all, you can (and arguably should) have your business logic happen in functional and reduce the GUI or whatever (which might or might not be OO) to more or less a thin layer of piping which ships data between the user and the pure parts of the program.
jamii 16y ago
I don't think anyone (sensible) is advocating that the entire program must be free of side effects, just that side effects have a cost in terms of clarity and maintainability and so should be avoided when possible. > programming a GUI or other heavily event-driven environment Nitrogen is a nice event-based GUI library written in erlang. Have a look at the demos here: http://nitrogenproject.com/demos http://nitrogenproject.com/demos
- eru 16y ago
  > I don't think anyone (sensible) is advocating that the entire program must be free of side effects, just that side effects have a cost in terms of clarity and maintainability and so should be avoided when possible. Indeed. Haskell for example, just `tags' all side-effecting code in the type system. You are free to use lots of side-effects in Haskell. (Even though that would miss the point of the language.)
eru 16y ago
You might want to look into functional reactive programming, and (unrelated) have a look at how xmonad does the IO-heavy work of a window manager, which is all about affecting external state, in a pure language like Haskell.

by SeanDav 16y ago

Swizec 16y ago

GUI isn't really the place to do functional programming imho. But check out node.js for the rest of your pain. It is very event driven and can easily be coded completely side-effect free due to closures.

barrkel 16y ago

Functional programming is a good conceptual fit for data binding in UIs, while functional reactive programming is its application to event streams. I've found the former more practical than the latter, so far.

jerf 16y ago

GUIs themselves aren't the problem; the problem is that all GUI toolkits are written imperatively and since you don't want to rewrite your GUI from scratch you have to end up interfacing your functional program to a huge hunk of imperative code. But it is important to be clear that the problem is actually just the impedance mismatch between the functional code and any huge hunk of imperative code, not special to the problem of GUIs. Functional has some interesting and even good answers to the problem of GUIs, but they all look way klunkier in practice than they "actually are" in some sense because they still have to work through those imperative toolkit bindings. For a clean answer to function + event-driven, see Erlang, which will blow pretty much any other attempt to solve the problems Erlang solves out of the water. Functional doesn't have a problem with event-based, functional blows imperative and OO out of the water at event-based. (Partially because it's a lot easier to write sophisticated runtime like Haskell's or Erlang's that can transparently deal with sync issues that drive imperative programs crazy.) Not enough people are good enough at both OO and functional for this to be commonly understood. You'll know functional languages have entered the mainstream to stay when someone writes a useful functional GUI.

anghyflawn 16y ago
This is all true, but, in any case, whatever happened to MVC? After all, you can (and arguably should) have your business logic happen in functional and reduce the GUI or whatever (which might or might not be OO) to more or less a thin layer of piping which ships data between the user and the pure parts of the program.

jamii 16y ago

I don't think anyone (sensible) is advocating that the entire program must be free of side effects, just that side effects have a cost in terms of clarity and maintainability and so should be avoided when possible. > programming a GUI or other heavily event-driven environment Nitrogen is a nice event-based GUI library written in erlang. Have a look at the demos here: http://nitrogenproject.com/demos http://nitrogenproject.com/demos

eru 16y ago
> I don't think anyone (sensible) is advocating that the entire program must be free of side effects, just that side effects have a cost in terms of clarity and maintainability and so should be avoided when possible. Indeed. Haskell for example, just `tags' all side-effecting code in the type system. You are free to use lots of side-effects in Haskell. (Even though that would miss the point of the language.)

eru 16y ago

You might want to look into functional reactive programming, and (unrelated) have a look at how xmonad does the IO-heavy work of a window manager, which is all about affecting external state, in a pure language like Haskell.