On Bloatware

2025-05-04

May 04, 2025

Muratori blames bloat on USB and Plug'N'Play.

I think that the problem is even deeper than that.

I think that the problem is caused by the function meme.

CPUs do not implement functions, CPUs implement subroutines. When the word "function" is used, people think that CPUs are just math processors, or compute-ers. Since the invention of "C", the distinction between pure functions and subroutines has been blurred and CPU manufacturers have been driven to make CPUs into FP (Functional Programming) machines, kinda like if they implemented Lisp machines and Forth machines that were wished for. Lispers and Forthers didn't get what they wished for, but FP'ers did get what they wished for.

The result is that programmers appear to think that "programming" is the act of writing more-and-more-pure functions, and turning every problem into a set of clockwork equations for compute-ation.

FP is a good paradigm, but it has been abused and pushed way out of its sweet spot by the forced addition of anti-FP concepts like mutation, assignment, concurrency, heaps, etc. The result: bloated hardware and extremely bloated software. If one thinks that one must use functions, then one is compelled to implement context switching and virtual memory. And, one is encouraged to think that everything is synchronous. Synchronousity is the anti-thesis of asynchronousity. This is probably why I keep mentioning Sector Lisp. Sector Lisp demonstrates how small and simple the FP paradigm can be and how bloated software is when only the FP paradigm is used (think "epicycles").

This appears to be coupled with a deep-seated belief that there must be one-language-to-rule-them-all. We don't need more synchronous, function-based languages. We need ways to use many languages/paradigms within every project. Custom languages, not general purpose languages. UNIX pipelines show germs of ideas for what can be done, but, got pushed aside because of their association with then-slow spawning of processes and over-blown hardware support.

What can you do with processes and PBP (Parts Based Programming) that you can't do with functions? Feedback. Multiple inputs over time. Multiple outputs over time. Massive parallelism. Mutation. Heaps. Note that the concept of "multiple" inputs and outputs in current PLs is a white lie. These things only pass around single blobs of bits all at once. Later destructuring fools programmers into thinking that the singular blobs are somehow multiple, but, destructuring simply lays different templates over each blob as a whole. Processes are but Greenspunian implementations of anonymous functions and closures.

Can one implement a subset of pipelines as nested functions? Yes. Can one implement something beyond nested functions using processes? Yes. For example, feedback and FIFO calling protocol instead of LIFO calling protocol (wait in line vs. jump to the front of the line).

What are the tells that something smells wrong with our current PLs? Bloat. Callback hell. Mars Pathfinder. Increasingly complicated ways to work around anti-mutation and concurrency (monads, sync/async/.then, etc.). The idea of hygienic macros vs. simpler macros. The idea that text-to-text manipulation must co-exist with other programming constructs inside only one-language-to-rule-them-all. We have been told to not use "eval" and to allow only high priests of programming to use "eval" ("compiler" == "eval"). Are macros different? Lispers are allowed to use macros, but such macros must be conflated with other programming concerns in the same programming language AND macros must be hygienic regardless of how bloated the result becomes. Hygiene becomes a nothing-burger if macros are split away from a programming language and run as separate thingies, like compilation is.

Conflating FP with mutation and macros and concurrency brings bloat. Instead, we need one different language for each different concept. Not one language for a mashup of all of these concepts at once. I keep harping on PEG and OhmJS and my experimental T2T stuff because they show that you CAN fruitfully separate these concepts out of PLs, resulting in de-conflation and de-bloatification. Developers do need big, fat machines that perform context switching, but end-users don't need that stuff. My 100 year old mother is required to pay $$$ for a developer-level machine just to run Tetris or to read books online, etc.

On what do I blame for this bloatiful meme?

C is not "close to the hardware" because it erased the memetic difference between subroutines and pure functions. In C, everything is called a "function" even when such functions are not mathematically-pure functions. Programming is not math. A subset of programming CAN be implemented using FP written on papyrus using quills, but that is only a subset of what can be done.

Yep, the words "function" and "subroutine" are just words. The pen is mightier than the sword, language affects thought, and all of that. Simple mis-use of these words has brought us bloat. A butterfly flapped its wings in Asia and now we have tornados in North America.

Programming Simplicity

Discussion about this post

Ready for more?

Programming Simplicity

On Bloatware

2025-05-04

See Also

Discussion about this post

Ready for more?