Dear all, let’s do some <#C5T9GPWFL|> about a real...
# thinking-together
h
Dear all, let’s do some #C5T9GPWFL about a really simple idea that I find irresistibly non-complected, but might well be partially or totally flawed or just a reformulation of something else; but hey! for the duration of this post, lets cast doubts aside and enter creative mode; exploring the idea as if building just another mind-blowing creation in Minecraft 🙂 : Any static web page as well as every dynamic UI in the browser or anywhere, can be seen as an orthogonal combination of
embodiment
and
essential state
. Let’s call such a combination a
layer
. (Think of state the
values
and embodiment as `rendering`/`timers`/`event-handlers` etc). Here’s the problem it is aimed for solving: State composes perfectly with state, embodiment composes perfectly with embodiment; but _when we mix state and embodiment, complexity explodes exponentially_; we can no more distinguish between them, no more extract and model the state explicitly, visualize it, generate tests based on it etc and for every new part or feature, technical debt is amassed and the complexity quickly skyrockets into levels that not even the most skilled designers and developers can handle. So back to the really simple idea: Let’s keep it orthogonal; let components be expressed in an orthogonal way, let’s composition propagate orthogonality. What follows from it? How can we model it; can we being to imagine a
Layer Machine
formalism? A
layer machine markup language
? Make an enlightening
run-time visualization
? Can we implement it, and in how many LOC?; can we use it to explore its PL usability factors along some cognitive dimensions? What new ideas can we form based on that experience?
a
I'm having trouble with your terminology. By "embodiment" do you mean the translation between the "essential state" (I'm assuming this means pure business/domain logic) and a concrete UI?
👍 1
n
Yeah, I can't really comment on this post, because you've coined your own term and not explained what it is, and why it "composes perfectly" with itself.
👍 1
w
"State composes perfectly with state, embodiment composes perfectly with embodiment; but _when we mix state and embodiment, complexity explodes_" — I'll take some of whatever state and embodiment you've got composing. In my experience, state composes awkwardly ("oh, it depends on this other data way over there"), embodiment composes awkwardly ("oh, that isn't going to fit on the screen"), and the two, when mixed, compose even worse ("wait, I was in the middle of editing that, it can't just disappear when make a change that will remove it from the list").
👍 2
h
@wtaysom What are examples of things that do compose well, in your experience? (I’m interested since I think composition is a key asset in keeping complexity from exploding)
@Andrew F @Nick Smith Sorry for posting raw ideas of the top of my head and messing up the terminology. I’ll keep that in mind next time. Do you think a brief summary and a link to a blog post w code examples would be more helpful? Anyways, what I mean with `state`is just a tree of pure values, like in
statecharts
, and, yes the embodiment can be DOM, concrete UI etc. In stead of Layer machine, just read
state machine
or
statechart
and assume a composable version of them that covers the whole app instead of leaving a lot to the host language. And in stead of layer machine markup, think HTML, just extended with some new kinds of tags or metatags. I think explicit state modeling as in e.g. statecharts is so great for keeping complexity at bay, and that the biggest thing stopping it from being even more useful is _composability_; thus I find anything that might enhance composability of statecharts/state modeling super exciting! Hope to do a better job of exiting people for that idea the next time! 🙂
w
In my experience? The third rewrite composes better. The first version is too hot: rough and ready. The second is too cold: over-engineered. And the third is just right: reusable pieces that snap together tightly using minimal glue. I have a short list of concrete examples, not my own: • Bayes rule composes well when you use odds instead of probabilities.

https://www.youtube.com/watch?v=lG4VkPoG3ko

• Maxwell's equations fall out from the geometric product in the proper units.

https://www.youtube.com/watch?v=60z_hpEAtD8

• The chain rule composes better under derivatives improved by keeping the function's original value too.

https://www.youtube.com/watch?v=17gfCTnw6uE

💯 1
😮 1
h
@Andrew F @Nick Smith Thanks for feedback, and my bad for posting raw ideas of the top of my head and omitting definitions/intuitions 🙂 I’ll keep that in mind next time; doesn’t hur to work on my communication skills 🙂 Do you think a couple of descriptive sentences and a link to a blog post w code examples would be more helpful? Anyways, what I mean with `state`is just a tree of pure values, like in
statecharts
, and, yes the embodiment can be DOM, concrete UI etc. In stead of Layer machine, just read
state machine
or
statechart
and assume a composable version of them that covers the whole app instead of leaving a lot to the host language. I think explicit state modeling as in e.g. statecharts is so great for keeping complexity at bay, and that the biggest thing stopping it from being even more useful is _composability_; thus I find anything that can enhance composability of statecharts is super interesting.
a
@wtaysom to me it seems algebras compose exceptionally well, both "horizontally" (algebra products) and "vertically" (algebra homomorphisms primarily). Whenever you manage to frame something as an algebra it becomes so much easier to work with. 🙂
😎 1