Re: liberté

Les progrès ne seront possibles que si nous pouvons réfléchir sur les programmes sans les imaginer comme des morceaux de code exécutable.

Sans remettre tout cela en cause (je suis particulièrement d'accord avec l'analogie des téléscopes), il faut quand même se souvenir de deux choses si l'on veut rester parfaitement objectif :

- On n'est pas obligé d'être forcément d'accord avec Dijkstra. Le libre, c'est aussi cela. Edsger Dijkstra a apporté beaucoup à l'informatique, mais il abordait surtout la chose en mathématicien, et ce n'est pas forcément toujours la meilleure approche, à mon goût. Et puis, il y en a eu d'autres, notamment Donald Knuth, pour qui le goto n'était pas forcément une invention du diable.

- Dijkstra a probablement écrit cette phrase à une époque où l'on n'utilisait pratiquement que la programmation impérative, même si la plupart des grands concepts en programmation ont été développés dans les années 60 et 70. Peut-être que si l'on avait filé l'UML à Dijkstra, il en aurait été satisfait (je déteste l'UML). Aujourd'hui, le paysage a tellement évolué que cette assertion n'a plus du tout le même sens.

D'une manière générale, le formalisme tel qu'enseigné dans les universités conduit souvent à des choses du style : « pour fabriquer un avion, on part de l'existant - un autobus - on lui colle deux ailes et le motorise suffisamment jusqu'à ce qu'il vole ». Il faut bien se rendre compte que si l'on avait toujours programmé de cette manière, les logiciels n'auraient commencé à être utilisables qu'avec les machines des années 2000.

Il est de fait que la « programmation intégrée » est un art qui se perd. L'époque où une machine avait des numéros de registres suffisamment statiques pour que son programmeur les connaisse et les utilise directement sans passer par des symboles. Le temps où l'on balançait un ESC 9g pour déconnecter un Minitel, etc. sont définitivement révolus. Ce n'est pas forcément une bonne chose car je pense que si un astronome n'est pas un astronome si ses connaissances se limitent à l'utilisation de son instrument, une personne qui ne l'a jamais manipulé n'en est pas un non plus.

C'est de la même manière qu'un pilote de course ne peut pas atteindre le sommet sans connaître aussi bien sa machine que le circuit, qu'un pilote d'avion doit être capable de maîtriser la mécanique de son appareil, qu'un capitaine de navire le connaît jusque dans ses moindre recoins, et qu'un grand musicien a forcément une relation avec son instrument. Selon cette idée, le logiciel le plus efficace sera forcément celui qui a été conçu pour la machine sur laquelle il est destiné à fonctionner.

En outre, c'est une notion qui a disparu avec l'engouement pour la sacro-sainte portabilité. Qu'en est-il aujourd'hui ? 99% du parc micro-informatique est équipé de PCs, tous systèmes d'exploitation confondus. Dans ces conditions, même un programme écrit directement en assembleur pourrait fonctionner presque partout.

Pour le reste, la portabilité reste très relative. Les parcs logiciels PC et Solaris sur Spark, par exemple, restent encore très distincts et les logiciels portés le sont, la plupart du temps, qu'au dessus d'une couche d'abstraction. Généralement une JVM, ou bien le système d'exploitation lui-même.

Dans ce dernier cas, si l'on ne considère que Linux, par exemple, dont le répertoire "arch" se limite au nécessaire (ce qui en soi reste une bonne chose), et qui fonctionne de manière complètement uniforme sur toutes les plateformes, quel est l'intérêt de produire des machines différentes ?

J'aimerais donc que les jeunes vocations en programmation aient l'occasion de tripatouiller leur hardware eux-mêmes comme on le faisait il n'y a pas si longtemps, sans avoir obligatoirement besoin de 15 ans d'expérience en C et en système pour pouvoir envisager écrire le pilote d'un périphérique.

Dès lors, en associant formalisme purement abstrait (sur papier) ET, en même temps, programmation dédiée très proche de la machine, alors on obtiendra les meilleurs résultats, à mon avis.

Avant cela, tout cela ne restera qu'affaire de préférence personnelle, ce qui est respectable en soi, mais pas forcément un exemple absolu.

[ Répondre ]