Le problème avec la programmation

Dans les années 80 et 90, Bjarne Stroustrup conçu et mis en œuvre le langage de programmation C++, qui a popularisé la programmation orientée objet et influencé de nombreux autres langages de programmation, dont Java.

Le C++ reste l'archétype du langage informatique de haut niveau (c'est-à-dire celui qui préserve les caractéristiques du langage naturel et humain), et il est toujours utilisé par des millions de programmeurs. De nombreux systèmes et applications de l'ère PC et Internet ont été écrits en C++. Pour autant, le langage reste controversé, en grande partie parce qu'il est notoirement difficile à apprendre et à utiliser, et aussi parce que la conception de Stroustrup permet aux développeurs de commettre de graves erreurs de programmation dans l'intérêt de préserver leur liberté.

Stroustrup, pendant de nombreuses années chercheur à AT&T Bell Labs, est maintenant professeur d'informatique au département d'ingénierie de la Texas A&M University, près de Houston.

Examen de la technologie : Pourquoi la plupart des logiciels sont-ils si mauvais ?

Bjarne Stroustrup : Certains logiciels sont en fait assez bons selon toutes les normes. Pensez aux Mars Rovers, à Google et au Human Genome Project. C'est un logiciel de qualité ! Il y a quinze ans, la plupart des gens, et surtout la plupart des experts, auraient dit que chacun de ces exemples était impossible. Notre civilisation technologique dépend du logiciel, donc si le logiciel avait été aussi mauvais que sa pire réputation, la plupart d'entre nous seraient déjà morts.

D'un autre côté, regarder des morceaux de code moyens peut me faire pleurer. La structure est épouvantable et les programmeurs n'ont clairement pas réfléchi à l'exactitude, aux algorithmes, aux structures de données ou à la maintenabilité. La plupart des gens ne lisent pas réellement le code ; ils voient juste Internet Explorer se figer.

