The content of this article is overly simplified and misleading.
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.
To me it seems like the perceived problems with memory management happen because of how programs are organized which is influenced in large part by the programming language used. In OOP you have a bunch of interconnected little 'objects' with different lifetimes that needs to be perfectly coordinated with one another. This is very very hard to do which is why you have RAII in c++ as a bandaid and Rust for those that have deemed the patient to be terminally ill and best put out of its misery.
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 believe the audience for this article is those who use managed languages. From a modern perspective, this may have some value for those who have been involved in managed language development from the beginning.
Trivia note: the IBM PL/I (F) compiler, circa mid60s, used OS calls to allocate and free stack frames on entry/exit of each procedure. My guess is that they did this because they were trying to implement concurrency (TASKs), and threads were not yet understood. As a result, the Programmer's Guide has the following tip: “Do not use procedures; they are expensive.”
I would hazard a guess that later PL/I compilers did this better.
You should know about the stack and heap as general concepts, yes.
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.
Yes, this article simply introduces the basic concepts of abstract storage for beginners. It's a very high-level introduction, which I think is well done for developers of managed languages, such as JavaScript.
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.
reply