Qui pourrait faire ça ? C'est ça qui me pose le plus de problème. Qui est assez doué pour comprendre le "langage de la recherche" et en même temps en faire un produit industriel.
Déjà, il y a des gens dont c'est le métier, c'est appelé la R&D, Recherche et Développement. Les ingénieurs R&D sont (en théorie) là pour faire le transfert entre la recherche et l'industrie.
Ensuite, il me semble qu'une autre réponse (en particulier dans le cadre du logiciel libre) c'est : "une équipe avec des compétences mixtes". Tu mets des chercheurs et des développeurs noyau ensemble, et tu les fais discuter, sur le long terme.
Un des rôles de la recherche est de transmettre le savoir, certes, mais on ne peut pas forcer les gens à écouter si ça ne les intéresse pas, s'ils ne sont pas prêt à faire un effort pour comprendre et participer. Si la volonté est là, c'est très facile d'obtenir d'un chercheur qu'il parle d'une façon compréhensible à des ingénieurs, il suffit d'envoyer un mail pour lui poser des questions, et de signaler quand on ne comprend pas quelque chose. (Ou alors d'aller à ses cours et ses exposés, et de poser des questions ensuite.)
Mais il faut que les gens se lançant dans une telle discussion soient conscients des rôles de chacun pour qu'elle soit productive. Si tu commences à discuter en espérant, au bout de quelques emails, pouvoir appliquer directement le résultat développé dans un cadre simplifié, purifié à ton gros projet de la vraie vie, tu vas sans doute être assez déçu. Il faut être prêt à entrer dans une boucle d'itération sur le moyen/long terme, avec des choses qui marchent partiellement au milieu.
Il y a des gens qui le font, par exemple qui testent Compcert sur tous les paquets OpenBSD et qui font des rapports d'erreur quand quelque chose coince (exemple). Ce travail peut mettre quelques années à aboutir, et le résultat (qu'on peut compiler OpenBSD avec un compilateur vérifié) n'est qu'une brique de base qui pourrait servir à d'autres choses ensuite.
Encore une fois, une bonne façon de faciliter encore ces échanges et de faire avancer les choses plus vite, c'est aussi de donner des sous (les chercheurs sont contraints en temps et en financement). Si la Linux Foundation avait sérieusement envie de faire avancer le sujet, elle pourrait facilement financer des thèses, dans des laboratoires de recherche, appliquées sur le noyau Linux. Les gens de Mozilla font ça, ils viennent à nos conférences (de recherche) et ils disent, clairement, "si vous avez des gens qui veulent travailler sur des sujets qui nous concernent, on peut les financer, les accueillir en stage chez nous pour leur faire découvrir nos problématiques, contactez nous". Et ça a un effet direct sur l'évolution de Rust par exemple.
[^] # Re: Le cerveau n'est pas logique
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Déjà, il y a des gens dont c'est le métier, c'est appelé la R&D, Recherche et Développement. Les ingénieurs R&D sont (en théorie) là pour faire le transfert entre la recherche et l'industrie.
Ensuite, il me semble qu'une autre réponse (en particulier dans le cadre du logiciel libre) c'est : "une équipe avec des compétences mixtes". Tu mets des chercheurs et des développeurs noyau ensemble, et tu les fais discuter, sur le long terme.
Un des rôles de la recherche est de transmettre le savoir, certes, mais on ne peut pas forcer les gens à écouter si ça ne les intéresse pas, s'ils ne sont pas prêt à faire un effort pour comprendre et participer. Si la volonté est là, c'est très facile d'obtenir d'un chercheur qu'il parle d'une façon compréhensible à des ingénieurs, il suffit d'envoyer un mail pour lui poser des questions, et de signaler quand on ne comprend pas quelque chose. (Ou alors d'aller à ses cours et ses exposés, et de poser des questions ensuite.)
Mais il faut que les gens se lançant dans une telle discussion soient conscients des rôles de chacun pour qu'elle soit productive. Si tu commences à discuter en espérant, au bout de quelques emails, pouvoir appliquer directement le résultat développé dans un cadre simplifié, purifié à ton gros projet de la vraie vie, tu vas sans doute être assez déçu. Il faut être prêt à entrer dans une boucle d'itération sur le moyen/long terme, avec des choses qui marchent partiellement au milieu.
Il y a des gens qui le font, par exemple qui testent Compcert sur tous les paquets OpenBSD et qui font des rapports d'erreur quand quelque chose coince (exemple). Ce travail peut mettre quelques années à aboutir, et le résultat (qu'on peut compiler OpenBSD avec un compilateur vérifié) n'est qu'une brique de base qui pourrait servir à d'autres choses ensuite.
Encore une fois, une bonne façon de faciliter encore ces échanges et de faire avancer les choses plus vite, c'est aussi de donner des sous (les chercheurs sont contraints en temps et en financement). Si la Linux Foundation avait sérieusement envie de faire avancer le sujet, elle pourrait facilement financer des thèses, dans des laboratoires de recherche, appliquées sur le noyau Linux. Les gens de Mozilla font ça, ils viennent à nos conférences (de recherche) et ils disent, clairement, "si vous avez des gens qui veulent travailler sur des sujets qui nous concernent, on peut les financer, les accueillir en stage chez nous pour leur faire découvrir nos problématiques, contactez nous". Et ça a un effet direct sur l'évolution de Rust par exemple.