De temps à autre, un bond dans évolution fait progresser et transforme l'ensemble de l'ingénierie. Le développement de logiciels a connu un bon de ce type avec l'introduction du langage de programmation C++. Ce bond n'était pas inhérent au langage en tant que tel : des langages orientés objets tels que Simula67 et Smalltalk existaient avant C++. Mais comme C++ a été créé à partir du langage de programmation C (et pouvait compiler les programmes C existants), il est parvenu à rendre les abstractions de la pensée orientée objets accessibles au grand public.

C++ a suscité énormément de réflexion autour de la conception et du développement de logiciels, des modèles de conception à la métaprogrammation. Et du fait de sa portabilité entre les différentes plates-formes matérielles et de son expressivité bas niveau, il ne fait aucun doute que C++ va devenir essentiel dans un monde où le matériel devient toujours plus petit et plus rapide.

J'ai récemment eu le plaisir de discuter avec Bjarne Stroustrup, le créateur du langage C++, d'un grand nombre de sujets, de son opinion sur les langages aux tendances générales du secteur en passant par ses livres de chevet. La plupart de mes questions m'avaient été suggérées par les lecteurs de mon blog. J'en profite d'ailleurs pour remercier tous ceux qui ont proposé des questions. Et bien sûr, pour remercier Bjarne.

Howard Dierking Pourquoi les langages de programmation touchent-ils aussi profondément les gens, au point d'engendrer la création de communautés de fanatiques de l'un ou l'autre langage ?

Bjarne Stroustrup Vous devriez plutôt demander à un psychologue, un sociologue ou peut-être même à un économiste mais pas à un informaticien ! Je pense que les langages utilisés pour exprimer nos idées deviennent une partie de nous-mêmes. Par conséquent, si vous ne connaissez qu'un langage, vous pourriez vous sentir personnellement menacé par les adeptes d'autres langages. Dans ce cas, il semble judicieux de bien connaître plusieurs langages. Je ne pense pas que l'on puisse être un professionnel des logiciels et ne connaître qu'un seul langage de programmation. Il y a peut-être aussi une raison économique : bien que la compréhension de base dépasse les limites du langage de programmation, ce n'est pas le cas pour de nombreuses compétences pratiques. Si je ne connais que le langage X et ses jeux d'outils et que vous soutenez le langage Y et ses jeux d'outils, vous menacez directement mon gagne-pain. Là encore, la solution semble être d'apprendre plusieurs langages et leurs jeux d'outils (et de bien connaître les principes de base). Malheureusement, mes suggestions ne tiennent pas compte du fait qu'il ne reste que très peu de temps aux gens une fois qu'ils ont fait tout ce qui leur semble simplement nécessaire. Mais ceci n'excuse en rien le fanatisme !

HD Quel doit être le rôle de l'environnement de développement intégré (IDE) dans le développement de logiciels ? Comment l'IDE doit-il prendre en charge un langage ?

BS Je n'utilise pas beaucoup les IDE. J'apprécie un éditeur d'IDE réactif qui comprend mon langage, mais je souhaite également pouvoir travailler sans IDE. Mon opinion pourrait être différente si un bon IDE était universellement disponible, ou s'il faisait partie intégrante du langage ou inversement (voir la figure 1). C'est ici que mon désir de portabilité du code entre en jeu. Avec C++, je souhaite pouvoir comprendre mon système uniquement à partir du code source des fichiers sources. Je déteste vraiment les mécanismes d'IDE qui impliquent des transformations ou une génération qui ne peut pas être représentée en tant que code exploitable par les utilisateurs.

HD Considérez-vous le bruit ou la lisibilité comme un problème dans les langages polyvalents actuels ? Si oui, comment y remédier ?

