To my knowledge, most of these are pretty accurate, but there are some errors that stand out to me: * BASIC string handling does not require garbage collection

To my knowledge, most of these are pretty accurate, but there are some errors that stand out to me: * BASIC string handling does not require garbage collection (in the sense used by all the other languages) because there's no aliasing. What many BASIC implementations referred to as garbage collection was to my knowledge simply heap compaction. * COBOL programmers do not normally use ALLOCATE and FREE, but instead map records directly with READ ... KEY and WRITE. * Common-Lisp as a specification doesn't require garbage collection. Lisp doesn't require garbage collection. See for example Baker's Linear Lisp. While most lisps are garbage-collected, Python (for example) differentiates different "dialects" of python so I would think it makes sense to do it here. * Java has many implementations, some of which allows garbage collection to be disabled. * Perl also supports a "last ditched effort" buffer which can be used to recover from out of memory errors ($^M) which is useful. * Smalltalk uses the term "automatic memory management" which I think can include reference counting, but Smalltalk doesn't (easily) support reference counting. It should say garbage collection. Garbage Collection may be Automatic Memory Management, but Automatic Memory Management isn't (necessarily) Garbage Collection. Another issue I have is that C uses its space for editorialising, and this seems wrong. Those errors are possible any time the programmer manages memory directly, and are easy to avoid with a number of simple techniques. It is in fact the "standard memory management" (malloc/free) and single-heap core that is horrible and (in my opinion) most contributory to those bugs. More opinion: the worst part about C is the self-hating and reluctant C programmers (followed shortly by the ones that don't program in C anymore).