Escaping Function-Based Programming

2025-01-04

Jan 04, 2025

Use a version of XXX (Lua, Rust, Python, etc.) that runs on bare hardware, not on an operating system.

Forth did that. Lisp 1.5 did that. Smalltalk ran on top of micro-code and used an O/S to handle file systems, display management, networking.

The original idea of an operating system, was to provide a few common routines (file systems management, display management, networking, etc.). This concept has grown into a bloated monster. Instead of bolting the common routines together via asynchronous message passing, as if the libraries were implemented on isolated pieces of hardware, we bolted them together with synchronous function calls. This has resulted in a huge, strongly-connected blob of software that causes scaling headaches and extreme fragility.

Function-based programming is a diversion supported by the existence of context-switching.

Context-switching, itself, is inefficient and needs extra software and hardware (MMUs, etc.) and is based on 1950s concerns about time-sharing needed to amortize the co$t of CPUs. Time-sharing, actually, does not provide multi-tasking. It just time-shares a CPU so quickly that humans can’t see what’s really going on.

Synchronous programming languages make it more difficult than necessary to express asynchronous behaviour. Hence, we get a continuous string of gotchas, like callback hell, .then, etc.

Function-based programming is a powerful paradigm, but becomes a burdensome crutch when over-used.

Compile to bare-hardware state machines and 0D[1].

Compile to bare-hardware Statecharts[2].

Compile to CPU-less 1972 Pong[3]. The original Pong didn’t use a CPU. The design was massively parallel. In spite of that, the designer managed to design Pong and didn’t need to use a synchronous programming language.

Modern versions of Pong, say written in Lua[4], are just as complicated as the original schematic. They’re just different. We’ve moved side-ways, not upwards.

The Production Engineering Piece is Missing

Too much emphasis on how to optimize the development experience based on 1950s primitive ideas about IDEs (aka “programming languages”), instead of optimizing away bloatware.