3 ms·

FP works much better for UIs in my experience. Take a look at Reagent as an example http://reagent-project.github.io/ http://reagent-project.github.io/ With Re

FP works much better for UIs in my experience. Take a look at Reagent as an example http://reagent-project.github.io/ http://reagent-project.github.io/ With Reagent, you have reactive atoms containing your data and components subscribe to them. Whenever the state of the atom changes, the UI is automatically repainted. You basically end up with a classic MVC pattern where UI components dispatch events that update the sate, and observe the changes via subscriptions. The advantage over OO is that the state is easily decoupled from the UI, and you can observe the entire state of the UI via data. Since the logic lives outside the UI components, you can also do testing at event level which tends to be a lot more stable.

ceronman 8y ago
I love how Reagent works and I do think it makes interactive applications simpler and easier to reason about. That said, I think FP still has one disadvantage which is performance. This is because the underlying computer is 100% imperative and there are still a lot of work to make FP patterns efficient. FP works well for interactive UIs because the number of objects that change in GUI is very small, so performance is not an issue. But take a video game, for example, then you have thousands of moving objects that are updated at 60FPS. Once you get that you notice is really hard to write the logic as a set of immutable state changes, object allocation becomes a bottleneck and then you discover that OO is more suitable, at least for now. Maybe later there will be ways to efficiently translate the FP patterns into the imperative CPU models.
- yogthos 8y ago
  That's a bit of a misconception about FP though. Immutability is just the default, and you can opt into local mutability when you need to. Clojure transients are a good example of this. So, in a case of a game, I would create local mutable sections for the tight loop. It's also worth noting that modern hardware hasn't been using imperative CPU models for a long time, and it provides an emulation layer that languages like C target https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479
0x445442 8y ago
That's interesting. Admittedly, I've not done UI work for many years and I've never used FP for UI development. But what you described is really the way we used to design things with OOP. You'd have classes which represented physical views and would register for events on an event bus. When the events arrived the views would update themselves accordingly.
- yogthos 8y ago
  The biggest difference is in how the state is managed. With OOP, each class is typically its own state machine with its internal behavior. With the FP approach, you can treat your state like a database, and you can easily inspect the overall state of the application. There is some nice tooling for doing these kinds of inspections in re-frame nowadays https://github.com/Day8/re-frame-10x https://github.com/Day8/re-frame-10x

ceronman 8y ago

I love how Reagent works and I do think it makes interactive applications simpler and easier to reason about. That said, I think FP still has one disadvantage which is performance. This is because the underlying computer is 100% imperative and there are still a lot of work to make FP patterns efficient. FP works well for interactive UIs because the number of objects that change in GUI is very small, so performance is not an issue. But take a video game, for example, then you have thousands of moving objects that are updated at 60FPS. Once you get that you notice is really hard to write the logic as a set of immutable state changes, object allocation becomes a bottleneck and then you discover that OO is more suitable, at least for now. Maybe later there will be ways to efficiently translate the FP patterns into the imperative CPU models.

yogthos 8y ago
That's a bit of a misconception about FP though. Immutability is just the default, and you can opt into local mutability when you need to. Clojure transients are a good example of this. So, in a case of a game, I would create local mutable sections for the tight loop. It's also worth noting that modern hardware hasn't been using imperative CPU models for a long time, and it provides an emulation layer that languages like C target https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479

0x445442 8y ago

That's interesting. Admittedly, I've not done UI work for many years and I've never used FP for UI development. But what you described is really the way we used to design things with OOP. You'd have classes which represented physical views and would register for events on an event bus. When the events arrived the views would update themselves accordingly.

yogthos 8y ago
The biggest difference is in how the state is managed. With OOP, each class is typically its own state machine with its internal behavior. With the FP approach, you can treat your state like a database, and you can easily inspect the overall state of the application. There is some nice tooling for doing these kinds of inspections in re-frame nowadays https://github.com/Day8/re-frame-10x https://github.com/Day8/re-frame-10x