A reactive variable already contains the seed of a distributed system. When values change independently, trigger work, cross boundaries, and maintain relationships over time, the program must manage concurrency, location, ownership, and communication.

Cartilage makes that hidden machine explicit: one process represents one reactive value or operation, while persistent links connect objects across a physically distributed fabric.

Follow the Logic From Reaction to Distribution

Reactive updates can occur at several places in source code at once. Autonomous processes carry those updates in parallel, and network relationships let the processes occupy different cores, devices, or machines.

Dynamic object creation then requires runtime structure. Cartilage allocates types, regions, ports, and routes as the program changes, preserving connections when an object moves through a larger hierarchy.

Make Parallel Structure Easier to Reason About

Harel statecharts, functional dataflow, object relationships, and distributed state machines can share the same substrate. Developers choose the surface that fits the problem while the hardware maintains locality and connectivity.

Teams building large reactive systems can map one live variable graph onto Cartilage and inspect how physical placement clarifies causality, ownership, and scale.

Make Reactive Programming Implies Distributed Systems Visible in Cartilage

Cartilage Visual Language makes the topology, state, and active computation in this argument directly inspectable.

Cartilage Visual Language

Originally posted on LinkedIn

Brian Greenforest · Tuesday, April 26, 2022 at 6:51:08 PM PDT (2022-04-27 01:51:08 UTC)

LinkedIn status when archived: Edited · Visible to anyone on or off LinkedIn.

I want to share with you my recent thought that came on a walk just a minute ago... It's for software developers and computer science engineers. It's about reactive programming. I think, reactive programming implies concurrent programming: many things can happen simultaneously at more than one location in your source code. That's an easy thing to agree with. Then, concurrent programming demands those multiple things to happen at those multiple places somehow. One way is multi-tasking on a single core. Another is to replace those computation updates with autonomous processes. An autonomous process is simply a thread or a program that runs on one core (or migrates between different cores as in Kevin Cameron's design of wandering threads, closer to relevant data). We can call the multi-processing programming a parallel programming, shall we? After that, I only need to mention that self-modifying code with dynamic types is a must for self-consistent type instantiation support in reactive programming. So, reactive programming is a parallel (at least, concurrent!) programming in disguise with self-modifying dynamic types, otherwise you're missing the point of its computer-scientific consistency. Indeed, any parallel programming is orthogonal to distributed programming, and distributed programming adds reliability and liveliness concerns, but given the development of modern networks, and multipath alllocation of bandwidth, and other clever tricks to keep distributed systems coherent, we may assume (or even explicitly model!) the interconnectivity relations between PARTS of ONE LARGE DISTRIBUTED PROGRAM. And that's the model of computation Cartilage hardware implements natively, without any OS support (it is a hardware operating system). Okay, what I'm trying to point out to is that for many, reactive programming, Matlab/Labview "Lego blocks" composition, is the only way to manage immense complexity of large systems. We thought that parallel programming is MUCH HARDER than ordinary, single-threaded one, but it turns out it's the opposite. In Cartilage, one process represents one reactive variable, or one reactive operation upon related reactive variables. You can stretch an "entanglement" link upon creation of an object inside of a bigger membrane, and maintain that link, while passing that object far away: you don't ever have to use the reactive objects as classes with methods and instance variables; it's perfectly fine to treat them as pure functions for those who PREFER pure functional programming with only computed transient state. Everything becomes possible, including hierarchical state machines (Harel), and distributed state machines (idle states). There are many ways you can design your distributed massively scalable applications on Cartilage, but the biggest kicker of WHY we doing this design is to make the FINAL CHIP. Today's chip shortage makes it extremely hard to procure an appropriate device, and forces many of us to wait...

Comments added by Brian Greenforest on LinkedIn

This comment was also preserved verbatim from Brian Greenforest’s LinkedIn data export or the public post page.

Comment 1 · Tuesday, April 26, 2022 at 6:58:36 PM PDT (2022-04-27 01:58:36 UTC)

For those of you interested in Kevin Cameron's wandering threads idea, here's the link: https://contest.techbriefs.com/2018/entries/electronics-sensors-iot/9076

View the LinkedIn post