Can systems function correctly without memory?

Question

I&rsquo;ve been thinking about whether memory is actually a runtime requirement for correctness, or just a training signal whose effects persist even when recall is no longer needed.In practice, many distributed systems accumulate complexity because they treat state as something to negotiate with rather than something to enforce against. When systems attempt to reconcile past states in order to act in the present, they often generate retries, reconciliation logic, and coordination overhead just to stay consistent.I&rsquo;ve been experimenting with an enforcement-first pattern where every interaction is treated as a first-time request, invalid states are refused rather than repaired, and state is carried explicitly by the request itself. I put together a minimal reference implementation to make the idea concrete.I&rsquo;m curious where people think this model breaks down in practice, and which classes of systems truly require narrative state rather than local constraint enforcement.https://github.com/SvengsFuture/stateless-substrate

thinkingkong · Accepted Answer

Well&hellip; if you look at pure functions without ant state then thats a whole class of computing you can refer to. The problem is that its not efficient to calculate state from arguments for everything. We end up saving to disk, writing packets over the network, etc. In a purely theoretical environment you could avoid state, but the real world imposes constraints that you need to operate within or between.Additionally, depending how deep down you go, theres state stored somewhere to calculate against. Vues are stored in some kind of register and theyre passed into operations with a target register as an additional argument.

PaulHoule · Answer

It depends on what kind of system you're talking about.
If you have no memory, that memory can't get corrupted.
If the memory is carried by the request the memory can't get desynchronized with the request.
You can use cryptographic techniques to prevent tampering and even reuse of states, though reuse can be a feature instead of a bug. Sometimes the state is too big to pass around like a football but even then you can access it with a key and merge it in in a disciplined way.

rlupi · Answer

Rigidity in inputs lock down your system's evolution. The whole system need to evolve in lockstep if you need to change what the systems processes.
In practice, you either end up with an enlarging monolith or introducing state evolution (either explicitly, or by adding incremental input types that the system processes and expanding its API surface).
Beyond a certain inflection point of complexity, flexibility in introducing change becomes necessary.