Memory Management Every Developer Should Know
webdeveloper.beehiiv.com
webdeveloper.beehiiv.com
Heap and stack exists and are widely used, but they are presented here as the only memory allocation strategies.
Static memory allocation is widely used in the embedded world.
And custom memory allocators are very often used in the gamedev world, quite often arenas, with allocations grouped by lifetime (like a frame or a level) and destroyed all at once. But there are many other approaches, more or less advanced and with different tradeoffs.
Memory management is not difficult but it is also not exactly entry-level, the problem we have is that many beginners are told that manual memory management is just outdated and unnecessary, while the cost of using "managed" solutions, quite often involving an annoying and intrusive garbage collector, and even worse, small allocations scattered all over the place for no reasons are very tangible.
Objects as an abstraction do seem useful and make sense but that is at the program level or at the very least the system level in a multi-system program. Definitely not at the data-struct + some related operations level which is what OOP languages consider them to be.
Alan Kay was right in that the big idea behind OOP is object communication but I think he got the object size wrong, message-passing doesn't seem that important when your object is a string with just a few functions attached. If instead your object is another program you are coordinating with or a different system such as your physics engine then message-passing does seem like a bigger deal.
I would hazard a guess that later PL/I compilers did this better.
If you unwind the stack (say in a debugger), you'll find that there's no "interruption" occurring.
More importantly, you need to understand generally how memory management works in your environment. It really, truly, does lead you into writing more efficient code.
But this article in particular isn't really worth the read, IMO.