Je fais partie des chanceuses et des chanceux qui ont participé à OOPSLA 2007 qui se tenait à Montréal. J'ai été témoin d'un grand nombre de remarques, émises par des gens importans et brillants, allant dans le même sens que ce texte, dont la version originale fut écrite à l'été 2006. Ces remarques me permettront d'enrichir le tout quand j'aurai eu le temps de réorganiser mes idées. De même, voir cet écrit tiré du blogue Beautiful Code qui va un peu dans la même direction
Je discutais ce matin avec l'un de mes anciens étudiants, le brillant et sympathique Lamine Sy, de sujets divers, surtout liés avec l'un de ses principaux sujets d'intérêt qu'est la programmation orientée aspect, ou POA.
La discussion gravitait autour de la problématique d'intégrer de nouvelles idées dans l''industrie. Lamine m'indiquait qu'il pensait que l'élégance et la qualité d'un concept devraient être des arguments en sa faveur, et qu'un gestionnaire devrait être en mesure de comprendre cela . Lamine est détenteur d'une Maîtrise en génie logiciel, cheminement technologies de l'information de l'Université de Sherbrooke et a suivi plusieurs cours poussés portant sur des sujets connexes à la gestion des TI, ce qui explique en partie que nous ayons de tels échanges à l'occasion.
Je lui ai, de mon côté, fait part de quelques-unes de mes préoccupations. Ce qui suit est donc de moi.
Tu parles comme un développeur, cher ami. Le gestionnaire va devoir d'abord être convaincu qu'il y a un problème, ou du moins un gain financier à faire.
L'injection[1] de nouvelles idées est un combat dans l'industrie—tu sais qu'il a fallu une quinzaine d'années avant que la programmation orientée objet (POO) ne soit perçue comme viable sur le plan commercial!
On a d'autres problèmes à surmonter aussi. J'en parlais avec des collègues dernièrement: je constate une saturation conceptuelle dans l'industrie. Les gens en place ont de la difficulté à gérer les concepts connus et m'avouent, dans divers focus groups, préférer des choses simples et connues, même laides et lentes, à des choses élégantes et rapides, pour le simple fait que trop peu de leurs développeurs arrivent à comprendre les idées derrière le code plus moderne, plus efficace.
Attention : je ne dis vraiment pas que .NET est un échec. J'ai beaucoup de réserves au sujet de cette plateforme mais elle a plusieurs bons côtés (considérablement moins que ne le suggère la publicité, cela dit). Mon propos ici est que la philosophie que promulgue cette plateforme[2] tient d'un constat d'échec implicite face à la profession du design informatique.
Ce produit, éminemment commercial, nous dit des choses sur la vision qu'a la plus importante entreprise de développement logiciel sur la capacité des développeuses et des développeurs à réaliser un design logiciel qui tienne la route malgré le passage du temps.
Vu du côté de celles et ceux qui comprennent, ce constat peut sembler étrange, mais c'est bien là un problème réel. Le modèle .NET est en soi un constat d'échec, une vision pessimiste du développement.
Regarde bien la notation de ces langages: dans les langages C# ou VB.NET, l'appelant doit chaque fois spécifier son intention (pense aux qualificateurs out et ref apposés aux paramètres en C#, qui doivent être spécifiés à la déclaration des méthodes, soit, mais auxssi lors de leur invocaiton) car le langage ne permet pas de faire reposer la responsabilité d'une invocation conforme aux attentes de l'appelant sur le seul design des interfaces utilisées.
Les classes dérivées doivent expliciter leur intention de spécialiser une méthode virtuelle (override en C#). Le design des classes ancêtres n'est pas considéré suffisamment stable pour qu'on puisse s'y fier.
Le modèle .NET nous dit que l'industrie a, en partie, abandonné le combat du design. La présomption de base est pessimiste: les interfaces ne seront pas assez stables pour que nous puissions nous fier sur elles. Les programmeurs changeront leurs interfaces publiques malgré les indications données par des professeurs (qui font leur possible) à l'effet qu'il ne faut pas le faire. Les règles de passage de paramètres seront changées après livraison des classes. Il faut, selon cette philosophie, aider les programmeurs de code client à se prévaloir contre les inévitables (c'est l'idée maîtresse) erreurs de design. Le design original ne tiendra pas la route.
Les informaticien(ne)s sont-elles/ ils indiscipliné(e)s? Sont-ils/ elles sous trop de pression de produire et de livrer pour penser suffisamment à leur design? Sont-elles/ ils même capables de livrer un design stable? Je parle ici des informaticien(ne)s sur le plan statistique; il y a beaucoup de gens capables de faire ce travail, mais ces spécialistes sont-ils en nombre suffisant pour que le modèle préconisé par les penseurs, selon lequel le design livré doit être stable et selon lequel livrer signifie s'engager à entretenir les interfaces publiques, soit un modèle commercialement viable?
La firme Microsoft a pris position et sa vision des choses est, clairement, que non, ce modèle n'est pas viable. Le code pris en charge de .NET, tout comme Java d'ailleurs, a rejeté le concept d'objets constants (voir cette série d'entrevues avec Anders Hejlsberg) parce que ses concepteurs sont d'avis que les programmeurs, faute d'être capables de penser un design solide a priori, passeront leur temps à recourir à des conversions explicites de types pour se débarrasser de la contrainte de constance. L'idée de pouvoir annoncer les exceptions susceptibles d'être levées par une méthode a aussi été rejetée sur la base de difficultés envisagées dans l'évolutivité du code.
Le modèle est pessimiste : on y prend pour acquis que les design seront mauvais, ou à tout le moins déficients, et que ce trait est suffisant pour introduire une gamme d'outils qui cherchent philosophiquement à lui pallier. On fait le choix de laisser le code client valider ses présomptions lui-même en explicitant sa perception des paramètres et des méthodes dont il se sert :
La verbosité des langages .NET est un choix volontaire, une vision. Et ils ont peut-être raison : le pessimisme est, historiquement, une position pragmatique.
Mais pour les éducateurs, placés devant ce constat, doivent réfléchir. Si notre enseignement ne peut plus être appliqué dans l'industrie, alors quoi faire? Si les efforts mis sur une démarche solide de design ne sont plus applicables dans la pratique parce que l'industrie présume que les design seront floués; si les techniques et concepts enseignés ne sont plus examinés à la lueur de leurs qualités (élégance, efficacité, robustesse, etc.) mais bien à la lueur de leur conformité avec ce que les gens en place connaissent déjà (tout un obstacle à l'innovation, convenons-en), alors les éducateurs investissent-ils leurs énergies au bons endroit?
N'ayant pas renoncé à la recherche et préférant la qualité à la conformité au pire, j'espère qu'il y a de l'espoir dans l'enseignement de l'informatique dans les institutions d'enseignement supérieurs (collèges et universités). Il nous faut donc, tous et chacun, réfléchir à des manières de redonner confiance aux gens de l'industrie en la capacité des étudiant(e)s diplômé(e)s à livrer un design susceptible de bien évoluer avec le temps tout en maintenant des interfaces stables et efficaces. Il nous faut aussi trouver le moyen de faciliter le transfert des connaissances même (surtout!) hors de l'école, pour que les étudiant(e)s diplômé(e)s soient en mesure à la fois de mettre en valeur leurs acquis, de jouer leur rôle de facteur d'innovation, de progrès et de réflexion sur les pratiques existantes, et pour que leur savoir soit transférable à leurs collègues diplômé(e)s depuis un peu plus longtemps. L'industrie envoie un message clair en ce sens: si innover signifie écrire des programmes que personne autour de soi ne comprendra par la suite, alors mieux vaut (commercialement parlant) ne pas innover.
La clarté de la démarche intellectuelle, le recours à une notation universelle (probablement une saveur d'UML), l'autodocumentation des programmes et la capacité à communiquer sont des atouts plus importants que jamais. La science a trop évolué, le savoir et le savoir-faire changement trop rapidement pour qu'une pédagogie continue ne soit pas mise en place. Chaque étudiant(e) diplômé(e) a maintenant la mission de trouver les mots pour expliquer ce qu'il ou elle fait.
Une partie de la solution, donc, est de mettre l'accent sur la capacité d'expression de nos étudiant(e)s et de nous assurer que la plupart d'entre eux puissent expliquer ce qu'ils savent faire et ce qu'ils font de manière à aider leurs collègues à comprendre le tout et à pouvoir prendre la relève en temps et lieu.
D'un autre côté, il nous faut essayer de comprendre pourquoi certains font de l'idée même de design un constat d'échec. Il nous faut réfléchir à nos propres méthodes d'enseignement et de design, et faire penser plus longuement et plus en profondeur les étudiant(e)s alors qu'elles et ils sont avec nous, dans les écoles. Réfléchir à la qualité de leur oeuvre et au processus global de développement dans lequel chacune et chacun s'engage.
Évidemment, le temps manque déjà pour faire ce que nous essayons de faire dans nos salles de classe. C'est tout un défi qui s'annonce...
[1] Le mot injection ici est un jeu de mot destiné à l'ami Lamine, du fait que ce mot prend un sens spécialisé en POA.
[2] Tout outil est porteur d'une philosophie, tout langage influence la pensée qu'il aide à articuler. Le choix d'un langage ou d'une plateforme est nécessairement porteur de conséquences. C'est un choix pragmatique et éthique, comme le sont maintenant nos choix de consommation. Soyons éveillé(e)s et alertes, nos actions ont un effet sur le monde.
