Sur le thème du "ah oui mais utiliser des outils pas adaptés c'est pas bon, on le savait déjà", personellement je trouve qu'il y a quand même une différence de fond entre la généricité, qui me semble être une caractéristique inhérente à la programmation, et le fait de bien couvrir ou pas tel ou tel domaine applicatif par exemple. C'est une chose de dire "t'aurais pu le savoir que faire des logiciels de trading haute-fréquence en PHP c'est une mauvaise idée" : le domaine applicatif vient avec tout un tas de contraintes (volumes de données, temps de latence, etc.) dont on peut raisonnablement dire : "tel langage risque de coincer" ou, dans l'autre sens, "il y a une chance d'avoir ce domaine dans le logiciel que je veux construire et faire évoluer" (on peut se retrouver à avoir besoin de choses qu'on n'avait pas prévu au départ, mais on a quand même une vague idée d'ensemble).
À l'inverse, "avoir besoin d'une structure de donnée générique", c'est un besoin qui me semble pouvoir apparaître dans tous, mais alors vraiment tous les domaines applicatifs. Ce n'est même pas un besoin qui diminue quand on a une application de petite taille (contrairement au "j'ai besoin de refactorer mon code et je ne sais plus si ça marche" qui est critiqué pour certains langages dynamique), puisqu'il peut apparaître quand on choisit d'utiliser une bibliothèque tierce pour construire notre petit programme.
Bien sûr, une des raisons d'être de la recherche en systèmes de typage vient du fait que, quel que soit le système, il y a des formes de généricité plus avancées encore qu'on risque d'empêcher. (Si tu as les génériques, il faut se mettre à réfléchir à la variance et on préfère éviter les wildcards; ou alors au polymorphisme de sorte supérieure, etc.) Donc tous les langages typés sont, dans une certaine mesure, confrontés à ce problème. Mais je pense que "structure de données génériques" est quand même un besoin de généricité qui va apparaître particulièrement tôt et souvent.
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Sur le thème du "ah oui mais utiliser des outils pas adaptés c'est pas bon, on le savait déjà", personellement je trouve qu'il y a quand même une différence de fond entre la généricité, qui me semble être une caractéristique inhérente à la programmation, et le fait de bien couvrir ou pas tel ou tel domaine applicatif par exemple. C'est une chose de dire "t'aurais pu le savoir que faire des logiciels de trading haute-fréquence en PHP c'est une mauvaise idée" : le domaine applicatif vient avec tout un tas de contraintes (volumes de données, temps de latence, etc.) dont on peut raisonnablement dire : "tel langage risque de coincer" ou, dans l'autre sens, "il y a une chance d'avoir ce domaine dans le logiciel que je veux construire et faire évoluer" (on peut se retrouver à avoir besoin de choses qu'on n'avait pas prévu au départ, mais on a quand même une vague idée d'ensemble).
À l'inverse, "avoir besoin d'une structure de donnée générique", c'est un besoin qui me semble pouvoir apparaître dans tous, mais alors vraiment tous les domaines applicatifs. Ce n'est même pas un besoin qui diminue quand on a une application de petite taille (contrairement au "j'ai besoin de refactorer mon code et je ne sais plus si ça marche" qui est critiqué pour certains langages dynamique), puisqu'il peut apparaître quand on choisit d'utiliser une bibliothèque tierce pour construire notre petit programme.
Bien sûr, une des raisons d'être de la recherche en systèmes de typage vient du fait que, quel que soit le système, il y a des formes de généricité plus avancées encore qu'on risque d'empêcher. (Si tu as les génériques, il faut se mettre à réfléchir à la variance et on préfère éviter les wildcards; ou alors au polymorphisme de sorte supérieure, etc.) Donc tous les langages typés sont, dans une certaine mesure, confrontés à ce problème. Mais je pense que "structure de données génériques" est quand même un besoin de généricité qui va apparaître particulièrement tôt et souvent.