Un bon GC est meilleure qu'un mauvais programmeur : ho la bonne surprise. Je vais te la faire à l'envers : un mauvais GC est pire qu'un bon programmeur ! Et on a bien fait avancer le bouzin.
Ce qui fait avancer le bouzin, c'est qu'il y a peu d'implémentations de GC par rapport au nombre de programmeurs, que les GC sont en général écrits par des gens pointus, et que vu le nombre d'utilisateurs et les ressources de développement qu'ils ont, ils sont souvent correctement débuggés et optimisés.
Bref, c'est l'avantage classique de mutualiser et déléguer le développement d'infrastructures critiques (gestion mémoire, routines d'E/S, ordonnancement de tâches, etc.) à des équipes hautement spécialisées dont le travail sera réutilisé par un grand nombre de gens. Quelle drôle d'idée !
Ensuite, rien n'empêche d'utiliser un allocateur spécifique pour ce cas là
Certes, rien n'empêche de tout réécrire à la main et de passer des jours à fignoler et débugger ce qui prendrait dix minutes dans un langage haut niveau. J'espère que tu appliques la même discipline en ce qui concerne ta libc, ta libm, tes primitives de synchronisation, ton noyau de système d'exploitation, etc.
(je ne parle pas du jour où il faudra que tes allocateurs spécifiques cohabitent harmonieusement avec des infrastructures tierces, par exemple un détecteur de fuites genre Valgrind—tiens, ça me rappelle une histoire avec OpenSSL)
Un programmeur correct sait faire ça assez vite
Mouarf. Soit les bibliothèques et applications C qui ont régulièrement des trous de sécu et des fuites mémoire sont écrites par des clampins (c'est quand même ballot, ça : ils auraient dû demander l'aide des gens comme toi), soit tu surestimes largement la protection contre les défauts qu'apportent des compétences en programmation bas niveau.
J'ai ma petite idée sur laquelle des deux explications est la bonne.
[^] # Re: Destructeurs
Posté par Antoine . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 10.
Ce qui fait avancer le bouzin, c'est qu'il y a peu d'implémentations de GC par rapport au nombre de programmeurs, que les GC sont en général écrits par des gens pointus, et que vu le nombre d'utilisateurs et les ressources de développement qu'ils ont, ils sont souvent correctement débuggés et optimisés.
Bref, c'est l'avantage classique de mutualiser et déléguer le développement d'infrastructures critiques (gestion mémoire, routines d'E/S, ordonnancement de tâches, etc.) à des équipes hautement spécialisées dont le travail sera réutilisé par un grand nombre de gens. Quelle drôle d'idée !
Certes, rien n'empêche de tout réécrire à la main et de passer des jours à fignoler et débugger ce qui prendrait dix minutes dans un langage haut niveau. J'espère que tu appliques la même discipline en ce qui concerne ta libc, ta libm, tes primitives de synchronisation, ton noyau de système d'exploitation, etc.
(je ne parle pas du jour où il faudra que tes allocateurs spécifiques cohabitent harmonieusement avec des infrastructures tierces, par exemple un détecteur de fuites genre Valgrind—tiens, ça me rappelle une histoire avec OpenSSL)
Mouarf. Soit les bibliothèques et applications C qui ont régulièrement des trous de sécu et des fuites mémoire sont écrites par des clampins (c'est quand même ballot, ça : ils auraient dû demander l'aide des gens comme toi), soit tu surestimes largement la protection contre les défauts qu'apportent des compétences en programmation bas niveau.
J'ai ma petite idée sur laquelle des deux explications est la bonne.