More remembering what's at the bottom of all this and wondering if we can make it simple again ... https://programmingsimplicity.substack.com/p/subroutines-are-not-functions-71a?r=1egdky

I like this one more then most of yours. One point, though: From a rhetorical perspective I feel like the picture you start out with compromises your argument.

At the hardware level, a program is just a sequence of opcodes.

That seems like pretty strong case for sequentialism! Might be worth rewording to something like, "when computers first came on the scene, their programs were just a sequence of opcodes." And then I'd quickly switch to a different picture that shows multiple sequences in parallel. And use that picture as the framework for the rest of the argument. Just some thoughts for the next iteration.

I generally agree. I think a lot was lost as the world crystallized on C and C-like languages because they gave the best performance at the time. I'm a big fan of statecharts, especially in combination with reactive programming, but it still hasn't really gone mainstream. I think tools like Statemate and the kind of work the Margaret Hamilton was doing for a while is more along the lines of what you might imagine a real "software engineering" approach might really look like. I think until someone steps up and makes something with these tools that the wider industry can point to - as opposed to NASA - and is made available and usable on par with the open source tools now, it might stay that way. I'm working on my own tools that are somewhat in this ballpark, but I don't think Statecharts alone are the actual answer.

yeah its funny we have techniques like trampolining to undo the damage of the function calling pattern, but its mechanism ends up brining in even more function call overheads for a thing that doesn't really suite the function calling paradigm in the first place.

One of the reasons I mentions Margaret Hamilton is because the way they built systems and thought about it in a distributed way with failure modes and priorities is so radically different than the lineage of programming that survived into the mainstream. Its not just about function calling patterns, its like - the whole imaginative background of what programming is - what a digital system is and how we can build them robustly is trapped in a specific lineage when there really are vastly more options.

Interesting! Thanks. Can you tell me if your background knowledge about what I'm after is colouring your understanding of this article, or, if there's something insufficient with how I say this? The rest of this reply turned out to be more than one sentence... Thinking About Timing Issues

Hmmm... I mean, I would venture to say that we probably agree about a lot of things. I wasn't really arguing. If it seemed like I misunderstood something you were saying, I would be happy to speak to it more directly. My responses were more of a "yes, and" in response to your article.

Do you have recommendations for writings about Margaret Hamilton's approach to system design? It sounds like a completely different paradigm than the one we are used to with function call stacks dominating execution.