Clojurians Log v2

"In this dissertation I propose a shift in the foundations of computation" https://dspace.mit.edu/handle/1721.1/54635 Uh-oh! Well, that's the way we reactive researchers always feel when we find it. But he cites constraints as a proof of concept, just before mentioning that they are impossible to work with. Matrix design, on day two, worried about living with reactive mechanisms, and still does. That may be the one ingredient computer science researchers feel free to dismiss, understandably: hey, we're doing the deep thinking, the COBOL maintainers can work out integration later. Interesting that Sussman is the advisor. I think he advised Steele on the failed constraints programme, as well. More powerful than Matrix, but unprogrammable in the way Prolog is. "How do I get this code to do what I intend?" A pattern emerges. I'll look at the thesis closer later, but I suspect there will be a scaling problem akin to GOTO-based programming.

Neat to see facets of this history of (more?) reactive programming.

Voila, @chromalchemy: https://dl.acm.org/doi/pdf/10.1145/800136.804464 I think that was a predessor to Steele's PhD thesis, which I have found before as a scan, but am not finding now. The title was sth like "The Design and Implementation of a Constraints-Based Programming Language." tldr: Interesting super powers that proved too non-determistic for real world programming: • partial constraints,eg, define A as less than B; • multi-way constraints: define A as B + C. Now implement a change to C. Note that the constraint can be maintained by changing A, B, or both. It turned out to be really hard to get expected/desired results from the solver that actually handled change. Note that Steele was fully aware of the deterministic spreadsheet model followed by Matrix, but did not find it interesting. I admire his ambition!

So looking at scoped propagators (SPs), the original comparison, the win seems to be modifying properties reactively without them being coded specially: the SP holds that logic and makes the changes. But a lot is not clear. Can I have two SPs working on one property? That would be like GOTO programming: how did this value get to this target property? SPs work on a source and a target, possibly the same with two diff props: can a target be fed from more than one property/target? I see no hint of that, and that would be quite limiting. Huge concern here. One nice thing about reactive systems that define formulas for properties, instead of having the formula elsewhere, is that I can look at the source and see how a property will be derived. Where do we put the code for an SP, near the source or the target? Here the "win" itself is in doubt. What is your take, @chromalchemy?

It’s all above my head unfortunately. I am very sympathetic to the notions of of contraint-based programming. Manually specifying reams of values to change one simple design dynamic in css was always frustrating for me. Hence cluing into the need for a real component system and sufficient reactivity. Specifically, it is suboptimal from a push-pull play aspect (which is why people often design in a graphics program first). I distinctly remember having Cassowary envy in CSS. I’m also very sympathetic to the colocation of parameters and formulas. The html/css split also brutalized me into that logic. Maintaining a registry does seem to add a lot of friction: double-naming, navigation tedium, cognitive load, every change is a “refactor” etc… Not really specific to this implementation. But I’m amazed at how deeply you all have thought on it (considering how shallow the industry standard is on average)

Do you think the vagaries of nondetermanism in an ambitious constraint system could be further boiled down with more patter-matching, like ai/llm can do?

"I’m amazed at how deeply you all have thought on it" I was trapped into it. Just working on GUI layout: https://tilton.medium.com/the-making-of-cells-5ab873d1e6c7 Turned out to be so dramatically effective and simple, I carried on with it and pushed it as far as I could. Turned out to be very pushable. 🙂 But "glitches" really challenged the approach, but turned out to have a simple solution: never return a value without checking that it is "current", and make it current if not. Scary how much code can run before a value gets returned, but it Just Works(tm), which I take to be a message from God. 🙂

"Do you think the vagaries of nondetermanism in an ambitious constraint system could be further boiled down with more patter-matching" When I saw the paper suggesting a new "walkabout strength" as a way of making constraints systems manageable I knew the programme was dead, the way you know Prolog is dead when it has to offer not just "cuts" but different color cuts. Meanwhile, it turns out that insanely complex apps can be developed easily with the trivial reactive mechanisms Steele sneered at. Again, I admire the ambition, but it was a reactive bridge too far, and there was no need for it. Matrix was developed by an app programmer interested in building apps, and evolved only as apps placed new demands on it.

Saw a shout out to Adam/Eve and Sean Parent in the Ycombo thread. That was C++ Matrix, in effect. Fun moment: Sean was giving a talk to Google all excited about, in effect, reactive programming. First question was, "Why didn't you use OCAML?".