Sequential Code and Hidden Runtime State
May 27, 2021
Conventional code compresses an entire machine into the wandering viewpoint of one instruction pointer. Control jumps among functions and objects, forcing the reader to reconstruct time, history, and hidden relationships before understanding what the system does.
Brian Greenforest turns that limitation into a design brief for a reactive, spatial, massively parallel programming model.
Make the System Visible at Once
A function call presents a black box and shifts attention into another sequential context. Shared references and callbacks then entangle boxes that looked separate on the page.
A spatial model gives every operation a location, state, owner, and set of connections. Causality travels through visible paths, and independent work remains visibly independent.
Replace the Program Counter With Structure
Cartilage combines local resource ownership, reactive ports, dynamic allocation, and hardware execution so the program’s organization becomes the machine’s organization.
Software architects and language researchers can bring a codebase whose control flow obscures the design. Recast it as a connected reactive system and make its real parallelism legible.
LinkedIn status when archived: Visible to anyone on or off LinkedIn.
Do you realize how BAD conventional code is?
If you imagine code as circuits, good luck with reasoning about something happening as inside of a black box (you have to be time and history specific). You even have to pick the specific box to focus your attention at (it jumps out of sudden between ALL boxes!)
How did we allow for such sequential von Neumann mess? Where did we turn wrong? Instruction pointer (program counter) concept was the biggest obstacle to scalability in software. I state, then, that silver bullet must exist... Think about it.
#parallelprogramming #gpgpu #fpgas #programming #scalability #mathematics #abstraction #painpoints #hierarchy #encapsulation #complexsystems #components #comprehension #composable #systems
These 5 comments were also preserved verbatim from Brian Greenforest’s LinkedIn data export or the public post page.
Comment 1 · (2021-05-27 01:35:21 UTC)
Sequential line-by-line code execution is the worst thing ever invented by people for comprehension and encapsulation and abstraction of large systems. How I didn't see that since the beginning?! I always FELT it though, inventing all kinds of crazy graphical programming languages with zero utility, because under them always were lurking those awful von Neumann processors!
You never need the concept of specificity. If everything is processed everywhere, your programmer mind can find peace, because no need to pay attention what line of code in which component is being executed, so what exactly part of THE ENTIRE system can get impacted in the very next moment of time.
How we even were able to pretend we apply abstraction with undoubtfully great concepts like OOP and FP?
Reactive programming can't be built without dynamic resource allocation and manangement, and without native hardware support. Reactive programming without parallel code execution is an oxymoron.
We almost there, and SILVER BULLET DOES EXIST.
Stay tuned.
Connect.
Send me a message.
Sad part about what the industry does with FPGAs... They can't even imagine doing place and route inside of the same FPGA model, like in Lisp... (they do run Yosys on softcores, but it's an overkill from hardware perspective, and definitely Yosys is not written in Verilog 😹)
I love it as an abstraction, but because function references are passed to arbitrary subsystems, it leads to not only memory scalability issues, but worse: things become unpredictably entangled. The concept of "function call" is still there (although works without IP/PC). Functions in FP are not the same as packages and blocks in digital circuits: encapsulation has unpredictable dependencies arising in surprising ways.
I tend to believe that FP is TOO POWERFUL to keep code comprehensible.
Comments added by Brian Greenforest on LinkedIn
These 5 comments were also preserved verbatim from Brian Greenforest’s LinkedIn data export or the public post page.
Comment 1 · (2021-05-27 01:35:21 UTC)
View the LinkedIn post
Comment 2 · (2021-05-27 01:43:34 UTC)
View the LinkedIn post
Comment 3 · (2021-05-27 02:48:17 UTC)
View the LinkedIn post
Comment 4 · (2021-05-27 03:03:02 UTC)
View the LinkedIn post
Comment 5 · (2021-05-29 20:11:27 UTC)
View the LinkedIn post