I'm selling my frustration. I experienced generic uncoupled UI for lazy reactive dataflow around the time I entered college, where I then suffered through C, Java where things quickly become dark magic. The clean thinking process of dataflow looked like a long forgotten dream that was weirdly close to what your code ends up doing, streaming data through transformations. But in imperative code it's obscured. Sure some people have the right view and the right brain (I believe more people before the 80s had this skill on average) and they can compile the idea into algorithmically clean imperative code where things don't step on each others (just like algorithms in Cormen), but I didn't met them often.
Graphics and other domains (sound, ..) had easier time finding an algebra to combine atoms and filters in arbitrary fashion to create complex results. I'm betting all high end (meaning hollywood) graphic software are lazy dataflow systems. But if you look at Photoshop, it's still imperative, and people are required to get skilled at managing dozens of layers to store intermediate results in case they wanna change something. This is pure madness. Find tutorials about Houdini where the artist builds its dependency graph as it fits, and if he something needs to be modified he just tweak the right upstream node and everything recomputes on demand.
Software is different ? not so much, Brett Victor demonstrated how you could develop a platform game in such fashion, lazy reactive source code with different dimensions/views. You can see the output of a trajectory function, change the code and observe the computed difference on the fly..
A lot of projects are trying to reduce the loop between idea / source / result. DevOps with testing/deploy vms (even storage systems are approaching functional idioms like btrfs, zfs, logfs), js client frameworks with databinding .. all the same. It's not everything though; a friend pointed to me that sometimes you need to research an algorithm, it won't be large so this won't help you understanding the problem faster.
The type encoded state is not imperative programming anymore, as I said, to me it's akin to prolog.
Graphics and other domains (sound, ..) had easier time finding an algebra to combine atoms and filters in arbitrary fashion to create complex results. I'm betting all high end (meaning hollywood) graphic software are lazy dataflow systems. But if you look at Photoshop, it's still imperative, and people are required to get skilled at managing dozens of layers to store intermediate results in case they wanna change something. This is pure madness. Find tutorials about Houdini where the artist builds its dependency graph as it fits, and if he something needs to be modified he just tweak the right upstream node and everything recomputes on demand.
Software is different ? not so much, Brett Victor demonstrated how you could develop a platform game in such fashion, lazy reactive source code with different dimensions/views. You can see the output of a trajectory function, change the code and observe the computed difference on the fly..
A lot of projects are trying to reduce the loop between idea / source / result. DevOps with testing/deploy vms (even storage systems are approaching functional idioms like btrfs, zfs, logfs), js client frameworks with databinding .. all the same. It's not everything though; a friend pointed to me that sometimes you need to research an algorithm, it won't be large so this won't help you understanding the problem faster.
The type encoded state is not imperative programming anymore, as I said, to me it's akin to prolog.