BS Une syntaxe plus simple serait agréable, mais je pense que lorsqu'ils parlent de lisibilité, les récriminations de la plupart des gens ne concernent pas tant le texte réel que la complexité de ce qui est exprimé. Trop de gens s'attendent à pouvoir décrypter n'importe quel programme écrit dans n'importe quel langage et comprendre toutes les constructions utilisées pour exprimer le programme ainsi que toute la logique du programme lui-même, et ce avec seulement un peu d'aide d'un moteur de support en ligne. Comparons cela à la façon dont nous abordons et utilisons les langages naturels. Vous attendriez-vous à comprendre un sonnet de Shakespeare sans détenir quelques informations de base ? Et qu'en est-il de « Beowulf » dans le vieil anglais original ? Peut-être attendons-nous trop de nos langages de programmation. N'importe quel langage capable d'exprimer tout ce qui est nécessaire pour un large éventail d'applications pourrait être considéré comme extrêmement complexe pour n'importe quelle application donnée, mais il doit pouvoir être utilisé avec une série d'applications pratiquement illimitée. Les langages spécifiques au domaine peuvent aider dans certains cas spécifiques mais nous devons d'abord traiter les complexités de nombreux langages et de leurs interactions.

HD Comment un langage polyvalent devrait-il prendre en charge les idées de conception d'application telles que la programmation de composant et la programmation de service ?

BS Un langage polyvalent doit pouvoir prendre en charge l'écriture de bibliothèques exprimant des notions générales et spécifiques aux applications, prendre en charge la création d'outils et fournir le liant nécessaire pour connecter les différentes parties d'une application. Pour cela, le langage doit être flexible et avoir un système de type expressif, des performances de base correctes et une stabilité à long terme.

HD La répartition multiple est-elle une bonne chose ?

BS Oui. Un langage de programmation conventionnel orienté objets à répartition unique (tel que Simula, C++, Smalltalk, Java et C#) ne peut pas exprimer de façon élégante des opérations simples, telles que des multiplications ou la recherche de l'intersection de deux formes, où les types exacts ne sont connus qu'au moment de l'exécution. Le code résultant (basé sur la double répartition, le modèle visiteur, et ainsi de suite) est lent et n'est pas aussi maintenable que nous le souhaiterions. Les langages qui prennent en charge la répartition multiple au moment de l'exécution (comme Dylan et CLOS) fonctionnent mieux et les langages (tels que C++) qui la prennent en charge au moment de la compilation peuvent parfois aider. L'année dernière, avec certains de mes étudiants, j'ai publié un article suite à nos travaux de recherche sur la façon d'ajouter proprement la répartition multiple à C++. Le code résultant pour la répartition multiple est plus court, plus simple, utilise moins de mémoire et s'exécute plus rapidement que toutes les solutions de contournement que nous avons vues (voir la Figure 2). Cependant, ces travaux sont arrivés trop tard pour C++0x. Vous trouverez un article sur ce sujet à l'adresse research.att.com/~bs/multimethods.pdf.

HD Que pensez-vous de la covariance/contravariance dans C++ aujourd'hui ? Prévoyez-vous une modification du comportement actuel dans les futures versions du langage ?

BS Pas vraiment. À ce niveau, je pense que C++ fait ce qu'il doit faire. Vous pensez aux exemples tels que la conversion d'un vecteur<Pomme> en un vecteur <Fruit>, n'est-ce pas ? Ce processus est très dangereux à moins que le vecteur <Fruit> soit immuable (ou que vous puissiez lui ajouter un vecteur Orange). Je ne pense pas que la vérification implicite du type au moment de l'exécution soit une approche idéale pour de tels problèmes.

HD Que pensez-vous de faire de la transmission de message une fonctionnalité clé des langages, par opposition à l'appel de méthode ?

BS J'aime la transmission de messages explicite mais je ne l'ai utilisée qu'une seule fois il y a assez longtemps et dans le contexte des systèmes distribués. En réalité, pour qu'elle fonctionne à grande échelle, nous devrions sérieusement revoir le langage et la prise en charge d'outils pour la transmission de message. Je ne pense pas que cela a été fait, mais je peux me tromper. De nombreux problèmes associés au partage et au verrouillage disparaissent si vous vous appuyez sur les messages et les files d'attente de messages. J'aimerais voir une bibliothèque C++ standard pour cela, et je vais peut-être l'avoir (dans quelques années) !

HD Existe-il un conflit inhérent dans la tendance des langages polyvalents à prendre en charge un large public divers tout en encourageant les améliorations au niveau de l'expressivité du code et de l'élégance de conception ? Quel est le rôle du langage dans la prise en charge de cette dernière ?

BS Je suppose qu'il y effectivement un conflit dans le sens où l'on peut approcher l'élégance grâce à la spécialisation. Si votre public est réduit (une communauté d'utilisateurs), vous pouvez vous adapter à ses goûts (uniquement). Vous pouvez vous éloigner des notations et des concepts conventionnels si vous contrôlez votre communauté d'utilisateurs d'une façon ou d'une autre (en disant quelque chose du style « lisez la documentation sur la théorie des types pour pouvoir utiliser ceci »). Un langage polyvalent est contraint non seulement par la nécessité de prendre en charge une grande variété d'utilisations, mais également par la nécessité d'être enseignable à de vastes groupes de personnes provenant d'horizons divers et ayant toute une série d'idées préconçues (les principes de base doivent être utilisables par un lycéen ayant un enseignant médiocre).

