Hacker News Reader

Comment by 0x445442 | Hacker News Reader

I think OOP is better suited when state needs to be maintained in memory over time. User interface development is one obvious use case and I think OOP really gained traction during a period when thick clients were the norm.

However, when thick clients gave way to web apps (ignoring SPAs for the moment) the industry still tried to pound the square OO peg into the round backend hole. Most of that backend code is just transforming data between a database and either a browser in the case of a web app or another client in the case of web services, applying business rules along the way. I think this class of software is much better served by the FP model.

View on HN

FP works much better for UIs in my experience. Take a look at Reagent as an example 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.

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.

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

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.

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

Reply on news.ycombinator.com