Diversifying Programming Workflow
2025-08-04
Programming Workflow Based On Only One Paradigm
The use of functions to write machine code has become so prevalent that it seems to have been forgotten that we don’t actually need to do things this way and only this way.
Binding and Mutation
The bind operation is a mutation operation that affects memory and affects CPU registers. The idea behind functional programming is to prevent programmers from having to explicitly specify mutation. Functional programming and the simpler idea of function-based programming implements mutation under-the-covers.
Not All Programming Paradigms Are Function-Based
Aside: an interesting alternate use-case is that of the Prolog language. Prolog code looks like functional code, but, it operates very differently.
Prolog implements a mechanism for performing exhaustive search.
Implementing exhaustive search in a function-based manner is certainly possible, but entails more detailed, lower-level work, consisting of coding up loops within loops. This introduces more opportunities for programming errors.
Prolog engines make different trade-offs when using CPUs and subroutines.
Prolog code isn’t necessarily smaller than that of function-based code, but, for certain programming use-cases, like specifying searches, the Prolog method helps programmers make fewer mistakes. In other use-cases, like string manipulation, the Prolog method makes programming more confusing and more error-prone. I argue that it is easier to reason about string manipulation in Javascript or bash than it is in Prolog.
Engines and Paradigms
Off-the-shelf CPUs have been used to implement many different paradigms, like
Forth
Postscript printing
Tiny Basic
Lisp 1.5
cartridge-based games
Forth-based telescope controllers
Forth-based computer boot monitors
UNIX pipelines
etc.
Ever since the “C” language became popular, though, the software industry has focussed on only one main paradigm - the paradigm of function-based programming. Function-based programming creates parameterized, value-returning, clockwork subroutines.
Function-based programming has led to current-day notions about Functional Programming.
I argue that “C” is not a low-level programming language, but, that it is a “gateway drug” for ideas like functional programming.
The function-based paradigm requires that calling functions pause - block - when waiting for return values from callees. Blocking requires extra scaffolding called operating systems.
The function-based paradigm requires that called functions follow one and only one dataflow protocol, i.e. the protocol of returning a result to the caller instead of sending information to other receivers (which is called “side-effects”).
These requirements oppose reasoning about asynchronous systems. It is possible to write programs for concurrent systems using the function-based paradigm, but, this requires extra work. This extra work is called “workarounds” and “research”. In Copernicus’ day, this kind of extra work was called “epicycles”.
Functional thinking adds additional semantics (and code?) by default to every subroutine and to every subroutine call. Programmers accepted this cost due to the fact that early computers were essentially calculators, where only the results mattered and the actual control of sequencing (control-flow) could be ignored. Today, though, we are faced with massive parallelism in fields like internet, robotics, IoT, etc. and should be using notations better-suited to such problems.See Also
Email: ptcomputingsimplicity@gmail.com
References: https://guitarvydas.github.io/2024/01/06/References.html
Blog: guitarvydas.github.io
Videos: https://www.youtube.com/@programmingsimplicity2980
Discord: “programming simplicity” https://discord.gg/65YZUh6Jpq
Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas
Twitter: @paul_tarvydas
Substack: paultarvydas.substack.com