FP is very constrained. FP is, itself, an imperative language (“do this, then do that” vs something like Prolog’s “this is what I want in the end, make it so”).
CPUs are just soft hardware.
The original intent of CPU design was to replace parts of massively parallel electronic circuits with sequencerICs+memoryChips that could be programmed in a synchronous/sequential manner. Somewhere along the way, it was forgotten that CPUs were only part of the solution and should not be considered to be the whole solution. Even when a whole massively parallel circuit could be replaced by many CPUs, each CPU would do its own thing in its own paradigm Such circuits go from being massively parallel to being only mildly parallel.
CPUs perform control flow and CPUs mutate RAM. Any PL that ignores those facts cannot describe how CPUs work. Such PLs might, though, lead to useful paradigms for thinking about how to program (only) certain aspects of CPU behaviour.
Paradigms for thinking about aspects of programming CPUs are good, but, one must realize that multiple paradigms are necessary to cover all of the bases.
Force-fitting other ideas into paradigms, stretching the paradigms out of their sweet spot, results in bloat and complication. Today, we have increasing complication and increasing bloat and increasing cognitive dissonance, eg. edicts like “mutation is bad”, even though mutation is the fundamental basis of operation for CPUs.
Programmers who think in terms of PUSM (Programming Using the SICP Method) do think in terms of FP, but, programmers who want to program beyond PUSM allow themselves to think outside of the PUSM box.
How To Think Outside Of The FP Box?
Learn about
other programming paradigms and PLs, like
Forth
Smalltalk
Self
multi-tasking (Holt’s book, esp. chapter on implementation of a nucleus)
How CPUs work
Don’t look at current CPUs - they’re too complex due to 5 decades of incremental improvement and tweaking
Look at how simpler CPUs work, like MC6800, 6502, PDP11, etc.
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: https://discord.gg/65YZUh6Jpq
Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas
Gumroad: tarvydas.gumroad.com
Twitter: @paul_tarvydas
Substack: paultarvydas.substack.com
This got me thinking... when it comes to learning other paradigms, what has made things click for you? (or not)
For me:
- Reading a language's Wikipedia page, seeing how it implements a "hello world" program => Does not work for me
- Doing little iterative coding exercises in Codecademy or something => Does not work for me
- Building class projects in some language => Does not work for me (maybe I didn't have the scaffolding to understand a new paradigm when I was in school)
- Building an actual project that I care about => Sort of works for me? (I'm currently working in Vue, and I became fairly proficient in component-based programming by just... getting used to it? (I'm reminded of the JVN quote - https://www.azquotes.com/picture-quotes/quote-young-man-in-mathematics-you-don-t-understand-things-you-just-get-used-to-them-john-von-neumann-35-54-07.jpg). And I didn't really understand the paradigm or how it differed from other ways of building websites)
- Getting used to something, getting really stuck, then deep-diving on the paradigm => Works for me (but the upfront investment is massive)
- Reading a book that illustrates a way of thinking => Works for me (I went through 1/2 of SICP and I took away some very low-level ideas. `car` and `cdr` were new to me, and it was interesting how far you could go with those primitives when it came to list manipulation. I think the best book I've read is Grokking Simplicity, which, if you haven't read it, I could write a whole other paragraph about why I think it's a great teaching book and how it avoids the common pitfalls)