Robust-first computing: Beyond efficiency

Me to, and I'm always battling with the LLM's obsession with lazily writing reams of ridiculously defensive code and masking errors in the code it generates and calls, instead of finding the root cause and solving that. (Yes, I'm referring to the code LLMs generate, not the API for generating code itself, but "fail early and spectacularly" should apply to all code and apis.) But you have to draw the line at failures that happen in the real world, or in code you can't control. I'm a huge fan of Dave Ackley's "Robust First" computing architecture, and his Moveable Feast Machine. His "Robust First" philosophy is extremely relevant and has a lot of applications to programming with LLMs, not just hardware design. Robust First | A conversation with Dave Ackley (T2 Tile Project) | Functionally Imperative Podcast link Robust-first computing: Beyond efficiency ▶ this video Bottom up engineering for robust-first computing link Living Computation: Robust-first programming in ULAM link link DonHopkins on Feb 11, 2020 | parent | context | favorite | on: Growing Neural Cellular Automata: A Differentiable... Also check out the "Moveable Feast Machine", Robust-first Computing, and this Distributed City Generation example: link DonHopkins on Oct 26, 2017 | parent | favorite | on: Cryptography with Cellular Automata (1985) [pdf] A "Moveable Feast Machine" is a "Robust First" asynchronous distributed fault tolerant cellular-automata-like computer architecture. It's similar to a Cellular Au

You might be interested in 'Robust First Computing' - link edit: here is a far better explanation by the terms creator: ▶ this video

I am happy you don't agree on modularity. I don't want to be correct, I want to arrive at correct conclusions. :) Composition is great, scale free self similarity is probably the basis for the universe. Modularity is a great design technique, it can also make things weaker and force other (unknowable) design choices because the module boundary prevents the flow of information/force. Overly constrained modular systems encourage globals, under constrained modular systems are asymptotic to mud/clay. I don't want to use K8S as a strawman to attack modularity, but I think it is an example of using this powerful design tool to solve the wrong problem using mis-applied methods all the while being more complex and using more resources. In the case of designing systems, modules/objects/processes (Erlang sense) are critical, but not so much in building/engineering them. Demodularizing or fusing a design can make it more robust and more efficient. I don't dislike modularity, I just think it is a bigger more complex topic than most give it credit for. Unix is highly-non modular and very poor composition. It sits on a molehill of a local maximum, itself sitting in the bottom of a Caldera, a sort of Wizard Mt on Wizard Island. Other things you might like is the research around "Collapsing Towers of Interpreters" [1] Or Dave Ackley's T2 Tile Project and Robust First Computing [2] Would love to chat more, but internet access is spotty for the next week, non-replies are not ignores. [1] [LINK

then you'd debug it, or program debuggers to flit around looking for programmer error then address it the system is clear about its capabilities regarding 'correctness' which seems to imply the programmer's job is to optimise with those built in inaccuracies but what those inaccuracies afford is what ackley is calling robustness and indefinite scalability ackley addresses your question directly with a sorting comparison(o) from a later video the graph fails to exhibit where maxwell's demon(i) horde sort would express itself on the graph, but sorting corruption is addressed in the paper(ii) The demon horde sort’s performance may be just adequate, by that measure, but its robustness seems quite impressive. Figure 23 shows results of one experiment in which we randomly corrupted site memory with simulated bit errors at a range of probabilities. Each error occurrence selects a random site and then flips from one to eight of its 64 atomic bits. We can see that while channel length helps performance, it does not help robustness against this system perturbation— but the system is strikingly robust anyway, tolerating upward of 10 multibit corruptions per million events with essentially no visible performance degradation, regardless of channel length. Above about 50 errors/Mevent the system reliably falls apart—and the pathology appears to run a reliable course.. unintended performance appears to be the reason for the advent of this system but going further as to deal with unintended