Anti Assimilation
Paul Tarvydas
 | |
Raoul Duke
Paul Tarvydas
"Thread safety" is but a piece of accidental complexity caused by mapping the theoretical concept of synchronous "concurrency" (which is not the same as asynchronous "parallelism") onto synchronous, sequential hardware, such as a single CPU, using shared memory between processes.
The thread safety issue can be wiped out by using processes that don't share memory. For example, nodes on an internet do not share memory and don't cause thread safety issues between one another. Software implementing a node can choose to continue to use a shared memory model internally, and, hence, will not fully benefit from the simplicity of eradicating thread safety. Internet nodes are asynchronously parallel, but software inside nodes that use memory-sharing concurrency based on the synchronous, sequential paradigm cannot be parallel and are only synchronously concurrent.
Multi-core, as I understand it, doesn't give full relief from thread safety issues.
Switching to a pure message-passing paradigm internally will cause evaporation of thread safety concerns. Using function calls only looks like message-passing, but is actually an impure form of message passing (I don't know of a name for this impure form ; functions block when calling other functions, hence, also pass control flow along with message data). Just about any modern programming language, especially those that conform to "calling conventions" fall into the category of being accidentally complexified.
I'll see if I can come up with a better explanation that de-conflates these issues. This will require some more thought and time...
Raoul Duke
Paul Tarvydas
That’s what Software Architecture is for. Trying to generalize the solution (as was done with thread safety) only bloatifies the result.
State isn't actually bad. Reality contains state. State within the FP paradigm is bad, though.
Programming languages based on the synchronous, sequential paradigm (i.e. most current PLs) make the use of state very clunky (global variables, if-then-else, blobs of state passed around as data, etc). That is a "tell" that this issue should be handled in a different notation. I kinda like Harel Statecharts, as previously mentioned.
Languages like Prolog, Datalog, Ceptre, Nova, and concatenative languages are different (non-FP) approaches to the issue of state. Ceptre is based on linear logic. There are many ways of doing this other than by just doing the same thing over and over and expecting different results.
Automagic state coherence is just an inefficient trick that architects should be allowed to choose to use when necessary, instead of having it hard-wired into hardware and programming languages.
aside: SIMD and SIMT are just other automagic tricks that are very optimized for a narrow range of use-cases (graphics, GPUs), but, are just albatrosses around the necks of other use-cases.
The strive for generalization makes us feel that the solution to every conceivable problem must be spoon fed to us. Software Architects should want access to specialization and LEGO-like parts and layers. That's not what we have at this moment. It's within reach, though. It's mostly just a mind-set problem.
On Jun 19, 2026, at 9:48 PM, Raoul Duke <rao...@gmail.com> wrote:
still doesn't fix the core issue of state coherence / consistency
--
You received this message because you are subscribed to the Google Groups "PiLuD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pilud+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pilud/CAJ7XQb6Kyxtw3jELtxXiWjGA%3D%3DDR9LM%2BfaeL4zWx5Hm0s%2BWvHg%40mail.gmail.com.