L'exemple microkernel vs monolytique n'est pas une bonne analogie. A ma connaissance, l'état de l'art sur les systèmes a micronoyaux n'a pas encore depassé celui des architectures monolithiques mis a part dans certains domaines très précis mais pas de manière générale.
Pourtant au niveau de la recherche sur le sujet, le noyau monolithique est obsolète par conception. Ce n'est pas moi qui le dit mais Tanambaum en 1992, qui est quand même un chercheur émérite du domaine. D'autant plus qu'il parlait au nom de son milieu, et non uniquement son point de vue personnel. Et il a répété jusqu'à sa retraite de la recherche que la conception de Linux, en n'étant pas un noyau monolithique, était toujours une erreur, que seuls les pure micro-noyaux avaient grâce à ses yeux.
Il a comparé Linux, en 1992 quand Torvalds était encore qu'un étudiant, qu'il ne lui donnerait même pas la moyenne pour ce projet à cause de ce choix architectural dépassé.
Bref, c'est en tout point semblable à ce que gasche déclare à propos de Go en tant que faute professionnelle en ignorant la recherche de son secteur d'activité sur le sujet.
Opposer théorie et pratique n'a pas de sens.
Bah, si.
Les deux doivent communiquer pour que le tout avance, mais on ne peut pas prétendre qu'une bonne idée théorique est systématiquement une bonne idée pratique. Nous en avons constamment la preuve, les noyaux (domaine que je connais mieux que les langages) en est une bonne démonstration car le modèle actuel dominant est plus sur les approches hybrides (monolithique modulaire pour Linux et *BSD ou noyau hybride comme ceux de macOS ou Windows) que pure micro-noyau qui sont réservés aujourd'hui à des niches.
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 théorie ne s'en préoccupe pas vraiment et c'est normal. Mais la pratique ne peut faire comme la théorie et tout refaire de zéro car la théorie dit que c'est mieux ainsi.
Certes ces nouveaux outils impliquent un cout non négligeable de formation, mais a choisir en entre cout de formation et cout en QA ou debugging, le choix sera vite fait. Payer des journées de dev pour coder ce qui pourrait se faire automatiquement avec des langages modernes ou a débugger des data race alors que le compilo pourrait en garantir l'absence a chaque build sera une position de plus en plus dur a justifier.
Mais tu ne peux dire demain de jeter des millions de lignes de code, de former des millions de développeurs d'un coup sur les nouvelles pratiques et espérer que ce soit économiquement intéressant. Les processus d'évolution que tu cites demandent du temps. Beaucoup de temps. Même certains langages comme COBOL, pourtant décriés, avec peu de personnes capables d'en tirer quelque chose était jusqu'à peu le pilier des applications bancaires. La transition vers Java fut très longue. Tu ne crois quand même pas qu'ils vont passer à Rust ou autre dès demain, si ?
Sinon dès demain tout le monde utiliserait Coq pour avoir un programme sans bogue. Mais ce n'est pas le cas, car le gain n'en mérite peut être pas le coût associé. Ce n'est pas pour rien que Coq est globalement employé par les secteurs où le niveau de criticité est telle que Coq revient finalement moins cher qu'un code C minimal testé de toute part. Car c'est là qu'il se met en valeur.
[^] # Re: go 2.0
Posté par Renault (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Pourtant au niveau de la recherche sur le sujet, le noyau monolithique est obsolète par conception. Ce n'est pas moi qui le dit mais Tanambaum en 1992, qui est quand même un chercheur émérite du domaine. D'autant plus qu'il parlait au nom de son milieu, et non uniquement son point de vue personnel. Et il a répété jusqu'à sa retraite de la recherche que la conception de Linux, en n'étant pas un noyau monolithique, était toujours une erreur, que seuls les pure micro-noyaux avaient grâce à ses yeux.
Il a comparé Linux, en 1992 quand Torvalds était encore qu'un étudiant, qu'il ne lui donnerait même pas la moyenne pour ce projet à cause de ce choix architectural dépassé.
Bref, c'est en tout point semblable à ce que gasche déclare à propos de Go en tant que faute professionnelle en ignorant la recherche de son secteur d'activité sur le sujet.
Bah, si.
Les deux doivent communiquer pour que le tout avance, mais on ne peut pas prétendre qu'une bonne idée théorique est systématiquement une bonne idée pratique. Nous en avons constamment la preuve, les noyaux (domaine que je connais mieux que les langages) en est une bonne démonstration car le modèle actuel dominant est plus sur les approches hybrides (monolithique modulaire pour Linux et *BSD ou noyau hybride comme ceux de macOS ou Windows) que pure micro-noyau qui sont réservés aujourd'hui à des niches.
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 théorie ne s'en préoccupe pas vraiment et c'est normal. Mais la pratique ne peut faire comme la théorie et tout refaire de zéro car la théorie dit que c'est mieux ainsi.
Mais tu ne peux dire demain de jeter des millions de lignes de code, de former des millions de développeurs d'un coup sur les nouvelles pratiques et espérer que ce soit économiquement intéressant. Les processus d'évolution que tu cites demandent du temps. Beaucoup de temps. Même certains langages comme COBOL, pourtant décriés, avec peu de personnes capables d'en tirer quelque chose était jusqu'à peu le pilier des applications bancaires. La transition vers Java fut très longue. Tu ne crois quand même pas qu'ils vont passer à Rust ou autre dès demain, si ?
Sinon dès demain tout le monde utiliserait Coq pour avoir un programme sans bogue. Mais ce n'est pas le cas, car le gain n'en mérite peut être pas le coût associé. Ce n'est pas pour rien que Coq est globalement employé par les secteurs où le niveau de criticité est telle que Coq revient finalement moins cher qu'un code C minimal testé de toute part. Car c'est là qu'il se met en valeur.