Physique, logiciel, loi : moins de règles, c'est mieux
Dura bug, sed bug
Je suis, par mon métier, souvent, pour ne pas dire tout le temps, confronté au besoin de résoudre des bugs informatiques. Des défauts, quoi.
L'erreur que la plupart des informaticiens font pendant des années (ou toute leur vie) est de considérer le bug comme un cas particulier d'une machinerie qui est par ailleurs correcte. Tiens, il y a un bug quand on fait ça,
constate le programmeur. Ô joie, le branchement conditionnel est une capacité reptilienne de l'ordinateur. Il suffit donc d'éliminer le bug d'un si en pleine tête.
Au tout début du XXe siècle, Einstein planche sur le bug introduit dans la physique par les équations de Maxwell : la vitesse de la lumière serait une constante, indépendamment du repère où on la mesure. Or, la mécanique newtonienne, celle qui expliquait déjà les mouvements des planètes, la chute des corps et bien d'autres phénomènes, ne tolérait pas d'objet physique assez bizarre pour que, se déplaçant dans un TGV, sa vitesse vue du quai fût la même que celle vue depuis le wagon. Il y avait bien un bug dans la physique.
Einstein aurait été informaticien en début de carrière (ou informaticien médiocre en fin de carrière), voilà ce qu'il aurait dit : La vitesse est une grandeur additive, sauf si c'est la vitesse de la lumière. Le bug est résolu car les observations collent désormais à l'énoncé et l'énoncé ne contient plus de contradictions.
Qu'a fait Einstein ? Il a considéré que l'ensemble de la mécanique newtonienne, un des fondements les plus importants de la physique, n'admettait pas le cas particulier de la vitesse de la lumière, mais était dans son ensemble un cas particulier, une anecdote d'une théorie plus générale. Comme dirait aujourd'hui un bon concepteur logiciel dans son dialecte abominable, Einstein a refactoré la physique. Réusiné, en français. Au lieu de se contenter de la retaper pour la faire tenir avec des bouts de ficelle.[1]
Il en va de même en informatique qu'en physique : bug et fonctionnement correct ne sont ni l'un ni l'autre l'exception de l'autre. Ils doivent toujours être considérés dans leur ensemble comme le fonctionnement constaté du logiciel. Chacun des deux — fonctionnement voulu et fonctionnement nuisible — est un cas particulier d'une généralité. On ne traite donc pas un bug en empilant un cas particulier supplémentaire — un si — mais en révisant la conception générale afin qu'elle n'engendre plus que le fonctionnement voulu. Plutôt que de tuer le bug, on révise son univers afin qu'il ne puisse pas naître (et je ne parle pas du fait qu'il arrive ou non ; bien des bugs existent sans s'être jamais manifestés). Ça peut parfois être un travail très exigeant intellectuellement, qui nécessite une forte intuition abstraite, celle qui a horreur de l'exception et du cas particulier. Celle qui a horreur du si. C'est là tout ce que j'aime en informatique, la construction, la conception, quand arrive le stade où tout le comportement du système que l'on conçoit émerge d'un assemblage subtil de concepts simples, sans conditions, simplement des flux de données que l'on transforme. Et, réciproquement, quand d'un fonctionnement complexe on arrive à faire émerger une conception simple. Avec, toujours, dans un coin de mon cerveau, la physique en exemple, qui modélise à peu près tout ce qui nous entoure avec si peu de formules, si peu de briques qui semblent pouvoir décrire si peu de choses. Et pourtant.
D'ailleurs, il n'y a pas que les informaticiens qui aient du mal à adopter des visions d'ensemble généralistes et qui préfèrent coller des bouts de sparadrap les uns sur les autres pour résoudre les problèmes un à un au fur et à mesure qu'ils se présentent, plutôt que de réfléchir à des abstractions à la fois plus simples et plus commodes pour modéliser un système. Il n'y a pas que les informaticiens qui voient les choses à plat au lieu de se rendre compte que rond et rectangle, que solide et liquide sont tous des points de vue du même verre d'eau.
Il y a aussi les législateurs.
J'aurai peut-être l'occasion d'en parler une prochaine fois mais loi et logiciel ont énormément en commun.
Note
[1] Je sais, Einstein n'était pas seul dans cette recherche. Citons au moins Lorentz.
11 mars 2009
Commentaires
C'est bô.
11 mars 2009
encore (et toujours) très intéressant à lire.
et toujours aussi plaisant.
merci Atv' !
12 mars 2009
Einstein n'avait pas 1 million de clients mécontents qui bourrinaient son "customer service" d'emails d'injures, ni la concurrence prête à lui sauter à la jugulaire au moindre faux pas.
Einstein ne risquait pas non plus de dérégler la gravité terrestre (ou la vitesse de la lumière) en formulant une nouvelle théorie.
Einstein n'avait probablement pas un "responsable marketing & sales" sur le dos en permanence pour lui demander si sa théorie de la relativité serait prête dans 10 minutes ou plutot 15 parce que bon j'ai un dejeuner avec le client à 12h30 et il veut voir où on en est.
Einstein n'avait pas 150000 unit tests à écrire pour vérifier son code, ils étaient déjà sur place.
Bref, il se la coulait douce, ce salopard.
12 mars 2009
Ben tu parles. Fonctionnaire au bureau des brevets, il avait le temps d'élaborer des théories pour tuer le temps.
Ce qui est rigolo, c'est que dans un sens, il a effectivement tué le temps.
15 mars 2009
Très bien vue cette dernière note Atv'.
Malheureusement, wololo soulève un réel problème de notre époque: le temps et les contraintes matérielles au delà du concept.
Ses responsables ont tendance à laisser de moins en moins de temps et de latitude à l'informaticien en lui demandant justement de faire des conditions et des cas particuliers sans lui laisser la latitude de refondre correctement son code pour s'adapter à ces nouveaux besoins.
Et là encore je pense que l'on retrouve le même phénomène avec la mode actuel au niveau législatif qui veut que l'on ponde une loi très spécifique à chaque cas particulier pour "rassurer" l'opinion publique sans même chercher à comprendre si à terme celle-ci s'insèrera dans l'existant ...
30 mars 2009