Je pense que le vrai problème est que nous (c'est-à-dire nous les développeurs de logiciels) sommes dans un état d'urgence permanent, nous cramponnant à la paille pour faire notre travail. Nous réalisons de nombreux miracles mineurs par essais et erreurs, une utilisation excessive de la force brute et de nombreux tests, mais, si souvent, cela ne suffit pas.

Les développeurs de logiciels sont devenus adeptes de l'art difficile de construire des systèmes raisonnablement fiables à partir de pièces non fiables. Le hic, c'est que souvent nous ne savons pas exactement comment nous l'avons fait : un système a en quelque sorte évolué vers quelque chose de minimalement acceptable. Personnellement, je préfère savoir quand un système fonctionnera et pourquoi il fonctionnera.

ENFANTS : Comment pouvons-nous réparer le gâchis dans lequel nous sommes ?

BS : En théorie, la réponse est simple : mieux éduquer nos développeurs de logiciels, utiliser des méthodes de conception plus appropriées et concevoir pour la flexibilité et pour le long terme. Récompensez les systèmes corrects, solides et sûrs. Punir la négligence.

En réalité, c'est impossible. Les gens récompensent les développeurs qui fournissent des logiciels bon marché, bogués et prioritaires. C'est parce que les gens veulent maintenant de nouveaux gadgets sophistiqués. Ils ne pas veulent des inconvénients, ne veulent pas apprendre de nouvelles façons d'interagir avec leurs ordinateurs, ne veulent pas de retards de livraison et ne veulent pas payer un supplément pour la qualité (à moins que ce ne soit évident au départ – et souvent même pas alors). Et sans de réels changements dans le comportement des utilisateurs, il est peu probable que les fournisseurs de logiciels changent.

Nous ne pouvons pas simplement arrêter le monde pendant une décennie pendant que nous reprogrammons tout, de nos machines à café à nos systèmes financiers. D'un autre côté, le simple fait de s'embrouiller est coûteux, dangereux et déprimant. Des améliorations significatives sont nécessaires, et elles ne peuvent venir que progressivement. Ils doivent venir sur un large front ; aucun changement n'est suffisant.

L'un des problèmes est que les cheminées universitaires gênent : trop de gens poussent certains domaines comme panacée. De meilleures méthodes de conception peuvent aider, de meilleures techniques de spécification peuvent aider, de meilleurs langages de programmation peuvent aider, de meilleures technologies de test peuvent aider, de meilleurs systèmes d'exploitation peuvent aider, de meilleures infrastructures middleware peuvent aider, une meilleure compréhension des domaines d'application peut aider, une meilleure compréhension des données les structures et les algorithmes peuvent aider, et ainsi de suite. Par exemple, la théorie des types, le développement basé sur des modèles et les méthodes formelles peuvent sans aucun doute apporter une aide significative dans certains domaines, mais poussés comme la solution à l'exclusion des autres approches, chacune garantit l'échec dans les projets de grande envergure. Les gens poussent ce qu'ils savent et ce qu'ils ont vu fonctionner ; comment pourraient-ils faire autrement ? Mais peu ont la maturité technique pour équilibrer les demandes et les ressources.

ENFANTS : L'idée derrière C++ était que les programmeurs travailleraient plus dur en échange d'un code plus efficace. Bell Labs voulait un langage que quelques personnes vraiment intelligentes utiliseraient pour écrire du code qui s'exécuterait sur des ordinateurs comme les systèmes de commutation électronique (ESS) qui n'étaient pas très rapides. Aujourd'hui, il y a beaucoup de développeurs de logiciels et les ordinateurs sont très rapides. Cela vicie-t-il l'intérêt du C++ ?

BS : C++ n'a pas été conçu spécifiquement pour les grosses machines de commutation, mais pour une vaste gamme d'applications. Bell Labs était le foyer d'une gamme incroyable de projets intéressants couvrant toutes les échelles et utilisant essentiellement tous les types d'ordinateurs et de systèmes d'exploitation. Mais oui, le programmeur moyen des Bell Labs était nettement plus compétent que la notion de programmeur moyen de la plupart des gens, et la fiabilité et les performances (dans cet ordre) étaient considérées comme nettement plus importantes que dans la plupart des autres endroits.

Les performances sont toujours un problème dans de nombreuses applications qui m'intéressent : réactivité des interfaces, temps de démarrage et de fermeture des applications. Les développeurs de logiciels ont neutralisé les performances étonnantes du matériel informatique moderne en ajoutant couche sur couche d'abstractions [logicielles] trop élaborées. Nous semblons avoir atteint les limites de l'accélération linéaire pour le matériel, mais dans de nombreux cas, nous pourrions récupérer quelques ordres de grandeur du logiciel.

Cela dit, le C++ est en effet devenu trop convivial pour les experts à une époque où le degré d'éducation formelle efficace du développeur de logiciels moyen a diminué. Cependant, la solution n'est pas d'abréger les langages de programmation mais d'utiliser une variété de langages de programmation et de former plus d'experts. Il doit y avoir des langages à utiliser par ces experts – et C++ est l'un de ces langages.

ENFANTS : Rétrospectivement, lors de la conception du C++, votre décision de troquer l'efficacité du programmeur, la sécurité et la fiabilité du logiciel pour les performances d'exécution n'était-elle pas une erreur fondamentale ?

BS : Eh bien, je ne pense pas avoir fait un tel compromis. je veux élégant et code efficace. Parfois, je comprends. Ces dichotomies (entre efficacité contre exactitude, efficacité contre temps du programmeur, efficacité contre haut niveau, et cetera.) sont fausses.

Ce que j'ai fait, c'est concevoir C++ comme un langage de programmation système avant tout : je voulais être capable d'écrire des pilotes de périphériques, des systèmes embarqués et d'autres codes qui devaient utiliser directement le matériel. Ensuite, je voulais que C++ soit un bon langage pour concevoir des outils. Cela requérait de la flexibilité et des performances, mais aussi la capacité d'exprimer des interfaces élégantes. Mon point de vue était que pour faire des choses de plus haut niveau, pour construire des applications complètes, vous deviez d'abord acheter, construire ou emprunter des bibliothèques fournissant les abstractions appropriées. Souvent, lorsque les gens ont des problèmes avec C++, le vrai problème est qu'ils n'ont pas de bibliothèques appropriées ou qu'ils ne peuvent pas trouver les bibliothèques disponibles.

D'autres langages ont essayé de prendre en charge plus directement les applications de haut niveau.

Cela fonctionne, mais souvent ce soutien se fait au détriment de la spécialisation. Personnellement, je ne concevrais pas un outil qui ne pourrait faire que ce que je voulais – je vise la généralité.

ENFANTS : Comment expliquez-vous le fait que le C++ soit à la fois largement critiqué et ressenti par de nombreux programmeurs, mais en même temps très largement utilisé ? Pourquoi est-ce si réussi ?

BS : La réponse simple est, il n'y a que deux sortes de langages : ceux dont tout le monde se plaint et ceux que personne n'utilise.

Il y a plus de systèmes utiles développés dans des langues considérées comme horribles que dans des langues louées pour être belles – beaucoup plus. Le but d'un langage de programmation est d'aider à construire de bons systèmes, où le bien peut être défini de plusieurs manières. Ma brève définition est correcte, maintenable et suffisamment rapide. L'esthétique compte, mais avant tout un langage doit être utile ; il doit permettre aux programmeurs du monde réel d'exprimer des idées du monde réel de manière succincte et abordable.

La principale raison du succès de C++ est simplement qu'il répond à ses objectifs de conception limités : il peut exprimer une vaste gamme d'idées directement et efficacement. Le C++ n'a pas été conçu pour faire une seule chose vraiment bien ou pour empêcher les gens de faire des choses considérées comme mauvaises. Au lieu de cela, je me suis concentré sur la généralité et la performance.

Je suis sûr que pour chaque programmeur qui n'aime pas le C++, il y en a un qui l'aime. Cependant, un de mes amis est allé à une conférence où l'orateur principal a demandé au public d'indiquer à main levée, un, combien de personnes n'aimaient pas C++, et deux, combien de personnes avaient écrit un programme C++. Il y avait deux fois plus de personnes dans le premier groupe que dans le second. Exprimer son aversion pour quelque chose que vous ne connaissez pas est généralement connu sous le nom de préjugé. De plus, les plaignants sont toujours plus bruyants et plus sûrs que les partisans – les gens raisonnables reconnaissent les défauts. Je pense en savoir plus sur les problèmes du C++ que n'importe qui d'autre, mais je sais aussi comment les éviter et comment utiliser les points forts du C++.

Et puis, bien sûr, vous ne vous attendez pas à ce que les partisans des langages qui ont perdu la concurrence avec C++ soient polis à ce sujet. Le développement de logiciels n'a pas ce degré de professionnalisme, même si j'espère qu'il finira par le faire. La science est différente à cet égard : lorsqu'un nouvel outil, une nouvelle technique ou une nouvelle théorie l'emporte, les gens voient cela comme un progrès. Dans les logiciels, les contributions des concurrents et des prédécesseurs ne sont pas largement reconnues, appréciées ou même comprises.

ENFANTS : Dans La conception et l'évolution du C++ , vous prétendez que Kierkegaard a eu une influence sur votre conception de la langue. Est-ce une farce?

BS : Un peu prétentieux, peut-être, mais pas une blague. Une grande partie de la réflexion sur le développement logiciel se concentre sur le groupe, l'équipe, l'entreprise. Cela se fait souvent au point où l'individu est complètement immergé dans la culture d'entreprise sans débouché pour des talents et des compétences uniques. Les pratiques des entreprises peuvent être directement hostiles aux individus dotés de compétences et d'initiatives exceptionnelles en matière technique. Je considère qu'une telle gestion des techniciens est cruelle et inutile. Kierkegaard était un ardent défenseur de l'individu contre la foule et a une discussion sérieuse sur l'importance de l'esthétique et du comportement éthique. Je ne pouvais pas indiquer une caractéristique spécifique du langage et dire, voyez, il y a l'influence du philosophe du XIXe siècle, mais il est l'une des racines de ma réticence à éliminer les caractéristiques de niveau expert, à abolir les abus et à limiter les caractéristiques à ne supporte que les utilisations que je sais être utiles. Je n'aime pas particulièrement la philosophie religieuse de Kierkegaard, cependant.

ENFANTS : Que regrettes-tu le plus ?

BS : Pas de regrets! Eh bien, bien sûr, je rêve de ce que j'aurais pu faire différemment et mieux, mais sérieusement, qui suis-je pour deviner, disons, le millésime 1984 de Bjarne ? Il avait peut-être moins d'expérience que moi, mais il n'était pas moins intelligent, probablement plus intelligent, et il avait une meilleure compréhension du mot de 1984 que moi. C++ a été utilisé pour construire de nombreux systèmes qui améliorent nos vies, et il a eu une influence positive significative sur les langages et les systèmes ultérieurs. C'est quelque chose dont on peut être fier.

Cliquez sur ici pour lire notre deuxième entretien avec Stroustrup.

cacher