Je pense qu'on peut regretter le fait historique que Linux, en tant que projet communautaire de noyau libre, est parti sur un noyau monolithique plutôt qu'un micro-noyau—aujourd'hui le noyau est presque impossible à sécuriser (je parle de sortir du jeu du chat et de la souris des attaques/réponses en rendant toute les classes d'attaques courantes impossibles grâce à la conception du système), et les gens qui veulent un système sûr (Qubes OS par exemple) doivent repartir au niveau des hyperviseurs.
Mais il y a une différence importante, c'est que (1) à l'époque les micronoyaux étaient difficiles à rendre efficace (L4 a fait beaucoup de progrès depuis), et (2) tu parles d'un choix de design fondamental qui demande de complètement tout refaire.
J'ai dit que ne pas inclure les types sommes dans un langage de programmation typé conçu dans les années 2000, c'est une faute. Il ne s'agit pas de demander de tout changer au langage, ou de le transformer en une variante de Coq. C'est une fonctionnalité qui n'est pas copmliquée à expliquer ou implémenter, qui se mélange bien avec la plupart des autres traits du langage, et qui lui donne une meilleure capacité à modéliser les domaines métiers—et donc d'écrire du code plus clair. On n'est pas du tout au niveau du "il faut tout refaire avec un micro-noyau".
Tu parles de récrire des millions de lignes de code, mais au moment où Go a été conçu, il n'y avait aucune ligne déjà écrite dans ce langage (ou alors juste des exemples exploratoires).
Je crois que tu es passé à côté d'un aspect de mon article. Quand je dis qu'il faut faire le travail de formaliser les langages de programmation, je parle de formaliser tous les langages, y compris le C, le Go, le Basic, l'assembleur, le Java etc. Formaliser un langage révèle des irrégularités ou des manques à corriger (c'est pour cela qu'il faut essayer de le faire pendant la conception du langage, et pas seulement apres-coup quand on est mis devant le fait accompli), mais ne demande en aucun cas de le modifier de fond en comble, de lui ajouter des types dépendants et de le transformer en l'hybride monstrueux de Rust, Haskell, Coq et Mathematica !
En général la théorie cherche la solution la plus élégante. Sur le papier, la théorie peut toujours l'emporter sur l'approche pratique. Mais voilà, la pratique c'est aussi les contraintes de la vie : la formation, les outils, les projets existants, l'Histoire.
La formation, les outils, l'histoire, tout cela évolue avec le temps et on travaille tous dessus. C'est un ensemble de choix fait par des gens, et l'un des choix qui se propose c'est de réfléchir à l'apport de la théorie, d'écouter ce qu'elle a à dire et d'entrer en contact avec des gens qui en font. Ça n'est pas la seule chose importante pour obtenir un langage qui réussit, mais je ne pense pas m'aveugler en pensant (à partir d'exemples concrets nombreux) que quand on suit cette démarche, les résultats ne peuvent être que positifs.
C'est pour ça que c'est important pour moi d'expliquer le domaine, les choix faits par certaines communautés, et pourquoi/comment on a confiance en les résultats obtenus. Le but c'est que les gens comprennent l'intérêt de la recherche dans ce domaine au lieu d'avoir une vision un peu simpliste, ou tout simplement de l'ignorer complètement comme l'ont fait, par exemple (mais ils sont loin d'être les seuls), les créateurs de Go.
[^] # Re: go 2.0
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 9.
Je pense qu'on peut regretter le fait historique que Linux, en tant que projet communautaire de noyau libre, est parti sur un noyau monolithique plutôt qu'un micro-noyau—aujourd'hui le noyau est presque impossible à sécuriser (je parle de sortir du jeu du chat et de la souris des attaques/réponses en rendant toute les classes d'attaques courantes impossibles grâce à la conception du système), et les gens qui veulent un système sûr (Qubes OS par exemple) doivent repartir au niveau des hyperviseurs.
Mais il y a une différence importante, c'est que (1) à l'époque les micronoyaux étaient difficiles à rendre efficace (L4 a fait beaucoup de progrès depuis), et (2) tu parles d'un choix de design fondamental qui demande de complètement tout refaire.
J'ai dit que ne pas inclure les types sommes dans un langage de programmation typé conçu dans les années 2000, c'est une faute. Il ne s'agit pas de demander de tout changer au langage, ou de le transformer en une variante de Coq. C'est une fonctionnalité qui n'est pas copmliquée à expliquer ou implémenter, qui se mélange bien avec la plupart des autres traits du langage, et qui lui donne une meilleure capacité à modéliser les domaines métiers—et donc d'écrire du code plus clair. On n'est pas du tout au niveau du "il faut tout refaire avec un micro-noyau".
Tu parles de récrire des millions de lignes de code, mais au moment où Go a été conçu, il n'y avait aucune ligne déjà écrite dans ce langage (ou alors juste des exemples exploratoires).
Je crois que tu es passé à côté d'un aspect de mon article. Quand je dis qu'il faut faire le travail de formaliser les langages de programmation, je parle de formaliser tous les langages, y compris le C, le Go, le Basic, l'assembleur, le Java etc. Formaliser un langage révèle des irrégularités ou des manques à corriger (c'est pour cela qu'il faut essayer de le faire pendant la conception du langage, et pas seulement apres-coup quand on est mis devant le fait accompli), mais ne demande en aucun cas de le modifier de fond en comble, de lui ajouter des types dépendants et de le transformer en l'hybride monstrueux de Rust, Haskell, Coq et Mathematica !
La formation, les outils, l'histoire, tout cela évolue avec le temps et on travaille tous dessus. C'est un ensemble de choix fait par des gens, et l'un des choix qui se propose c'est de réfléchir à l'apport de la théorie, d'écouter ce qu'elle a à dire et d'entrer en contact avec des gens qui en font. Ça n'est pas la seule chose importante pour obtenir un langage qui réussit, mais je ne pense pas m'aveugler en pensant (à partir d'exemples concrets nombreux) que quand on suit cette démarche, les résultats ne peuvent être que positifs.
C'est pour ça que c'est important pour moi d'expliquer le domaine, les choix faits par certaines communautés, et pourquoi/comment on a confiance en les résultats obtenus. Le but c'est que les gens comprennent l'intérêt de la recherche dans ce domaine au lieu d'avoir une vision un peu simpliste, ou tout simplement de l'ignorer complètement comme l'ont fait, par exemple (mais ils sont loin d'être les seuls), les créateurs de Go.