Original Post

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...