Ce que tu appelles «défaut», ou plus bas «problème», c'est-à-dire la gestion manuelle de la mémoire,
Non, ce que j'appelle défaut, c'est un bug, une fuite mémoire, un crash, un trou de sécu, etc.
et tu as une manière très condescendante d'expliquer qu'on est tous des gros débiles à vouloir gérer manuellement la mémoire
Ma condescendance répond au complexe de supériorité des gens qui pensent que les défauts de gestion mémoire sont forcément dus à l'intervention d'un "mauvais programmeur"...
Postuler des turpitudes individuelles comme cause de tous les problèmes empêche de prendre conscience des effets de système. La difficulté de la gestion manuelle de la mémoire dans une application complexe, par exemple, est un effet de système inévitable (car les logiciels ne reviendront pas à la complexité des années 60, au contraire). L'historique complexe de l'évolution des projets sur de longues périodes est un autre effet de système (ce qui conduit par exemple à une discordance des conventions internes et d'éventuels malentendus sur icelles).
Évidemment, tout reporter sur les "mauvais programmeurs" est d'autant plus facile que la notion est mal définie et chacun peut décider selon ses propres critères qui est un "mauvais programmeur" (ce qui rappelle un célèbre sketch des Inconnus). Et la désignation d'un bouc-émissaire produit un effet de catharsis assez plaisant chez beaucoup d'êtres humains.
C'est ce que font plein de gens tous les jours dans tous un tas de domaines où un GC est hors de question.
La proportion d'applications où un GC est hors de question est appelée à diminuer. Comme le rappelle un intervenant, un téléphone "intelligent" aujourd'hui est suffisamment puissant pour faire tourner une JVM entière.
[^] # Re: Destructeurs
Posté par Antoine . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 8.
Non, ce que j'appelle défaut, c'est un bug, une fuite mémoire, un crash, un trou de sécu, etc.
Ma condescendance répond au complexe de supériorité des gens qui pensent que les défauts de gestion mémoire sont forcément dus à l'intervention d'un "mauvais programmeur"...
Postuler des turpitudes individuelles comme cause de tous les problèmes empêche de prendre conscience des effets de système. La difficulté de la gestion manuelle de la mémoire dans une application complexe, par exemple, est un effet de système inévitable (car les logiciels ne reviendront pas à la complexité des années 60, au contraire). L'historique complexe de l'évolution des projets sur de longues périodes est un autre effet de système (ce qui conduit par exemple à une discordance des conventions internes et d'éventuels malentendus sur icelles).
Évidemment, tout reporter sur les "mauvais programmeurs" est d'autant plus facile que la notion est mal définie et chacun peut décider selon ses propres critères qui est un "mauvais programmeur" (ce qui rappelle un célèbre sketch des Inconnus). Et la désignation d'un bouc-émissaire produit un effet de catharsis assez plaisant chez beaucoup d'êtres humains.
La proportion d'applications où un GC est hors de question est appelée à diminuer. Comme le rappelle un intervenant, un téléphone "intelligent" aujourd'hui est suffisamment puissant pour faire tourner une JVM entière.