I noticed Arawjo 2020 and was reminded to read through, thank you. His vision of coding-as-inscription reminds me a lot of Sengers's anti-boxology, and her notes on critical technical practice, which you seem to be working with here.

You might enjoy p.13 - 20 of Sengers 1998 (digitally numbered p.25 - 32), which pulls Winograd & Flores / Suchman / Chapman / Agre / Varela et al. into a delightful five-way synthesis. These are all researchers who have applied rigorous ontological discipline to subjective experiences. When you describe 'bending [computing machines] to fit paradigms of thought', that's what I think of

reports-archive.adm.cs.cmu.edu/anon/anon/usr/ftp/usr0/ftp/1998/CMU-CS-98-151.pdf

e.g. depending on your formulation of the action space,

In an unexpected move, after trying to understand AI in a Heideggerian sense Winograd chose to jettison AI altogether as impossible. [...] AI can solve problems that are formally specified and circumscribed, but will always fail to attain true intelligence because “[t]he essence of intelligence is to act appropriately when there is no simple pre-definition of the problem or the space of states in which to search for a solution” (98).

Today, we focus on only one engine - the FP-machine engine.

Is that true? Academic CS research is very much focused on FP, but my impression is that the software industry doesn't.

It is my impression that software industry programmers use the word "function" even when they mean "procedure", and, programmers tend to shy away from side-effects and state, and programmers tend to rely on the existence of preemptive operating systems (Windows, Linux, MacOS), etc. It is my impression that most popular CPUs today are enbaubled with scaffolding that supports the function-based meme (e.g. virtual memory, MMUs, caches, etc. (stuff that is needed to handle larger and larger data, but, not actually necessary for code itself)). It is my impression that programmers tend to think that "concurrency" and "asynchrony" are difficult concepts. These are all "tells" of too much emphasis on function-based thinking. It is, thus, my conclusion that the software industry is heavily influenced by the FP / function-based meme. (I blame "C").

And yet, most software I have personally looked at and worked with does not adopt FP as its dominant style. But scientific software is probably a special case.

Yes. I'm struggling to find words to express my observation. If I use the phrase "function-based", no one understands what I mean, if I switch to using "FP", everyone understands what they think I mean, but, miss my point). Before C, programming languages talked about "subroutines" (or, "procedures") and "functions", where "function" meant pure function in a mathematical-y sense. C conflated the two terms and just called everything a "function". This - psychologically - seemed to infer that CPUs were supposed to be used as function-machines. Early languages, like Prolog, Forth, etc. were invented before this mindset took over - the inventors allowed themselves to build little engines using opcodes. The engines supported various - very different - paradigms for thought. It is my belief that, today, programmers try to solve every problem using only one paradigm for thought (the function-based paradigm) and push themselves into unseemly corners in cases where the function-based paradigm is an unsuitable choice. Stuff like "concurrency", "asynchrony", "robotics" should be solved, IMO, in paradigms other than than the function-based one (and, without the attendant "operating system" that is needed by the function-based paradigm).

Smalltalk was infected with this cognitive dissonance and began misusing the phrase "message passing" when in fact it only implemented function-calling (blocking) with named parameters {correction: functions (aka "methods") named by inclusion of parameter keywords}. IMO, an "object" should be a whole CPU and a "message" is a blob of data sent along a wire from one CPU to another CPU. There is a deep difference between the idea of synchronous machines / objects and free-running, asynchronous, distributed machines. We couldn't afford to build this properly in the early days, but, we could afford to do this, properly, today (using cheapo CPUs, Arduinos, RPis, etc.) if we wanted.

IMO, if you're using Python, Javascript, Smalltalk, CLOS, C++, etc. then you are implicitly using the function-based paradigm.

If no one understands what you are trying to say, especially after years of trying to say it, you might consider that you are not communicating your point well. I would further suggest that the reason for this external communication failure is internal: you haven’t gotten your ideas in good order yet.

For example, how would moving from function to procedure make any difference for specifying async or concurrent tasks? What difference are you drawing between the two things? How is one not just a special case of the other? I have suspicions about what you mean here based on my understanding of these things, but you haven’t really clarified these distinctions within your communications.