À mon avis, un langage polyvalent peut encourager l'élégance à condition qu'un code élégant puisse y être exprimé. Avec C++, il est parfaitement possible d'écrire un code très élégant. En appartenant à un langage polyvalent et en étant largement disponibles, des exemples de code élégant peuvent se retrouver entre des millions de mains et dans des articles et manuels lisibles par des millions de gens. Aucun langage spécialisé, aussi élégant soit-il, n'a ces possibilités.

HD Vous êtes-vous trop concentré sur l'architecture ?

BS Non. En tout cas, pas de la façon dont je définis l'architecture. Au contraire, l'accent n'a pas été suffisamment mis sur l'architecture et il existe trop de code médiocre reflétant une compréhension insuffisante des principes structuraux. Je pense que l'un des problèmes majeurs avec l'architecture, c'est que de nombreux programmeurs n'ont qu'une vague idée de ce qui fait qu'un bon code est bon. Il ne suffit pas de savoir le reconnaître lorsqu’on le rencontre. Il ne suffit pas de disposer d'une liste de choses à ne pas faire. Nous avons besoin de règles normatives précises.

HD La communauté Open Source a-t-elle aidé, nui ou n'a-t-elle eu aucun impact sur la qualité, la conception et le professionnalisme des logiciels ?

BS Il s'agit d'une question vraiment difficile. Dans certains cas, elle a aidé (en augmentant la qualité du code et le degré de professionnalisme des gens impliqués). Dans certains cas, elle a nui (en enseignant des très mauvaises habitude et attitudes) et dans de nombreux cas, je serais incapable de vous le dire !

Il nous est actuellement impossible de vérifier les effets sur la communauté dans son ensemble. Nous ne pouvons pas non plus savoir ce qui serait arrivé si le degré de travail Open Source avait été plus ou moins important. La communauté est tout simplement trop vaste pour que je puisse le deviner.

HD Voyez-vous un changement important vers les langages dynamiques dans un avenir proche ?

BS Pas vraiment. Je pense que les gens comparent trop souvent pommes et oranges. Je ne pense pas que nous ayons le choix entre les langages statiques et les langages dynamiques en général, et je ne pense pas en outre que les langages entrent clairement dans une catégorie ou dans l'autre : la plupart sinon tous les langages dynamiques ont des aspects déterminés de façon statique et tous les principaux langages statiques peuvent faire des choses qui nécessitent une détermination au moment de l'exécution de la signification des valeurs. Il existe bien sûr des modes et je ne peux pas les deviner. Mais à mon avis, de nombreux choix de langage de la vie réelle sont faits de façon rationnelle en fonction des exigences d'une application, d'un domaine d'application et/ou des compétences des développeurs disponibles. Par exemple, je n'essaierais pas d'implémenter un service d'exécution Java en (disons) Ruby, ni d'exprimer un langage de simulation très interactif comme C++ (par opposition à son implémentation).

HD Pensez-vous que qu'il soit judicieux de supprimer à terme toute existence de void*/variant/object/etc ? ((La figure 3 est un bon exemple).

