How C Accidentally Locked Programming Into a Single Paradigm
A Paradigm Past Its Expiration Date 2025-11-20
Modern ANSI C no longer resembles 1973 K&R C. We (the royal “we”) veered off and concentrated on function-based programming, using only text which then led to the need for intense type-checking that causes syntactic pollution of programs.
Our modern programming languages concentrate on the manipulation of equations in the form of 500 year old technology based on Gutenberg type-set equations, and, thus, have less and less to do with the actual low-level realities of basic CPUs.
C - maybe inadvertently - was marketed to students. At the time, there was no such thing as “open source” and it was essentially impossible to easily/legally view the innards of compilers. The fact that UNIX and C source licenses were fed to universities and to their students caused young, malleable minds to believe that this was the only way to write programs. C didn’t invent function-based programming, but was key to popularizing the technique, due to the marketing efforts behind it.
Compiler research was on the track of figuring out how to deal with the realities of CPUs, but got derailed by the over-emphasis on function-based “programming”. Function-based thinking isn’t compatible with the full gamut of operations available to CPU-based machines.
Languages that weren’t function-based, like Forth, Prolog, UNIX pipelines, etc. were summarily sidelined and ignored.
CPUs are but a building material. Multi-threading is easy unless you try to force it through the eye of the needle of the function-based paradigm. CPUs are more than just “better paper”, but, our current spate of programming languages cannot reflect this fact.
Function-based programming (and its descendant FP) is but one paradigm available for programming. There are other paradigms available for solving problems in different kinds of domains if only one removes one’s function-based blinders.
One of the problems is that we continue to strive to shove all paradigms into a single language, instead of simply using many languages and many paradigms. For example, assignment doesn’t belong in any language that is based on the the use of functions.
The word “function” means one thing in mathematics, but has been co-opted to mean something else in Computer Science, yet, we keep trying to beat programming back to having paper-based mathematical properties. “Referential transparency” was a solved problem long before FP (and C) came about. It was, and still is, called “pin for pin compatibility”. Referential transparency is mysteriously difficult in function-based programming because of the over-use of the function-based paradigm with its inherent synchronous/sequential aspects. (We don’t need to delete side-effects, we just need to contain them better).
We’ve painted ourselves into a corner by basing every popular programming language on a single paradigm (function-based). Rust is function-based - the language has to jump through hoops with complex type annotations because it’s trying to solve problems (safe concurrency, memory management) while staying locked into the function-based model. Python is function-based, Javascript is function-based, Clojure is function-based, etc.
We’re wasting brain-power inventing epicycles in order to crawl out of the corner we’ve painted ourselves into. When CPUs were wildly expensive, it made sense to waste brain-power instead of silicon power.
Now, though, we can stop doing that.
See Also
Email: ptcomputingsimplicity@gmail.com
Substack: paultarvydas.substack.com
Videos: https://www.youtube.com/@programmingsimplicity2980
Discord: https://discord.gg/65YZUh6Jpq
Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas
Twitter: @paul_tarvydas
Bluesky: @paultarvydas.bsky.social
Mastodon: @paultarvydas
(earlier) Blog: guitarvydas.github.io
References: https://guitarvydas.github.io/2024/01/06/References.html