Immediate Mode UI + ECS

The most Lispy/Haskelly way to to implement use interface is through first designing a ECS database, and then using immediate mode UI to draw it. Stateless UI just so much easier to implement and reason about, and it involves no OOP nonsense. You can probably replace ECS database with an in memory relational database or even a Prolog like system.

Hierarchical inheritance object systems always seems to invoke Greenspun's Eleventh Rule: any sufficiently complicated OOP program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Prolog.

Example Qt for C++, where they over use the observer pattern together with component classes to simulate ECS, but in a really imperfect and frail way.

At least Qt has good support for screen readers. Can't say the same for toy immediate UI toolkits.

>>3
Immediate mode a superset of the graph mode. There is nothing the graph style toolkits can't do the immediate mode can't do, if it is built on top of a ECS system. Same way OOP is just a subset of COP (component oriented programming). The only reason to use OOP is because COP is too slow for anything but the highest level glue. I.e. you can store you meshes inside ECS, but it will provide a tad of flexibility, but will be too unpractical. So even separate particles are rarely implemented using ECS, because you need millions of them. But particle emitters themselves are good candidates to be in ECS, since they really interplay with all other systems.