Anti Assimilation

2026-06-19

Jun 19, 2026

Anti Assimilation

2026-06-19

The way we build software - time-shared and centralized - is no longer appropriate for the problem domains of the 21st century, regardless of how convenient the synchronous, sequential, centralized paradigm seems.

Any code sitting atop Linux (or other even more bloated operating systems) has a base tax of about 30,000,000 lines of code on top of CPU ICs that use many more transistors than what was needed to build Sketchpad, Visicalc, Turbo Pascal, Unix V1 (UNIX was originally written in assembler, not K&R C), etc. We can do a lot better.

Continuing to build software the same way over and over again, expecting different results is a death march based on unwillingness to accurately assess the cost of doing so and based on the belief that there is only one purpose for “computers” (a better name might be RM - Reprogrammable Machines).

Pure functional programming - modern Sector Lisp - costs about 354 lines of assembler. Most other programming languages pay a huge tax for stretching and generalizing the functional programming model.

We need to think outside of the box of the synchronous, sequential, centralized model. Machine code and ICs can support many more kinds of models than just functional programming (K&R C may have been a convenient abstraction, but, subsequently, C has been distorted into a functional programming language (albeit flawed) replete with function-based calling conventions).

Progress should result in less code. I don’t believe that this is happening.

Our current programming model makes us believe that issues - e.g. assignment, synchronous concurrency, asynchronous parallelism, thread safety, control flow - falling outside of the functional, synchronous, sequential model can be ignored or simply assimilated. Yet, Harel came up with a better notation for one of those issues some 40 years ago (Statecharts for reactive control flow). I think that we should be using models for programming that allow us to compose solutions using many paradigms, each with laser-focused languages to support them - specialization instead of generalization and the kitchen sink approach. Decentralization instead of centralization and assimilation. Eliminating problems instead of laboriously assimilating solutions to them.

Switching to a decentralized model could eliminate the issue of thread safety. Simply eliminating thread safety concerns would noticeably reduce the size and complexity of programming languages. Since the main role of operating systems is to act as scaffolding to support the functional model, can something be done about that issue?

Everything we’ve accomplished in the past 50 years fits inside just one of the bubbles on my diagram labelled “app” in a previous article. We haven’t really addressed the rest of the stuff, other than by applying notation worship to assimilate each new gotcha, in a whack-a-mole manner, into the ball of stuff that we already have. Grace Hopper warned against this approach.

Functions and math-like notation (mangled by 500 year-old Gutenberg technology) aren’t the only way to program the things we call “computers”.

It is entirely reasonable to specialize and drill down onto a thin slice of programming. But, it must be remembered that this is not programming, it is just a thin slice of programming. Looking at all problems through a single lens has a cost.

Programming Simplicity

Discussion about this post

Ready for more?

Programming Simplicity

Anti Assimilation

2026-06-19

Anti Assimilation

See Also

Discussion about this post

Ready for more?