CPUs do not, in fact, see procedures. They execute machine instructions. Your "procedures", exactly, 'encapsulate complexity behind a language feature'. A rudimentary feature, true, but one identically the same as is found in modern languages, among their more powerful features.
I am, indeed, always cautious about calling things "carefully correct and generally useful". Still, I am aware of many language features and standard library components in modern languages that fully satisfy those criteria.
Who pastes code copied from stack overflow? I assume that was a ham-handed attempt at an insult. You are welcome to continue fooling with toy languages, old and new. Pretending they are adequate tools for serious work says more about you than about them.
Can you explain what you mean here? In the context of structured programming.
"CPUs do not, in fact, see procedures. They execute machine instructions. Your "procedures", exactly, 'encapsulate complexity behind a language feature'."
That's right, CPUs execute instructions. Those instructions are executed one after another, with jumps when a certain operation should be repeated or skipped. This is the definition of structured programming. Structured programming is a simple abstraction over how CPUs execute machine instructions.
I don't see any objects with methods there. Nor do I understand how would a CPU understand a lambda function or care if something is immutable or not.
"I assume that was a ham-handed attempt at an insult."
No insult there. It is just a sad reality how many developers rely on Stack overflow instead of using their own head a little.
Structured programming was defined by Edsger Dijkstra, and consisted originally of a model of programming with restrictions on where branches may go. Later programming language constructs if/then/else and while implemented this model. It does not address subroutines.
I describe C and similarly primitive languages as toys because they do not provide the expressive power needed to enable the levels of productivity and reliability demanded of serious work.
I would be very cautious when calling anything that encapsulates complexity "carefully correct" or "generally useful". Hiding such complexity behind language features is how we ended up with new generations of programmers who have no idea how to code anything themselves.
If generations and generations of stack overflow copy-pasters are the future of programming, then I don't want to be a part of it.
"In the 1970s, Hare might have competed with C and Pascal to express the then newly valued "structured programming". Today it is a toy."
Excuse me? The most useful, the most endured, the most sane and the most understood coding paradigm is a toy to you? You know, some of us really like to think of our programs as many procedures being called one after the other.
That's the most logical way to think about them, because it's the exact way the CPU sees them.