BS Je pense qu'en principe, se débarrasser de toutes les options fourre-tout est une bonne idée. Mais en réalité, ceci ne peut être fait qu'à condition de disposer d'une classification complète de tout ce qui doit être exprimé pour que nous puissions toujours être plus spécifiques. Par exemple, je n'ai jamais vu une fonction réelle qui puisse faire quelque chose à chaque objet. Si vous faites quelque chose, vous ne connaissez jamais vraiment tout sur ce que vous manipulez (une fonction de transfert pure est la chose la plus proche d'un contre-exemple qui me vienne à l'esprit). Les travaux actuels sur les concepts dans le monde du C++ (contraintes/exigences sur les algorithmes génériques) apporteront une aide non négligeable ici, mais je ne vois pas comment nous pourrions nous passer de quelques mécanismes vraiment généraux pour exprimer « quelque chose mais je ne sais pas vraiment quoi » pour traiter des besoins imprévus.

HD Avec la tendance qui revient aux langages faiblement typés, devons-nous commencer à envisager à nouveau la notation hongroise ?

BS Je ne suis pas certain que cette tendance existe, bien qu'il y ait probablement une augmentation de la part du travail total adapée aux langages faiblement typés. En d'autres termes, l'utilisation de langages à typage statique pourrait continuer d'augmenter (à mon avis) tandis que l'utilisation de langages faiblement typés augmente encore plus rapidement. Et non, n'utilisez surtout pas la notation hongroise. C'est une très mauvaise idée. Le code source doit refléter la signification d'un programme et non simuler un système de type. Si vous souhaitez vraiment utiliser la notation hongroise, vous utilisez alors probablement un langage peu approprié à votre application.

HD En 2000, vous avez présenté un exposé intitulé « C++: A New Language for a New Millennium » et avez introduit le concept d'inclusion dans un wrapper<T>. Il s'agit en fait de programmation orientée aspect. Que pensez-vous de la programmation orientée aspect (en règle générale) et de sa formalisation de l'inclusion dans un wrapper <T> (astuces, conseils, etc.) ?

BS Je ne me suis pas assez penché sur la programmation orientée aspect pour vous donner une réponse solide. J'aime que la composition (surtout non intrusive) soit prise en charge dans un langage (par opposition à « non prise en charge » et à « prise en charge par un outil »). Les outils extralinguistiques et les chaînes d'outils non standard m'inquiètent. Le succès des modèles C++ en matière de composition non intrusive est impressionnant. Pensez simplement à la bibliothèque de modèles standard (STL) et à certaines des utilisations dans la programmation des systèmes intégrés. C'est une vraie force que de pouvoir associer des idées sans les imposer dans une hiérarchie rigide ou préconçue. Cependant, cela a été difficile à gérer pour certains développeurs et certains responsables de la maintenance. Et c'est également lourd en termes de notation. C++0x tente de résoudre ces problèmes sans affecter la flexibilité ni les performances.

HD Certaines caractéristiques du langage C++ peuvent potentiellement créer certaines conséquences inattendues particulièrement déplaisantes (telles que des macros). Quelles sont les autres conséquences inattendues que vous aimeriez voir désambiguïsées dans C++ ou dans les langages modernes en général ?

BS En fait, je savais que les macros étaient indésirables lorsque j'ai commencé à utiliser le langage C. Mais comme la plupart des gens, j'ai sous-estimé leur effet indésirable et leurs influences aussi négatives qu'envahissantes. L'utilisation constante de macros dans C est probablement la principale raison pour laquelle nous ne disposions pas d'excellents environnements de développement C++ il y a 10 ans. Il existe beaucoup trop de façons déroutantes d'initialiser des objets dans C++. J'espère résoudre ces problèmes avec un mécanisme uniforme dans C++0x. J'ai mentionné les modèles lors de ma réponse à votre précédente question. Ils représentent la principale réussite des versions de C++ post 1985, mais ce succès a grevé le langage. Une nouvelle fois, certaines parties de C++0x sont conçues pour traiter ces problèmes.

