Computation vs. The Arrow of Time

2026-05-31

Jun 01, 2026

In the book “Order Out of Chaos” authors Ilya Prigogene (Nobel laureate) and Isabelle Stengers state that functional thinking - function-based notation - has set physics back by 100 years.

I feel that the same is happening in Computer Science.

I used to think that Computer Science was a study of the way to express what reprogrammable machines (RMs) could do.

I no longer think so. I see Computer Science as the study of how to formalize computational thinking and of how to use reprogrammable machines as building materials to build machines for computation, i.e. “compute-ers” instead of a study of what reprogrammable machines are capable of.

Lisp 1.5 was an exposition of how to use assembler-based CPUs to build machines for computing within the functional paradigm, where only the result matters and the zig-zag, irreversible path of how that result was achieved is elided and ignored. In my view, Computer Science is just an extension and further refinement and modernization of this notion.

I see this as a form of notation worship. The intent seems to be to thread every problem through the eye of the needle of the synchronous, sequential paradigm, regardless of how much accidental complexity this causes.

This is but a one-way mapping. You can use CPUs to create machines for computation, but you can’t use synchronous, sequential computation to express the composition of the asynchronous parts that make up a laptop or an internet. You can use current synchronous, sequential programming languages to create parts of a laptop - e.g. the CPU-based part - or parts of the internet (i.e. one node) - but you can’t actually express the composition of the whole, since that involves components that run asynchronously - which is - by definition - swept off the table by the underlying model of synchronous, sequential paradigm.

To express async composition, we use electronic schematics. Schematics allow for the combination of asynchronous units, like disks, CPUs, keyboards, displays, etc. Schematics ain’t perfect as a notation, but at least they don’t prematurely discard asynchronous non-sequential operation.

Inventing constructs like “async/await” in programming languages allows us to describe reactive elements that work synchronously internally but can only be coupled together in a laborious, assembler-like fashion, into compositions of asynchronously-operating units. This will never achieve the expression of the composition of async elements - something “above” and outside of the capabilities of what we currently call programming languages. Programming deals only with the synchronous, sequential action of a single node in an asynchronous system, it does not deal with the whole async system.

Multi-threading as we know it cannot be parallelism, it is only a collection of interleaved functional threads that work so quickly as to fool us into perceiving that they are working in parallel.

Example: Prolog is a non-functional language. Prolog uses synchronous, sequential programming languages, of the ilk of assembler, C, Haskell, Clojure, Rust, etc., as building materials to construct an engine for relational expression and thinking. Prolog builds relational engines using synchronous, sequential programming languages, but can never express whole parallel relational machines since asynchronousity has already been removed due to the underlying synchronous, sequential substrate.

I assert that continuing to use current synchronous, sequential programming languages to deal with asynchronous systems is a death march. It only looks like we are dealing with asynchronous, non-sequential issues, but, by using synchronous, sequential programming languages we remove asynchronousity and cherry pick problems and solutions that are already amenable to that kind of approach - a thin slice of what’s actually possible. This kind of cherry picking is causing us to miss the forest for the trees.

Arrow of time: the synchronous, sequential paradigm is a spherical cow that excludes the arrow of time for computational convenience. Once you throw out the arrow of time, you can’t put it back. You can put fake constructs like timestamps into the synchronous, sequential expression of systems, but in reality, the arrow of time is gone.

Programming Simplicity

Discussion about this post

Ready for more?

Programming Simplicity

Computation vs. The Arrow of Time

2026-05-31

See Also

Discussion about this post

Ready for more?