Website, DB, & Software Developers

Object Oriented languages have gone a long way to solve lost memory issues. In the mid 80s, I wrote a rather efficient memory manager that would release all memory on normal termination. Essentially it set aside blocks of memory the size of an object and chained the blocks. Within the blocks it used linked lists (part of the object allocation) to track free space. If anything failed to release memory, the termination sequence would walk through all of the object lists and release all of the blocks - boom.

Most of that is handled by the OS now and you have to get tricky to get around the code/data space division to do anything like self-modifying code. It's sort of a no-no now, but it was a shitload of fun 20+ years ago.

As for TDD, the techniques predate the name by about two decades. Most of us were doing some form of it, just not calling it that. The paradigm breaks down on slow machines and tight deadlines, and a lot of the "library" usage was copy/paste from library text files for compile/link execution speed. That's why I said the drawbacks are fading with time. A 4.77 MHz x86 machine with 4K of memory just doesn't touch a six core i7 at 3.33 GHz and 24GB. Automated testing was mostly a matter of "hurry up and wait". Now the biggest problem is not thinking of a failure case when writing the test routine.