De nombreux problèmes, mineurs et moins mineurs que nous avons découverts au fil des ans ne peuvent pas être résolus dans C++ pour des raisons de compatibilité. Par exemple, la syntaxe de déclarateur est une complication inutile et n'importe quelle notation linéaire serait plus adaptée. De même, de nombreux comportements par défaut sont inappropriés : les constructeurs ne devraient pas faire de conversion par défaut. Les noms ne devraient pas être accessibles par défaut à partir d'autres fichiers sources, et ainsi de suite. Le fait de ne pas pouvoir contrôler l'éditeur de liens a été une source constante de problèmes ; en particulier, les analystes programmeurs semblent prendre plaisir à fournir des fonctionnalités similaires dans des formulaires incompatibles.

Nous avons également eu des surprises positives. La plus spectaculaire a été l'utilisation fréquente de destructeurs dans les techniques liées à la gestion des ressources et des erreurs (à l'aide d'exceptions). Je savais que les destructeurs étaient une bonne idée (après tout, vous devez inverser l'effet d'un constructeur) mais je ne m'étais pas rendu compte à quel point ils deviendraient essentiels à une bonne utilisation de C++.

HD Vous avez déclaré sur votre site Web, « Je pense que nous devons chercher l'élégance dans les applications créées plutôt que dans les langages mêmes. » L'adoption de langages spécifiques au domaine (DSL) est-il une convergence de ces langages ?

BS Oui, j'en suis presque sûr. Il s'agit souvent d'une tentative dans cette direction. Il arrive même parfois que cela fonctionne.

HD Que pensez-vous des DSL en général ? Comment envisagez-vous la relation entre les DSL et les langages polyvalents ?

BS Je m'inquiète du nombre de langages conçus, implémentés et introduits en fanfare, puis qui disparaissent sans impact significatif. Pendant cette phase de développement souvent de plusieurs années, un nouveau langage consomme des ressources considérables pratiquement sans le moindre retour. J'ai écrit un article sur ce phénomène appelé « A Rationale for Semantically Enhanced Library Languages » (research.att.com/~bs/SELLrationale.pdf). Dans cet article, je prône l'utilisation de bibliothèques, éventuellement prises en charge par des outils, et un langage polyvalent.

