<https://programmingsimplicity.substack.com/p/the-...
# share-your-workk
Konrad Hinsen
10/07/2025, 11:26 AMI don't think that "Stockholm Syndrome" is a good label for what you describe. Computing hasn't become the victim of some evil outside force. It has become the victim of its success, like so much other technology. It evolves through incremental improvement, not through revolution, because incremental improvement yields immediate pay-off whereas revolutionary innovation would most probably just fail for lack of adoption.
x
xyzzy
10/07/2025, 12:11 PMC++ which has co-routines, although 30 years late and thread-safe queues should be sufficient for Message Passing right ?
g
guitarvydas
10/07/2025, 4:04 PMThere likely is a difference in how I think of computation. I think in a very hardware-centric way.
Incremental improvement is good, but has its down-sides, too, like the Mars Pathfinder fiasco, callback hell, Ptolemaic Cosmology, etc.
Previously, you said something that resonates with me. We have what we have. Period. Can we use it in some different manner? I think so. I think that the ingredients are all available: queues, closures, tagged messages, main-loop meme extended to be recursively defined (like, say, Lisp lists, or bash scripts that call other bash scripts), UNIX process and pipeline memes (actually, the pipeline meme runs so much faster in 2025 that shelling-out becomes a practical strategy for program development, in my mind (we /can/ use multiple languages if we want it (John Lennon))), etc. We don't need wild new hardware and we don't need to dump the code that we have. I think that it boils down to only a psychological issue, not a technical issue(s).
@Konrad Hinsen
guitarvydas
10/07/2025, 4:32 PMIn my mind, the model of Message Passing is two completely separate computers. Say, Arduino A running one thread and another thread on ESP32 B. Two thin uni-directional wires between them. No memory sharing. We needed to worry about thread safety and the politically correct verbiage for time-sharing (later rebranded as "multi-processing") back in 1960/1970/etc. We don't need to think that way any more. Thread safety, red/green threads, co-routines, 55,000,000 LOC operating systems are just inefficient ways to use computers. Apple made zillions of $'s by stuffing CPUs into printers (postscript printers) back in the day. An acquaintance told me about his horse-racing technology - he hung 30-ish computers off of each horse (in the stable), each one running micro-python essentially executing one main thread. Then, he asked me how to make it "better". I took his question to mean how could he complicate the design and told him not to change anything. The missing piece of technology didn't obviously exist at the time (a way to coordinate the computers in layered form instead of in an infinite canvas form (hence my train of thoughts on 0D/PBP)) @xyzzy
k
Konrad Hinsen
10/07/2025, 6:12 PMI can see how your architecture would work for some kinds of computations, roughly summarized by "data flow". But there are other kinds, roughly summarized as "updating state", where I don't see how it could be done if the state cannot be distributed efficiently.
2 Views