Give that back
In the dark ages of personal computing, those primitive new devices could do one thing at the time. Their microprocessors had few interrupts and their operating systems (often little more than a language interpreter) used them for the most basic of tasks, such as device management.
When multitasking finally arrived, it came about as a simple outgrowth of its single-tasking predecessors. Essentially, whenever an application felt like it, it said "I guess I can take a breather now" and gave up control of the CPU, thus freeing it for the next task in a queue. This approach was dubbed "cooperative multitasking", and its huge drawbacks were obvious since the beginning. Polite applications that gave up control often were at a great disadvantage over hoarders, as the latter could simply starve the former.
The baffling thing about cooperative multitasking is that it had staunch supporters, who claimed it to be superior over preentive multitasking, which at the time only existed in larger computers able to run Unix and other proper operating systems. Arguments along the lines of "time management is too important to be left to the OS" were made, as well as others that mentioned precise application timing and such. Of course, today, when preemptive multitasking is ubiquitous, no-one would make such arguments, and it would take quite a bit of gall to still insist that cooperative multitasking has anything worthwhile going for it.
And yet, even though the above matter has been settled, there is a completely analogous debate that still goes on, except that instead of time management, it is about memory management. Serious people claim, in all seriousness, that memory is too important to be left to the OS. And thus, millions of applications continue being built under this premise, each with a double burden: to do whatever it is they are meant to do, and to manage their memory.
It would seem obvious why manual memory management is a terrible idea, since pretty much all the drawbacks of cooperative multitasking apply, just as its advantages are equally illusory, but just to be clear, let's mention a few: greedy applications will hog all the memory, and have little incentive to release it other than their own survival; designing applications is harder due to the dual concern; and high-level application designers need to concern themselves with low-level details. Also, unsurprisingly, manual memory management does not get along well with preemptive multi-threading.
Thankfully, the tide has been turning slowly for a number of years. More and more people have realized that garbage collection (automatic memory management) is a necessity, rather than a luxury, and that its supposed drawbacks are trivial, much like those of its now-dominant time-management cousin. One rather aggressive 800 pound gorilla still stands in the way, but it seems inevitable that eventually it will be starved into irrelevance.
One can hope, at least.
When multitasking finally arrived, it came about as a simple outgrowth of its single-tasking predecessors. Essentially, whenever an application felt like it, it said "I guess I can take a breather now" and gave up control of the CPU, thus freeing it for the next task in a queue. This approach was dubbed "cooperative multitasking", and its huge drawbacks were obvious since the beginning. Polite applications that gave up control often were at a great disadvantage over hoarders, as the latter could simply starve the former.
The baffling thing about cooperative multitasking is that it had staunch supporters, who claimed it to be superior over preentive multitasking, which at the time only existed in larger computers able to run Unix and other proper operating systems. Arguments along the lines of "time management is too important to be left to the OS" were made, as well as others that mentioned precise application timing and such. Of course, today, when preemptive multitasking is ubiquitous, no-one would make such arguments, and it would take quite a bit of gall to still insist that cooperative multitasking has anything worthwhile going for it.
And yet, even though the above matter has been settled, there is a completely analogous debate that still goes on, except that instead of time management, it is about memory management. Serious people claim, in all seriousness, that memory is too important to be left to the OS. And thus, millions of applications continue being built under this premise, each with a double burden: to do whatever it is they are meant to do, and to manage their memory.
It would seem obvious why manual memory management is a terrible idea, since pretty much all the drawbacks of cooperative multitasking apply, just as its advantages are equally illusory, but just to be clear, let's mention a few: greedy applications will hog all the memory, and have little incentive to release it other than their own survival; designing applications is harder due to the dual concern; and high-level application designers need to concern themselves with low-level details. Also, unsurprisingly, manual memory management does not get along well with preemptive multi-threading.
Thankfully, the tide has been turning slowly for a number of years. More and more people have realized that garbage collection (automatic memory management) is a necessity, rather than a luxury, and that its supposed drawbacks are trivial, much like those of its now-dominant time-management cousin. One rather aggressive 800 pound gorilla still stands in the way, but it seems inevitable that eventually it will be starved into irrelevance.
One can hope, at least.
hopeful
worried
blank
contemplative