|
Dans les années 1980, l’informaticien danois
Bjarne Stroustrup (1950-) a conçu aux Bell Labs d’AT&T le langage de
programmation C++, évolution du langage C (1972) vers l’orienté objet. Devenu
dans les années 90 l’un des langages les plus utilisés, C++ sera l’ancêtre de
Java (1995).
La MIT Technology Review a publié un
entretien avec Stroustrup sur la qualité des programmes.
J’en condense ici en brassant le texte de l’entretien les éléments qui m’ont
paru les plus instructifs. Le lecteur curieux pourra se reporter à
l’original
qui contient sur C++ des considérations que je n’ai pas reprises.
* *
Donnons donc la parole à Stroustrup :
« Le meilleur programme écrit en C++ c’est
Google, dont j’admire la performance et qui possède de splendides
algorithmes parallèles et distribués. J’aime bien aussi les premiers navigateurs
Web et les systèmes embarqués, comme les systèmes d’analyse de l’environnement
et de pilotage autonome des Mars Rovers ou encore le contrôle des
injecteurs dans les gros moteurs marins. Tout ces programmes sont conçus pour
être fiables et répondre à de sévères contraintes de ressources. Il y a aussi du
bon code dans Photoshop, qui gère de façon magnifique l’interface
utilisateur et l’accès des algorithmes de traitement d’image aux pixels.
« Il existe donc d’excellents logiciels.
Cependant la qualité moyenne des programmes est à pleurer. Leur structure est
affreuse et il saute aux yeux que les programmeurs n’ont pas été attentifs à la
cohérence, aux algorithmes, aux structures de données ni à la maintenabilité.
Les utilisateurs ne peuvent pas s’en rendre compte parce qu’ils ne lisent pas le
code : ils voient seulement les programmes se planter.
« Comme les programmeurs travaillent sous la
pression de l’urgence, ils tentent d’accomplir des miracles en procédant par
essais et erreurs, en utilisant la force pure et en faisant beaucoup de tests.
Ils sont devenus experts dans l’art de construire, en intégrant des blocs non
fiables, un système qui marchera à peu près. Le système évolue ainsi jusqu’à
atteindre le niveau jugé acceptable mais il serait préférable de savoir pourquoi
il fonctionne, et comment.
« La performance pose souvent problème : les
programmeurs neutralisent les progrès du matériel en empilant dans leurs
programmes couche sur couche d’abstractions compliquées, ce qui ralentit la
réponse des interfaces ainsi que le démarrage et la fermeture des applications.
* *
« Il est dangereux de considérer la
programmation comme une tâche banale que pourraient remplir des programmeurs
formés en quelques mois. Nous n’admettrions pas cela pour des plombiers, des
comptables, des architectes, ni pour ceux qui conçoivent les ponts et les
trains. Aujourd’hui trop de programmeurs n’ont pas été assez formés et manquent
d’expérience.
« Évidemment il ne convient pas que les
outils soient plus compliqués qu’il n’est nécessaire. Mais plutôt que de
diminuer leur qualité pour satisfaire des gens qui peuvent à peine comprendre
les problèmes et moins encore leur trouver de solution, il faut qu’ils puissent
convenir au professionnel qualifié.
« On doit aussi construire des outils qui
faciliteront les tâches simples pour davantage de gens, mais il ne faut pas
laisser n’importe qui porter la main sur les infrastructures de notre
civilisation technique, ni forcer les professionnels à utiliser des outils
conçus pour les amateurs.
* *
« En théorie, la solution réside dans la
formation des programmeurs et l’utilisation de méthodes qui organiseraient la
conception des produits en vue de leur utilisation à long terme et de leur
maintenabilité. On devrait récompenser les réalisations solides et punir les
négligences.
« Mais en fait on récompense les
programmeurs qui produisent à la va-vite des programmes bogués et peu coûteux.
Les utilisateurs veulent disposer de leurs gadgets sans devoir ni attendre, ni
apprendre de nouvelles façons d’interagir avec leur ordinateur, ni payer pour la
qualité. Si les utilisateurs ne changent pas de comportement, les fournisseurs ne
modifieront pas le leur. En pratique, la solution théorique est donc
inapplicable.
On ne peut d’ailleurs pas arrêter un système d’information en attendant d’avoir
tout reprogrammé.
« Continuer de la sorte est coûteux,
dangereux et déprimant. Il faudrait un changement significatif et global, mais
il ne pourra venir que de façon progressive.
* *
« Trop de gens croient avoir trouvé la
panacée dans une solution partielle : améliorer l’ingénierie des exigences,
l’architecture, le langage de programmation, les tests, le système
d’exploitation, le middleware, la structure des données, les algorithmes etc.
Tout cela peut aider, mais si l’on croit qu’une de ces approches constitue la
solution à l’exclusion des autres on va à l’échec.
« Je parie que le prochain grand progrès
conceptuel concernera la gestion de la concurrence[2]. Alors
que nos ordinateurs auront bientôt 32 processeurs, nous autres programmeurs
n’avons pas encore assez réfléchi aux choses qui se passent simultanément.
« Je ne pense pas toutefois qu’un nouveau
paradigme vienne remplacer d’un coup les paradigmes antérieurs : il s’y
ajoutera. Ce qui viendra après la programmation orientée objet inclura l’orienté
objet comme un sous-ensemble.
* *
« Les sauts qualitatifs peuvent être très
coûteux : je préfèrerais que le budget de la R&D fût consacré à des changements
progressifs.
« Il faudrait aider l’évolution des langages et
des bibliothèques avec des outils qui faciliteraient la mise à niveau des
systèmes réels et permettraient aux anciennes applications de survivre dans
l’environnement conçu pour le nouveau système.
« Qualifier avec arrogance les anciens
programmes de legacy et recommander la stratégie qui consiste à tout
réécrire, c’est inepte. J’accepterais des changements radicaux dans le code
source si le changement était universellement supporté par un outil solide qui
permette de traduire de l’ancien style vers le nouveau. En l’absence de tels
outils, les développeurs de langages doivent être prudents envers les nouvelles
possibilités, les développeurs d’application doivent être prudents envers les
nouveaux outils offerts par les nouveaux langages.
« L’informatique et la programmation n’ont
pas encore émergé comme fondations théoriquement et empiriquement solides pour
développer des programmes répondant à de vrais problèmes. Théorie et pratique se
rencontrent rarement : les chercheurs sont attirés par les problèmes théoriques
plus que par les problèmes du monde réel, et beaucoup de programmeurs ignorent
complètement les résultats de la recherche. »
Jason Pontin, « The Problem with Programming », MIT Technology Review,
28 novembre et 7 décembre 2006,
http://www.technologyreview.com/InfoTech/17831/ et
http://www.technologyreview.com/InfoTech/17868/
[2]
En informatique on nomme "concurrence" la situation où deux
utilisateurs (ou deux processus informatiques) peuvent simultanément
modifier les mêmes données. Le risque est alors que l'action de l'un efface
l'action de l'autre (pensez par exemple au cas d'un document Word : la
solution peut consister à enregistrer séparément chaque paragraphe et à
émettre une alarme si deux utilisateurs veulent modifier le même
paragraphe). La concurrence pose des problèmes difficiles aux applications
transactionnelles. |
