Feeling of Computing Weekly 2026/03 Week 5

Would love for y'all to add input here. This idea is pretty exciting to me. I'll have more longform thoughts on what I'm building and where it fits soon, but figuring out this metaphor together is an important way to start. A collective mental model is the first step towards collective action.

If you want to participate in the Ecological Computer, we're on our way.

two-minute-week

💬 guitarvydas: Schmitt trigger

🧵conversation

Your description reminds me of a Schmitt trigger used in electronics. One can implement a Schmitt-trigger-like action in the digital domain with a state machine:
S1: when a 0->1 event occurs, go to state S2.
S2: when a 1->0 event occurs go back to state S1.
(I think of the timer variant as a Schmitt trigger that deals with analog signals).

💬 maf

🧵conversation

I guess observable enthusiasts around here may find this one interesting! I'm designing a way for object to "act together" in a more natural way. This involves objects that do stuff (as opposed to simply computing a value) and that can generate their own events. Examples on the video are a Timer (which can be started/stopped and will stop itself automatically after some time) or a KeyPresser (which can be pressed down/released, based on the physical keyboard's keys but may also generate synthetic events, according to notifications received from other objects).

On the video you can see a simple Timer-based limiter, that releases the space after half a second. I can press the key myself, and that will cause Automat to start the Timer (you can take a closer look at the hand over the Key Presser - it shows whether the key is pressed or not). And then after some time, Automat will release the key for me. If I release the key sooner, the Timer is cancelled. You can see that the flow of information is multidirectional. The direction is indicated by the movement of belts between gears. That's the first half of the video.

One fundamental issue of these observable systems is that the computation would loop forever if the objects just announced their new state on every change. Typically they are only evaluated once, according to some topological sorting (most observable systems don't allow loops) and they also store & compare their state to prevent redundant updates (optional optimization in loop-free reactive systems but absolutely necessary if loops are allowed - it's the stop condition).

(terminology: many people call this "feedback loops" and treat this as an undesired behavior, but IMO there are places where feedback loops are a sound solution, so I'll call this "reactive echo" - it's when an object changes state but then notifies the source of the change of its change. Another reason is that "reactive echo" doesn't really need to cause a loop - the issue is that a change notification is accidentally sent back)

None of this is new - it's a pretty well known pattern. Fun things start when the OS is involved & objects start to flip-flop fast. This happens when I create a loop with the Timer. This is the second part of the video. The Timer switches itself off & on - but it happens pretty much instantly. This off/on switching still generates notifications for the Key Presser - so it sends the events to the OS. And some time after, the OS sends these events back to Automat. There is a delay caused by the OS. The events differ from the internal state tracked by the Key Presser, so they must be announced to other synchronized objects, causing the Timer to stop & restart instantly. The flow of events is:

I press the key down => "ON" notification sent to the Timer
Timer completes => "OFF" notification sent to the Key Presser, which posts a synthetic "release key" event
Timer restarts => "ON" notification sent to the Key Presser, which posts a synthetic "press key" event
OS sends back the "key released" event to Key Presser => "OFF" notification sent to the Timer (uh oh! it's a reactive echo!)
OS sends back the "key pressed" event to Key Presser => "ON" notification sent to the Timer (again - it's a reactive echo!)

The last two events should not be there. But the causal chain of reactive echo escapes the process and arrives back with a delay so it cannot be reasoned about in a local fashion. There is no portable way to distinguish synthetic vs natural events so they cannot be simply ignored. I cannot even attach anything to these events explicitly. They're pretty much indistinguishable from real user events.

As you can see on video, it actually works fine - this is because Automat is now using a completely different way to prevent the reactive echo (Automat has five different echo cancellation mechanisms, lol). I like this one the most because it's using a strategy known from biological neurons. You won't find it in the artificial ones! The real biological neurons have an inhibitory period that they enter after firing. This allows them to prevent back-flow of information in a completely distributed fashion - without the need for a central orchestrator that will sequence their activations in topological order - and without the need to track & compare any internal "value" (neurons store no bits - they just "fire" & rest). The way it works in Automat is that whenever a Key Presser sends an event, it records a timestamp - it's the start of its inhibitory period. For the duration of this period it will ignore the next event received from the OS. Very simple solution actually, and widely used in nature - but not so much in engineered reactive systems. But if you think about it - it could be!

📑 Resources

2026-04-01 15-11-03.mp4

👨🏽‍💻 By 🐘 @[email protected] 🦋 @marianoguerra.org

💬 Not a member yet? Check the Feeling of Computing Community

✉️ Not subscribed yet? Subscribe to the Newsletter / Archive / RSS

🎙️ Prefer podcasts? check the Feeling of Computing Podcast

Feeling of Computing Weekly 2026/03 Week 5

2026-04-11 14:52

linking-together

share-your-work

thinking-together

two-minute-week