Si te encuentras con alguna parte que te causa duda puedes dejarlo en la sección de comentarios y te ayudaremos lo mas rápido que podamos.
Solución:
Ada fue diseñado con aplicaciones militares en mente. Una de las grandes prioridades en su diseño fue el determinismo. es decir, uno quería que un programa de Ada funcionara exactamente de la misma manera cada vez, en cualquier entorno, en todos los sistemas operativos… ese tipo de cosas.
Un recolector de basura convierte una aplicación en dos, trabajando una contra la otra. Los programas de Java desarrollan contratiempos a intervalos aleatorios cuando el GC decide ir a trabajar, y si es demasiado lento, existe la posibilidad de que una aplicación se quede sin almacenamiento dinámico algunas veces y otras no.
Simplificado: un recolector de basura introduce cierta variabilidad en un programa que los diseñadores no querían. Haces un desastre, ¡lo limpias! Mismo código, mismo comportamiento cada vez.
No es que Ada se convirtiera en un gran éxito mundial, eso sí.
Porque Ada fue diseñado para su uso en sistemas de defensa que controlan armas en tiempo real, y la recolección de basura interfiere con el tiempo de su aplicación. Esto es peligroso, razón por la cual, durante muchos años, Java vino con una advertencia de que no debía usarse para sistemas de control militar y de atención médica.
Creo que la razón por la que ya no existe tal descargo de responsabilidad con Java es porque el hardware subyacente se ha vuelto mucho más rápido, así como el hecho de que Java tiene mejores algoritmos de GC y un mejor control sobre GC.
Recuerde que Ada se desarrolló en las décadas de 1970 y 1980 en una época en la que las computadoras eran mucho menos poderosas de lo que son hoy, y en las aplicaciones de control, los problemas de temporización eran primordiales.
En primer lugar, no hay nada en el lenguaje realmente que prohíbe recolección de basura.
En segundo lugar algunas implementaciones realizar la recolección de basura. En particular, todas las implementaciones que tienen como objetivo la recolección de elementos no utilizados de JVM.
En tercer lugar, hay una manera de obtener una cierta cantidad de recolección de basura con todos los compiladores. Verá, cuando un acceso escribe sale del alcance, si le dice específicamente al idioma que reserve una cierta cantidad de espacio para el almacenamiento de sus objetos, entonces ese espacio se destruirá en ese punto. He usado esto en el pasado para obtener un mínimo de recolección de basura. La declaración voodo que usas es:
type Foo is access Blah;
for Foo'storage_size use 100_000_000; --// 100K
Si hace esto, toda la memoria (100 KB) asignada a los objetos Blah a los que apuntan los punteros Foo se limpiará cuando el tipo Foo quede fuera del alcance. Dado que Ada le permite anidar subrutinas dentro de otras subrutinas, esto es particularmente poderoso.
Para obtener más información sobre lo que storage_size y los pools de almacenamiento pueden hacer por usted, consulte LRM 13.11
En cuarto lugar, los programas Ada bien escritos no tienden a confiar en la asignación de memoria dinámica tanto como lo hacen los programas C. C tenía una serie de agujeros de diseño que los practicantes aprendieron a usar punteros para pintar. Muchos de esos modismos no son necesarios en Ada.
Si conservas algún titubeo o capacidad de prosperar nuestro noticia puedes añadir una aclaración y con gusto lo observaremos.