Understanding Smallness and Speed https://open.substack.com/pub/programmingsimplicity/p/understanding-smallness-and-speed?r=1egdky&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true

A good starting point for a scientific exploration is gathering examples for case studies. You listed mostly lean code of the past vs. bloated code of today. Is there lean code today? From my domain of work, I can cite high-performance computing. Modern code in HPC is no more bloated than the code of the past, at equal functionality. Hypothesis: constrained resources encourage lean code. Other environments with resource constraints are probably interesting to look at: embedded devices, IoT, retrocomputing, intentional minimalism (which is where I'd place Sector Lisp).

Thanks! Most interesting. Pondering… meanwhile: • To me Sector Lisp’s size was a surprise. I went in thinking that it was all due to assembler tricks. Clearly intentional minimalism. Eventually, though, I concluded that its small size was overwhelmingly due to the way it treated the paradigm. It implements the functional paradigm and treats it in a pure manner - no assignment, no heap, no attempt to deal with the full gamut of the underlying hardware and opcodes. I interpreted this as unintentional minimalism, although I’m not sure that this is a correct interpretation. Now, I’m wondering if what I call bloat is caused by the intentional unioning of multi-paradigmatic features into GPLs (which makes me question if GPLs are the right path)… • Tougher questions: What is code size? Does increasing transistor count reduce code size? What is “programming”? I don’t think that “computing” defines all there is to “programming” - why do I think this?

We are still in the period of infatuation with a new toy, Turing-complete computation. We will probably figure out one day that computation is just a means to an end and that we should focus on the end. Fewer "general purpose", fewer "universal", etc. Computation as an aspect of technical devices, not as the definition of a type of device. And then we can come up with more interesting measures of complexity than "code size". Until then, let's count the microcode in the processor as code as well, no matter how much Intel will protest.

Yet further belabouring the point, I'm thinking that modern PLs sitting on top of bloated OSes (Linux ~40M LOC, Windows ~50-80M, macOS ~80-86M) suggests we've had code bloat baked in from the start — and while alternatives exist (MicroPython, Forth, etc.), continuing to stretch the current OS-dependent programming model to fit non-HPC problem domains is like adding epicycles.