I've stated that CPUs don't implement "functions". In this [article](On Options For Programming https://open.substack.com/pub/programmingsimplicity/p/on-options-for-programming?r=1egdky&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true), I say this again, hopefully in a better way.

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 http://reports-archive.adm.cs.cmu.edu/anon/anon/usr/ftp/usr0/ftp/1998/CMU-CS-98-151.pdf

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.

This - psychologically - seemed to infer that CPUs were supposed to be used as function-machines.

I doubt it. C goes back to a time when FP was considered impractical. I see the reasoning behind the term "function" in C (as in Lisp) as procedures being a generalization of the concept "function" in the context of code (as opposed to math).

Yes, FP was considered impractical in the days of C. (In fact, I studied Denotational Semantics due to my interest in compilers, and rolled my eyes). Yet, I think that there was a psychological effect just in the use of the word "function" instead of the then-used words like "procedure" and "subroutine". The word "function" gave free reign to thoughts like "mutation is bad", "state is bad", functions must return a value, no side-effects (what is a "server", then?), etc., etc. All of that led to bloat such as MMUs, caches, preemption, excessive amounts of memory, ignoring of coroutines, etc., etc. When I listen to Muratori's talk, I "hear" this. He actually flip-flops between using the words "subroutine" and "function" while decrying bloatware. Functions require stacks, everything-is-a-function-ideology requires "infinite" stacks which leads to virtual memory and excessive amounts of memory (we need more memory for fatter and better media, but, that does not directly imply that our code needs to become bloated, too). Functions create ad-hoc blocking which leads to heavy-weight operating systems needing to use preemption. Early games had the right idea, IMO, you slipped in a cartridge and the software took over the whole machine, without 55,000,000 LOC of operating system getting in the way.

The term "function" is actually pre-C. Fortran used it as well, in pretty much the same sense, with the possibility of mutable state as well.

I haven't used Fortran in ages, but I remember that a "function" was different from a "subroutine". Do you know what the difference is/was?

Starting in FORTRAN II in 1958, `FUNCTION`s returned a value and `SUBROUTINE`s did not. So if you wanted some result from a subroutine you would pass (usually) an array into the subroutine to be modified in place. However, you could also pass such a datum into a function to be modified, so the real difference is that a subroutine is a special case of a function that never returns anything. Algol and early Lisp made a similar distinction, which is unsurprising given that McCarthy worked on all of them.

The one big reason to use FUNCTION rather than SUBROUTINE is that you can use function calls inside compound expressions (e.g.

2.0 * SQRT(X)

), whereas subroutines must be called with a CALL statement, i.e. one line per call.