I finally got around to Dave Ackley's latest video report on robust-first computing which @curious_reader shared here, and it prompted me to zoom out and think about the territory of computation and what we know of it so far in the year 2025. Right now I imagine it as a 3D terrain. Along one axis, analogous to a plan view, I see the following coarse technical approaches to structuring computation, each equally valid: • Computation as the orchestration of precise instructions. • Computation as the learning of matrix weights. • Computation as the orchestration of fuzzy, imprecise cellular automata. Ackley's approach. I think that's it? Are there others? Along an orthogonal axis, analogous to an elevation view, I see social approaches to organizing the means of computation. So far we only have open questions here: • Does computational infrastructure necessarily require authoritarian dictators or at best feudal lords and vassals? Or is it possible to have something analogous to a democratic approach? • Can we reduce inequality between the haves and have-nots of tech knowledge and computer whispering? • Can we design incentives to keep computation working over time, in a secure and trustworthy way? (Can computation ever be biased less towards offense, can defense be viable?) • Can we design incentives to make the means of computation sustainable in their impact on the environment? And along a second orthogonal axis, analogous to a side view, I imagine ways to connect up computation with other fields of human endeavor. Here there has been much progress, though I am running out of steam: • Learning from the arts to improve visual and auditory design, e.g. typography. • Learning from math to better model the world, e.g. numerical methods. • Learning from the social sciences to nudge groups of people in productive and unproductive directions. Coevolving populations with these lessons that will inevitably grow robust to such nudging. • ...? Feel free to point out gaps, additional axes, add examples..

In the end computers tend to end up executing precise instructions anyway. The first approach that you listed is the bedrock abstraction that the second and third approaches are built on top. In principle it's possible to build machines that would implement other approaches natively but doing so is rarely practical (1, 2 & 3-d cellular automata are some of the exceptions). I think the question that you asked ("are there others") is the main reason many of us are here 🙂 From the back of my memory, there is: • quantum computing (another case where building a native computer is essential) • spiking neural networks • expert systems, also fuzzy ones • fpga-style logic networks • a few cryptographic approaches (ethereum / unison / white-box cryptography / zero-knowledge proofs)

There is a lot of passive mechanical computation in existence. For an underwater robot we added floats to the bottom of our rotating wifi antenna so the antenna went vertical when on the water surface (maximizing range) but folded flat when underwater (reduce drag for locomotion). This is a genuine computational device relying on a non-linearity and "programmed" by positioning hinges and orientated w.r.t. gravity and the environment to get a designed behaviour. A toilet flush is quite a complicated but common one. I consider these closed loop control systems but the feedback computation is done without silicon, which is often much more robust albiet limited in expressivity. They don't require electricity to run, but in these two examples they are powered but with kinetic energy (and they lose energy via heat losses like everything powered).

For the first axis, there are probably many candidates, depending on how "mainstream" we require them to be. Quantum computing is an obvious candidate, as @Marek Rogalski pointed out. There are also more exotic ideas, such as the Chemical Abstract Machine . On the other hand, I'd remove "learning of matrix weights" from the list as long as it is implemented strictly in terms of the preceding technique in the list. Just to punish laziness.

I don't care too much that one metaphor is built in terms of another, or which kind is most fundamental. That kind of reductionism seems unimportant here.

I agree. But if you want to map out the space of computation, you have to say somewhere what you mean by computation, at least roughly. I have witnessed two heated debates, between academics of different disciplines, on the question "is the brain a computer?" In both cases, it turned out after some rounds of shouting at each other that each participants had a different view of what "computer" means. At one extreme, it was "a physical system capable of processing information", at the other extreme it was a deterministic system with a clear separation of hardware and software layers.

Yeah. Perhaps it would help to clarify that I'm thinking in this thread about the experience of getting some desired behavior. What does the inner experience of "programming" feel like. So the technical part of my OP was, you can program by engaging with syntax and semantics, or by running tons of data through an algorithm to tweak weights, or by whatever mechanism Dave Ackley is doing that I don't understand but definitely seems much more fault tolerant than syntax and semantics. Expert systems and relevance work do feel like first-class different experiences. Maybe related to neural networks? In all 3 the feedback loop seems definitely dilated. There's no equivalent of adding a semi-colon in response to an error message.. I don't know enough about quantum computers to know what the activity of programming them feels like. So open question. Is it just libraries that run on a coprocessor with weird time complexity properties, and some barriers to adjusting function boundaries (to avoid observing at the wrong time)? Or is there more to the experience? FPGAs don't immediately feel different in the same way. My rough sense is you compile the same conventional languages to commands that configure logic gates. It's akin to compiling down to Verilog. Though there's some weirdness in terms of seemingly simple things in software that explode to take up tons of gates. That might make programming them feel different. Similarly, DAOs on blockchains seem like regular programming, just less flexible? Once it goes on the ledger it's hard/impossible to change.. They're probably slower, but we also have lots of experience with slow languages 🙂 ZK proofs do feel fundamentally different. I have some sympathy for the idea that analog computation and reversible computation feel like their own experience. But I don't know enough to be sure. I also have some sympathy for the idea that programming a game feels very different than other kinds of programming even if you're using similar languages and tools. There's a level of mechanism design and tuning for playability that's gestalt rather than detail-oriented in a way that I've never quite been able to grok. And that barrier is always an indication it's a whole different activity.

OK more on target then: programming an LLM system is quite a different beast (build benchmarks, iterate on prompt, think about context, lots of second guessing the LLMs thought process)

Programming with an LLM seems a little bit like being a manager. Which gets to @Konrad Hinsen's idea of other people as a substrate to delegate work to. Arguably the oldest programming of all.

Using an LLM (1) is different to building a system around LLMs (2). 1. is managerial. 2. is herding cats and involves a lot of probabilistic reasoning.

Is 2 what you meant in your previous comment? I don't quite understand this kind of system building. Say more?

Yeah, building a system that uses an LLM internally ends up more like applied science. In normal programming you get deterministic results. When you embed an LLM you get this thing that kinda does what you want some of the time, so you have to deal with the rate of failure in a methodical way, and you tweak things to improve the rate of failure. So its quite a different way of programming. This is different than using an LLM, coz in that situation you have a goal and you are both coordinating to achieve that goal, so some of the work gets done by you (e.g. code assistance). If you are giving an LLM powered product to lots of people, you have more unknowns and you can't apply test-driven-development or anything like that. So its different. Its still development, but its quite different to distributed systems where the rate of failure is relatively low and there are clear reasons why it behaves the way it did. LLMs you are programming where every function call is a roll of the dice modified by free text. The methodical way of taming that is evals at scale, which doesn't fit in a CI process, costs money etc. etc.

@Kartik Agaram Focusing on the experience makes this a much clearer exercise! For quantum computing, the main experience is the paperwork of getting access to one. Once you do, it feels much like batch processing in the past: you submit your program via some front-end (a standard computer), and wait for the result. The program has syntax much like a standard program, but its semantics are wildly different. Analog computing is more interesting. It feels much more like doing an experiment in a lab than like running software.