Je me rappelle d'un texte d'un codeurs linux qui lisait des papiers de recherche sur un problème précis d'OS qui était majoritairement monocpu, alors que cela n'existe presque plus, et pour des résultats non reproductibles.
Moi je vois aussi que les développeurs du kernel sont très lents à intégrer des idées venant du monde de la recherche, qu'il faut un peu tout leur apporter déjà cuit. Je ne vais pas parler de la recherche en OS que je connais mal, mais sur les tests, il y a eu plein de progrès sur le test aléatoire (concoling testing, etc.), les devs kernels n'ont jamais fait d'effort pour adopter ça dans le noyau (par exemple : en demandant à la Linux Foundation de financer une collaboration avec des universitaires du sujet pour financer une thèse d'application au noyau), et attend que des ingénieurs recodent leurs solutions from scratch (les fuzzers qui commencent timidement à être utilisés dans le noyau). C'est encore pire pour la vérification de programmes / l'analyse statique, où le kernel Linux n'a rien en place, alors que le kernel Windows utilise des annotations riches qui sont vérifiées statiquement depuis des années—pour ce genre de projets il faut que les développeurs soient prêt à spécifier les annotations qui précisent la possession de la mémoire, les informations de taille de pointeurs, etc., on ne peut pas vérifier le code sans en changer une seule ligne.
Je vois la recherche énorme autour du GADT que peu de personnes comprennent.
Bien expliqué et bien implémenté, les GADTs ne sont pas très compliqués, et ils simplifient quand même un certain nombre de choses difficiles à faire sans (Menhir, par exemple, repose sur des GADTs, mais est implémenté avec des Obj.magic en interne car il a été développé avant que ça n'arrive dans le langage; la plupart des bibliothèques avec des types fantômes sont dans cette situation). Il y a des bouts importants de l'écosystème OCaml qui devraient être soit moins sûrs soit moins efficaces sans les GADTs.
Ocaml [...] n'a toujours pas de moyen simple d'utiliser du multi-core ou les instructions SIMD.
En même temps (1) il y a peu de moyens "simples" d'utiliser le multi-core et (2) il y a de la recherche là-dessus depuis des années (dont maintenant de la recherche spécifiquement pour OCaml). C'est un peu pareil pour les instructions SIMD, si tu connais une façon simple de les ajouter au langage sans casser les garanties de sûreté du langage, raconte-nous.
Je n'ai pas vu non plus de recherche sur un langage pour la génération de code performant.
Pourtant il y en a plein, c'est peut-être juste que tu n'as pas regardé au bon endroit. LLVM me semble être un exemple, ou alors les travaux sur des DSLs qui se compilent bien vers des GPU par exemple. Si tu veux des références plus précises, peux-tu en dire plus sur ce que tu cherches ? (Quel genre de code ?)
J'ai vu de la recherche sur la compilation du code C (la lib de transformation de boucle utilisé dans gcc), mais pas sur un langage qui permet au compilateur de mieux faire son boulot (unboxing facile, allocation mémoire minime, gestion des instructions assembleurs spécifiques facilités,...).
Il y a pourtant eu pas mal de recherche sur des langages pour la programmation scientifique (X10, Fortress...) dont les aspects que tu mentionnes (à part l'assembleur je pense) étaient des aspects importants.
La recherche semble aussi focaliser sur la recherche du langage ultime. Mais comment fait-on la migration des centaines de millions de lignes de code existantes ? Comment assurer une transition progressive ?
Il y a des deux dans la communauté scientifique, des gens qui étudient la conception de meilleurs langages/outils (à utiliser dès le départ pour de futurs projets), et des gens qui cherchent à faciliter l'usage des langages existants malgré leurs défauts. Tu vas trouver le genre de choses que tu mentionnes chez les gens qui sont partisants de la seconde approche.
Par exemple, Michael Hicks et ses collaborateurs à l'université du Maryland ont travaillé depuis 2001 sur le problème de "Dynamic Software Update" pour le C (et les langages proches de C) et le Java, donc la question de comment migrer d'une version à l'autre d'une application pendant qu'elle tourne (avec des problématiques proches de ta question sur les migrations de schéma de bases de données, qui j'imagine a aussi été très étudiée mais je ne connais pas la recherche en bases de données).
(Maintenant il y aussi de la recherche sur la migration automatique de code en utilisant du machine learning, par exemple la recherche de Tien Nguyen à l'université du Texas.)
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 7.
Moi je vois aussi que les développeurs du kernel sont très lents à intégrer des idées venant du monde de la recherche, qu'il faut un peu tout leur apporter déjà cuit. Je ne vais pas parler de la recherche en OS que je connais mal, mais sur les tests, il y a eu plein de progrès sur le test aléatoire (concoling testing, etc.), les devs kernels n'ont jamais fait d'effort pour adopter ça dans le noyau (par exemple : en demandant à la Linux Foundation de financer une collaboration avec des universitaires du sujet pour financer une thèse d'application au noyau), et attend que des ingénieurs recodent leurs solutions from scratch (les fuzzers qui commencent timidement à être utilisés dans le noyau). C'est encore pire pour la vérification de programmes / l'analyse statique, où le kernel Linux n'a rien en place, alors que le kernel Windows utilise des annotations riches qui sont vérifiées statiquement depuis des années—pour ce genre de projets il faut que les développeurs soient prêt à spécifier les annotations qui précisent la possession de la mémoire, les informations de taille de pointeurs, etc., on ne peut pas vérifier le code sans en changer une seule ligne.
Bien expliqué et bien implémenté, les GADTs ne sont pas très compliqués, et ils simplifient quand même un certain nombre de choses difficiles à faire sans (Menhir, par exemple, repose sur des GADTs, mais est implémenté avec des Obj.magic en interne car il a été développé avant que ça n'arrive dans le langage; la plupart des bibliothèques avec des types fantômes sont dans cette situation). Il y a des bouts importants de l'écosystème OCaml qui devraient être soit moins sûrs soit moins efficaces sans les GADTs.
En même temps (1) il y a peu de moyens "simples" d'utiliser le multi-core et (2) il y a de la recherche là-dessus depuis des années (dont maintenant de la recherche spécifiquement pour OCaml). C'est un peu pareil pour les instructions SIMD, si tu connais une façon simple de les ajouter au langage sans casser les garanties de sûreté du langage, raconte-nous.
Pourtant il y en a plein, c'est peut-être juste que tu n'as pas regardé au bon endroit. LLVM me semble être un exemple, ou alors les travaux sur des DSLs qui se compilent bien vers des GPU par exemple. Si tu veux des références plus précises, peux-tu en dire plus sur ce que tu cherches ? (Quel genre de code ?)
Il y a pourtant eu pas mal de recherche sur des langages pour la programmation scientifique (X10, Fortress...) dont les aspects que tu mentionnes (à part l'assembleur je pense) étaient des aspects importants.
Il y a des deux dans la communauté scientifique, des gens qui étudient la conception de meilleurs langages/outils (à utiliser dès le départ pour de futurs projets), et des gens qui cherchent à faciliter l'usage des langages existants malgré leurs défauts. Tu vas trouver le genre de choses que tu mentionnes chez les gens qui sont partisants de la seconde approche.
Par exemple, Michael Hicks et ses collaborateurs à l'université du Maryland ont travaillé depuis 2001 sur le problème de "Dynamic Software Update" pour le C (et les langages proches de C) et le Java, donc la question de comment migrer d'une version à l'autre d'une application pendant qu'elle tourne (avec des problématiques proches de ta question sur les migrations de schéma de bases de données, qui j'imagine a aussi été très étudiée mais je ne connais pas la recherche en bases de données).
(Maintenant il y aussi de la recherche sur la migration automatique de code en utilisant du machine learning, par exemple la recherche de Tien Nguyen à l'université du Texas.)