À mon avis, un DSL doit être utilisé en dernier recours, et non en premier. Si cela est possible, le DSL doit être fermement enraciné dans un langage polyvalent et des chaînes d'outils standard. Un DSL nécessite un langage polyvalent (ou au moins un langage de programmation de systèmes) pour son implémentation et l'implémentation de ses primitives au moment de l'exécution. Je pense que l'idéal serait qu'un DSL soit fermement et délibérément associé à au moins un langage polyvalent pour faciliter l'ajout de nouvelles installations via l'utilisation de bibliothèques écrites dans ce langage polyvalent. Évidemment, un professionnel doit maîtriser plusieurs langages. Mais je me demande si la somme complexe de plusieurs DSL ne pourrait pas devenir si élevée qu'elle en devienne un problème. De même, beaucoup (si ce n'est pas la totalité) des DSL semblent « souhaiter » devenir des langages polyvalents.

HD Vous avez mentionné que de nombreuses constructions dans C++ sont intentionnellement restées ambiguës en raison de définitions variées sur différents matériels. Voyez-vous des avancées dans l'interopérabilité pouvant désambiguïser certaines de ces constructions ?

BS Le terme « ambiguës » est incorrect. Bien trop de choses sont restées indéfinies ou définies par l'implémentation. Je pense que si je pouvais redéfinir C++ en partant de zéro, il ne présenterait aucun comportement indéfini et présenterait beaucoup moins de comportements définis par l'implémentation. Cependant, je ne possède pas de machine à remonter le temps. Et nous ne pouvons simplement pas rompre des centaines de millions de lignes de code en choisissant un ensemble de résolutions aujourd'hui.

HD Quelle méthodologie de processus avez-vous tendance à utiliser et enseigner ?

BS Identifier les concepts d'application clés, identifier les bibliothèques utiles, créer de nouvelles bibliothèques pour prendre en charge le concept d'application, tester les idées très tôt, intégrer très tôt, tester tôt et fréquemment, utiliser la documentation et les didacticiels comme outils de conception et créer des programmes plus volumineux partir de programmes plus petits (en effectuant des itérations tout au long du développement). Je ne vous surprendrai pas en disant que je travaille actuellement sur des projets relativement petits.

HD Voyez-vous une intersection ou une affinité entre un langage et une méthodologie de développement ?

BS Il me semble que oui, dans la mesure où la conception de bibliothèque est considérée comme une technique de conception/développement. Le fait de se concentrer sur des installations de niveau de plus en plus élevé (plus proche de l'application) via la création de bibliothèques place les exigences sur le langage. Je n'insisterais pas trop sur ce point, mais à mon avis, on ne peut pas avoir une méthodologie de développement unique pour (disons) COBOL, C, Java, C++ et Python et s'attendre à obtenir davantage que la prise en charge minimale de chaque langage.

HD Quelles sont vos règles d'or lorsque vous créez un logiciel ?

BS Se concentrer sur les concepts clés, se concentrer sur leurs interfaces, se concentrer sur la gestion des ressources (mémoire, fichiers, verrous et ainsi de suite), se concentrer sur la gestion des erreurs. La conception de bons invariants pour les classes et RAII (Resource Acquisition Is Initialization) sont des techniques essentielles.

HD On entend partout parler du concept d'agilité. Qu'entendez-vous par « agilité » ? Le C++ prend-t-il en charge l'« agilité » ?

BS Je n'utilise pas ce mot. Il est beaucoup trop vague. Bien sûr, C++ prend en charge l'agilité, quoi que cela signifie.

HD Comment un langage peut-il évoluer pour prendre en charge des fonctionnalités avancées telles que les modèles, les événements dynamiques et le code autoécrit tout en restant accessible aux nouveaux utilisateurs ?

BS Je ne sais pas. Je ne pense pas qu'il existe une réponse générale. Les nouvelles fonctionnalités peuvent être importantes dans la mesure où elles prennent en charge des techniques plus efficaces dans le contexte d'un langage. Cependant, la stabilité est essentielle : la force de C et C++ réside entre autres dans le soin pris par les comités de normalisation pour que l'ancien code (souvent vieux de plusieurs décennies) reste valide et que les nouvelles fonctionnalités s'intègrent sans heurt. Tout ceci n'est, pour le moins, pas simple et l'introduction de nouvelles fonctionnalités n'aboutit pas toujours. Trop souvent, les inquiétudes des novices sont ignorées par les membres des comités de normalisation. Certaines des fonctionnalités clés prévues pour C++0x, telles que l'initialisation uniforme, le mot clé auto (pour déduire un type variable de son initialiseur), et des concepts tels que la vérification des exigences d'argument de modèle devraient faciliter l'utilisation du langage par les profanes.

HD Considérez-vous les métadonnées de langage comme un élément de base clé des langages de programmation à venir ?

BS Non. En ce qui me concerne, l'utilisation importante de métadonnées me met très mal à l'aise.

HD Voyez-vous un changement fondamental de la simultanéité à l'avenir si les processeurs commencent à augmenter le nombre de noyaux ? Comment la difficulté de la simultanéité pourra-t-elle est résolue dans C++0x ?

BS C++0x fournit les bases : un modèle machine adapté au multithreading, une série de primitives de bas niveau pour la création de bibliothèques et une API de bibliothèque de threads et de verrous. J'aimerais voir davantage (et ce sera probablement le cas dans les prochaines années) de modèles de simultanéité de plus haut niveau, en particulier des modèles plus simples, basés sur les pools de threads, les futures et les files d'attente de messages. Nous devons trouver de façons automatiques ou quasi-automatiques de répartir le calcul sur plusieurs processeurs et de localiser les activités sur ces processeurs. Le travail dans ce domaine est très important, en particulier en C++, mais il n'existe pas encore de modèle dominant. STAPL de Texas A&M University et TBB d'Intel en sont des exemples.

HD Que pensez-vous du GPGPU (general-purpose computing on graphics processing units) ?

BS C'est intéressant mais je n'ai pas suffisamment d'expérience pratique pour le commenter au delà des évidences, à savoir qu'il faut d'importantes compétences pour utiliser un processeur spécialisé.

HD Prévoyez-vous une plus grande transparence de l'informatique hautes performances (HPC) pour les programmeurs ? Et cette transparence sera-t-elle un objectif pour un langage, une bibliothèque ou une infrastructure ?

BS Une certaine transparence seulement. Je ne pense pas que la simultanéité puisse ou doive être complètement transparente. Tout d'abord, la gestion des erreurs peut être très différente en fonction de la disponibilité des processeurs, de la mémoire partagée (ou non), de la distribution (ou non) et de la latence. L'approche de la transparence lorsqu'elle est appropriée est et restera un objectif pour les nouveaux langages, les nouvelles fonctionnalités de langage et les nouvelles bibliothèques (mes préférées). Au niveau des bibliothèques, c'est uniquement faisable si le langage sous-jacent fournit les garanties de base nécessaires en tant que modèle machine et un jeu de primitives de très bas niveau. Ce que C++0x fera.

HD Comment se passe la conception de C++0x ?

BS Nous touchons presque au but ! Enfin ! Du moins, je l'espère ! Rien n'est jamais certain tant que les votes ne sont pas enregistrés et vers la fin, la tension et les émotions sont à leur comble. Selon la planification actuelle, nous devrions voter la nouvelle norme complète et la soumettre aux commentaires du public en juin, ce qui donnerait une nouvelle norme officielle de 12 à 18 moins plus tard. Évidemment, je pourrais écrire un livre entier sur ce sujet : comment créer une norme, quels devraient être les principes directeurs et quel en est le contenu exact ? Je l'ai presque fait ; vous n'avez qu'à lire mon article HOPL intitulé « Evolving a language in and for the real world: C++ 1991-2006 » (disponible à l'adresse research.att.com/~bs/hopl-almost-final.pdf) et tout ce qui contient C++0x dans son titre sur mes pages Web. Si vous aimez souffrir, vous pouvez rechercher « WG21 » sur le Web et lire tout les articles du comité de normalisation ISO C++ (notamment toutes les propositions). À tout le moins, vous serez convaincu que cela représente un travail monumental ! L'amélioration d'un langage de programmation très utilisé n'est pas évidente. Surtout d'un langage qui constitue la couche d'implémentation de nombreux outils, langages et applications. Vous trouverez également des vidéos réalisées par moi-même ou d'autres en ligne et sur ma page C++.

HD Que lisez-vous actuellement ?

BS Pour ce qui est du technique, je suis revenu à Hennessy et Patterson pour me rafraîchir la mémoire sur l'architecture système. J'essaie également de rassembler des travaux et des articles qui aident les gens à écrire du bon code (pour un cours que j'enseigne). C'est beaucoup plus difficile que je le pensais. Les travaux universitaires ont tendance à être très spécialisés. Quant aux travaux non universitaires, ils promettent souvent beaucoup mais finalement, ne contiennent que très peu d'éléments concrets (toute suggestion est la bienvenue). Bien sûr il y a un flux régulier de documents relatifs à la normalisation de C++. J'étais sur le point de me rafraîchir la mémoire sur Knuth, mais quelqu'un s'est sauvé avec mon volume III... Je vais donc devoir patienter ! Quant à mes lectures plaisir, je suis actuellement plongé dans la série Aubrey et Maturin d'O'Brian. J'essaie de rafraîchir ma compréhension des sciences. Je viens donc de faire une cure de Richard Dawkins. Je viens également de terminer le livre de Rodger intitulé « Command of the Ocean: A Naval History of Britain, 1649-1815 » (d'où mon retour à O'Brian).

HD Vous avez déclaré « J'ai toujours rêvé d'un ordinateur qui soit aussi simple à utiliser qu'un téléphone. Mon rêve s'est réalisé : je n'arrive plus à utiliser mon téléphone ! ». Possédez-vous un Smartphone ? Sont-ils devenus plus simples à utiliser ?

BS Je ne suis pas un grand fan des téléphones. Je préfère la communication directe et sinon, la communication écrite. Même le téléphone le plus sophistiqué ne remplacera jamais un message électronique bien écrit. J'utilise un petit téléphone que je conserve confortablement dans ma poche et je suis loin d'utiliser toutes ses fonctionnalités. Je pourrais aisément échanger toutes ses fonctionnalités contre la fiabilité et une bonne qualité sonore. Pour être honnête, les interfaces utilisateur sont nettement mieux actuellement que lorsque j'ai fait cette remarque.