Tengo una opinión positiva acerca de la recolección de basura (garbage collection) como técnica para la gestión de memoria en los programas. Creo sinceramente que llega a ser imprescindible para hacer un buen diseño software en los lenguajes orientados a objetos.
Recuerdo una práctica en 5º de carrera, de la asignatura Tecnología de Objetos, hecha en C++ (lenguaje sin recolección de basura) en la que tenía que hacer un pequeño programa, ya no recuerdo exactamente sobre qué. Sí recuerdo sin embargo, la imposiblidad de llegar a un diseño “correcto” debido a la obligación de gestionar la memoria dinámica “manualmente”. El problema es muy simple: Cuando se pide la liberación de un objeto, ¿cómo sabes que ese objeto no está siendo referenciado desde otra parte/módulo? Derivado de esto es que habría que crear una dependencia gravísima entre los diferentes módulos que, en algún momento, compartiesen una referencia a un objeto. Tendrían que ponerse de acuerdo los programadores de ambos módulos en quién libera finalmente el objeto. Inadmisible.
Tratando de satisfacer mi ego personal, hoy he buscado por la red alguna documentación que corroborase mi desencanto con los lenguajes sin recolección de basura (Ojo, en C++ siempre estás a tiempo de create tu recolector, yo lo que quiero indicar es que de un modo u otro es prácticamente imprescindible).
Pues aquí va lo que he encontrado. Una reflexión de Paul Johnson. Destaco en negrilla lo que va en la misma línea de lo que he dicho.
Garbage collection (GC) is a facility in the run-time system associated with a language which will automatically reclaim objects which are no longer used. OO Languages which require garbage collection include Eiffel, Smalltalk and CLOS. C and C++ can have garbage collection retrofitted
Without GC programmers must explicitly deallocate dynamic storage when
it is no longer needed (in C this is done by a call to free(3)).
There are a number of problems with this:
1: Bugs due to errors in storage deallocation are very hard to find,
although products are available which can help.
2: In some circumstances the decision about whether to deallocate
storage cannot be made by the programmer. Drawing editors and
interpreters often suffer from this. The usual result is that the
programmer has to write an application-specific garbage collector.
3: An object which is responsible for deallocating storage must be
certain that no other object still needs that storage. Thus many
modules must co-operate closely. This leads to a tight binding
between supposedly independent modules.
4: Libraries with different deallocation strategies are often
incompatible, hindering reuse.
5: In order to avoid problems 3 and 4, programmers may end up copying
and comparing whole objects rather than just references. This is a
particular problem with temporary values produced by C++ overloaded
operators.
6: Because keeping track of storage is extra work, programmers often
resort to statically allocated arrays. This in turn leads to
arbitrary restrictions on input data which can cause failure when
the assumptions behind the chosen limits no longer apply. For
instance many C compilers limit expression nesting, identifier
length, include file nesting and macro stack depth. This causes
problems for programs that generate C.