Discussion :

[Bill Fassinou]

Bjarne Stroustrup, créateur du C++, s'exprime sur les systèmes distribués, la sécurité des types
et sur les langages concurrents comme Rust et Java

Le C++ est né il y a presque 40 ans maintenant, en 1983, et depuis, il n’a cessé d’évoluer et de s’améliorer. Sollicité par l’ACM (l’Association for Computing Machinery), son créateur, Bjarne Stroustrup, a eu l'occasion de revenir sur les motivations l’ayant conduit à la création du C++, la façon dont il a évolué, les autres langages existants du même calibre, ainsi que la concurrence. Pour l’ensemble de tout ceci, Stroustrup a déclaré que le C++ “est bien, bien meilleur qu'il ne l'était il y a quelques décennies”. Il s’est dit content de la manière dont le C++ a acquis une grande communauté.

Dans un AMA (Ask Me Anything) organisé par l’ACM en juin dernier, Stroustrup a donné son avis sur le langage qu’il a créé. Dans un premier temps, on lui a demandé ce qu’il changerait s'il était capable de remonter le temps au jour où il a créé le C++. « Hum... C'est une question de machine à remonter le temps, et nous n'avons pas de machine à remonter le temps », a-t-il déclaré. Il a tout de même dit que cela n’est pas une bonne idée de vouloir changer des aspects d’un langage ou toute autre chose dès lors que celui-ci à des utilisateurs. Cela risquerait de casser leur code, selon lui.

« L’un des aspects les plus importants de la conception d'un langage de programmation est que si vous réussissez, vous avez ce que vous avez fait il y a plusieurs années et décennies, et vous devez vivre avec. Une fois que vous avez des utilisateurs, vous avez des responsabilités, et l'une des responsabilités est de ne pas casser leur code. La stabilité devient donc un enjeu majeur. Il y a quelques centaines de milliards de lignes de C++ sur le marché, et nous ne pouvons pas les casser », a-t-il déclaré. Par la suite, il a fait savoir qu’avec le C++, il n’avait pas essayé de réinventer la roue.

Stroustrup a déclaré à son interlocuteur qu’il s’est, dans un premier temps, contenté d’étendre les conventions du langage de programmation C qui existait déjà. « Je savais que c'était un problème quand j'ai commencé. Cependant, il existait déjà une communauté C, et je pouvais passer mon temps à enseigner aux gens comment écrire une boucle For, ou je pouvais fournir un concept de classe décent. Je ne pouvais pas faire les deux. Je n'avais pas le temps », a-t-il déclaré. Ainsi, la première chose qu’il a donc faite est d’ajouter la programmation orientée objet au C.

Toutefois, il ne s’est pas arrêté là. En plus de cet ajout, il s'est aussi souvenu de ses premiers objectifs de conception pour le C++. « Je voulais une très grande liberté d'expression, une très grande généralité. Je voulais des performances comparables à celles du C codé à la main, directement sur la machine. Et je voulais une sécurité de base pour les caractères. Compte tenu du temps, de la technologie et des connaissances, j'ai obtenu deux sur trois. J'ai ensuite passé les 20 années qui ont suivi à essayer de comprendre comment nous allons obtenir le troisième », a-t-il confié.

Cette troisième chose est la sécurité des types. Cette fonction a été ajoutée plus tard au langage grâce aux “concepts”. Cela permet de limiter les types de données des modèles de fonctions du langage. Cela dit, il a ajouté qu’il n’est pas un fan de la métaprogrammation de modèles, estimant qu’elle est « laide et compliquée, mais tellement pratique que des personnes saines d'esprit la feront malgré ses problèmes ». Ainsi, s’il pouvait changer une chose au C++, Stroustrup veut pouvoir remplacer les parties laides et compliquées de la métaprogrammation par quelque chose de plus simple.

En outre, il a précisé plus loin que s’il avait pu inventer les concepts en 1988, « nous aurions été mieux lotis aujourd'hui ». Il a fini cette partie en expliquant que le succès du C++ est basé sur sa grande communauté, de grandes performances, une grande flexibilité, un support d'outils massif, des bibliothèques massives. « C'est juste un bon langage solide », conclut-il. Questionné à propos de la concurrence, il a aussi fait plusieurs déclarations. Selon lui, seulement deux choses peuvent arriver si vous essayez de remplacer un langage, comme le C++.

« Vous savez, quand vous simplifiez un langage pour le rendre plus facile, vous jetez généralement quelque chose. Cependant, même au-delà, les langages simplifiés finissent tous par emprunter l'une des deux voies suivantes : vous échouez parce que vous ne pouvez pas amener les gens à utiliser votre langage ou vous réussissez, et votre langage se développe », a-t-il déclaré. Il a donné un exemple de cela : « Java est aujourd'hui trois, quatre, cinq fois plus complexe et plus grand qu'à ses débuts », prétendant qu'il était meilleur que le C++ parce qu'il était plus simple.

À la question de savoir quel était son langage préféré, il a dit : « Je ne crois pas qu'il y ait ou puisse y avoir un langage de programmation parfait, du moins pas à l'échelle de temps dont nous parlons, quelques décennies ou une centaine d'années. Peut-être dans une centaine d'années, mais pas de mon vivant ». Pour ce qui concerne Rust, le langage conçu par Mozilla et qui fait beaucoup parler de lui actuellement, il a déclaré que le C++ peut faire absolument tout ce que Rust fait et avec des performances similaires.

Selon lui, les développeurs de Rust l’accusent de copier certains concepts de Rust. Voici ce qu’il a dit à propos : « c'est très humoristique quand certains développeurs de Rust viennent m'accuser d'avoir volé certaines de leurs idées sans le reconnaître, alors que certaines des choses que j'ai faites, je les ai faites il y a presque 40 ans ». Il a ensuite parlé de ce sur quoi il travaille actuellement chez Morgan Stanley, une banque américaine. Il travaille sur les systèmes distribués, la mise en réseau, l'obtention de données de A à B sous diverses contraintes…

Selon ce qu’il a dit, ces points constituent le sujet d’un doctorat sur lequel il travaille aussi. Enfin, il a fait part de certains objectifs en matière de design qui pourraient être plus éloignés à l'avenir. « Nous avons un modèle pour une meilleure concurrence à venir. Il est presque certain que ce sera dans la [version C++] 23. Il existe et il est utilisé. Il est soutenu par des gens comme Facebook, NVIDIA et Intel... C'est donc là que nous aurons une meilleure concurrence, une meilleure utilisation du matériel... Au-delà de cela, j'envisage une concordance de style fonctionnel », a-t-il déclaré.

« Je travaille sur ce sujet depuis longtemps, je l'ai proposé pour le C++ 17. Nous l'aurons peut-être pour 23 ou 26, mais les choses avancent lentement quand on déplace une communauté vraiment massive. Si nous pouvons le faire correctement, j'aimerais beaucoup », ajouta-t-il. Il a aussi appelé à la fin à beaucoup plus de soutien pour la contribution distribuée. « C'est comme ça que j'ai commencé. Je voulais construire ce qui aurait été le premier cluster Unix, si j'avais réussi à le terminer au lieu de me laisser distraire par le C++ », a-t-il fait remarquer.

« Et j'aimerais que le langage, ou les bibliothèques, permettent de communiquer avec de grands groupes d'ordinateurs et de cœurs, etc. Nous sommes assez bons en multicœur, en multithreading, ce genre de choses. Mais j'aimerais en venir à la mémoire non partagée. En tout cas, c'est mon cheval de bataille personnel, depuis longtemps », a-t-il conclu.

Source : vidéo

Et vous ?

Que pensez-vous des propos de Bjarne Stroustrup ?

Voir aussi

Linus Torvalds : le "C++ est un langage horrible" en justifiant le choix du C pour le système de gestion de version Git

L'EDI CLion 2020.2 de JetBrains disponible, avec l'ajout des projets Makefile, l'amélioration du support de CMake, une analyse de code plus précise et une meilleure conformité à la norme C++20

Big Data : la plateforme de développement pour l'analyse in-memory Apache Arrow 1.0.0 est disponible et s'accompagne de nombreuses améliorations

[Uther]

Pour ce qui concerne Rust, le langage conçu par Mozilla et qui fait beaucoup parler de lui actuellement, il a déclaré que le C++ peut fait absolument tout ce que Rust fait et avec des performances similaires.

Je trouve ce genre de critique un peu légère pour quelqu'un qui reconnait ne pas connaitre grand chose du Rust. A priori, il l'a juste essayé il y a longtemps, à l'époque où il n'était pas encore terminé. Du coup il se contente d'une critique très superficielle. Les performances c'est une chose, mais la façon dont on produit le code a son importance et ça a notamment des impacts sur la productivité et la fiabilité.

Parce qu'on peut dire exactement la même chose du C++ par rapport au C. C'est vrai que techniquement, tout ce qui est faisable en C++ est aussi faisable en C avec des performance identiques. Il n’empêche que le C++, comme le Rust, apporte des éléments intéressantes à prendre en compte au delà de l'aspect purement performance.

[emilie77]

le C++ peut fait absolument tout ce que l'assembleur fait et avec des performances similaires

[MABROUKI]

Bonjour
Le C++ c'est du C plus une couche POO , car Bjarne Stroustrup est un élève des Labos Bell ou il a côtoyé Denis Ritchie.
La couche POO permet de factoriser le code C, & permet de gagner en productivité de code.
La méta programmation (Templates) est une couche rajoutée plus tard par d'autres programmeurs, ce qui complexifie la production de code.
La méta programmation l’énerve car elle n'est pas son oeuvre.
Faut-il faire du threading ou du parallélisme contenu du matériel actuel pour améliorer les performances du code tel est le nouveau challenge de Bjarne Stroustrup.

[Aurelien.Regat-Barrel]

Parce qu'on peut dire exactement la même chose du C++ par rapport au C.

Pas tout à fait. La destruction automatique des ressources allouées (RAII) n'est pas faisable en C. Exemple simple : un type string qui gère automatiquement l'allocation et la désallocation mémoire.

Accessoirement, tout ce qui relève de l'évaluation compile-time avec constexpr n'est pas faisable non plus. Et niveau généricité, c'est pas comparable non plus. Par exemple, une simple fonction sort() capable d'inliner l'opérateur de comparaison du type concerné.

Mais je comprends ta remarque : c'est vite expédié comme comparaison. Mais je sais qu'il est très vigilant dès qu'il s'agit de s'exprimer / comparer avec un autre langage, car le moindre élément positif qu'il dit au sujet d'un autre langage est repris en boucle sur le web au son de "le créateur de C++ admet que le langage XX est meilleur" (ça s'est déjà produit).

le C++ peut fait absolument tout ce que l'assembleur fait et avec des performances similaires

Ben non : tu ne peux pas profiter de certaines instructions asm très spécifiques. C'est pour ça que certains compilos permettent d'intégrer du code asm dans le source (au détriment de la portabilité bine sûr)

Bonjour
Le C++ c'est du C plus une couche POO , car Bjarne Stroustrup est un élève des Labos Bell ou il a côtoyé Denis Ritchie.
La couche POO permet de factoriser le code C, & permet de gagner en productivité de code.
La méta programmation (Templates) est une couche rajoutée plus tard par d'autres programmeurs, ce qui complexifie la production de code.
La méta programmation l’énerve car elle n'est pas son oeuvre.
Faut-il faire du threading ou du parallélisme contenu du matériel actuel pour améliorer les performances du code tel est le nouveau challenge de Bjarne Stroustrup.

- C++ n'est pas / plus "C with Classes", l'idée que C++ est une surcouche POO a beaucoup joué dans sa mauvaise utilisation et son mauvais enseignement : c'est un langage multiparadigmes, avec dès ses débuts des concepts fonctionnels par exemple (le mot clé "const" vient de C++ et a été ensuite backporté vers C)
- templates et méta programmation sont 2 choses distinctes, encore plus maintenant où la tendance est à faire de la metaprog sans templates
- il a suivi de près la thèse et les travaux d'Andrew Sutton ainsi que tous le travail sur les concepts, donc loin de ne pas aimer ça il participe et pousse à ce que la metaprog évolue en C++. Ce qu'il n'aime pas c'est la metaprog avec les templates, mais c'est le cas de la majorité des dev C++ qui s'y essaient : c'est une critique forte des utilisateurs et une demande de beaucoup de monde de simplifier cet aspect du langage. Et sous entendre qu'il n'aime pas quelque chose au prétexte que c'est pas son oeuvre, c'est mal connaître comment le langage évolue au sein de l'ISO (processus qu'il a lui même initié).
- la tendance actuelle est de faire du parallélisme et de la concurrence sans les threads, voir les coroutines qui débarquent en C++20

[yahiko]

Le Stroustrup, mon premier bouquin sur la programmation, avant le K&R.

J'aurais quand même tendance à croire Stroustrup, qui a tout mon respect, lorsqu'il dit que les concepts de Rust qu'on l'accuse d'avoir piqué, il les avait déjà en tête bien avant.

Et je suis content qu'il pointe le fait que Java qui initialement était vendu comme "simple" est en fait devenu un monstre, horriblement laid de surcroît.

[archqt]

Il n'a pas tord, sauf erreur la spécification de java est aussi grosse que celle du C++, alors que java se devait d'être plus "simple" au départ.

[laurentcpp]

Juste pour confirmer le post de Aurelien.Regat-Barrel,

>"C'est vrai que techniquement, tout ce qui est faisable en C++ est aussi faisable en C avec des performance identiques."

Non, c'est completement faux, Rust propose des concepts puissants tels que la notion de propriete (ownership) qui fait partie integrante du language alors que C++ l'implemente sous forme d'outils de la librairie standard (smart pointers)
C'est pourquoi Stroustrup affirme que ce qui est faisable en Rust l'est avec C++
Beaucoup de programmeurs C++ regardent avec interet (voir envie) Rust. Mais Rust a fait le choix de la table rase, alors que C++ celui de la compatibilite avec C (sans cela, C++ aurait pu etre comme Rust ou D, et il aurait eut le succes de Rust ou D).
Donc encore une fois, Stroustrup a probablement raison: il a surement pense a ces problemes il y a 40 ans, mais la compatiblite avec C l'a empeche d'integrer ces concepts / fonctionalites a l'epoque, c'est normal qu'il tacle gentillement les developpeurs de Rust et ca n'est pas une querelle de langages juste une mise au point (et je pense que c'est la partie la mois interressante a retenir de l'entretien)


L'analogie avec le C ne marche pas: les smart pointers sont implémentés grâce a RAII (ou maintenant appelé CADR (constructeur aquiere, destructeur relache))
On ne peut donc pas faire en C tout ce que l'on peut faire en C++ (il ne s'agit pas de critiquer C, mais de comprendre les différences)

> Le C++ c'est du C plus une couche POO
C'est vraiment une non-compréhension classique du C++: C++ n'est pas un langage de POO, c'est un langage multi-paradigmes qui permet entre autre de faire de la POO
La différence fondamentale entre C et C++, c'est RAII/CADR

> La méta programmation (Templates) est une couche rajoutée plus tard par d'autres programmeurs, ce qui complexifie la production de code.
Archi faux! Les templates ne sont pas la metaprogrammation, la meta-programmation est un sous ensemble de la programmation generique par template et a été "decouverte" par les utilisateurs plus qu'invente (Andrew Koenig, Alexandrescu et bien d'autres ont decouverts que les templates constituaient un langage a part entière (exécuté durant la compilation) et pouvait servir a autre chose qu’implémenter des containers & algorithmes a types paramétrables)

> La méta programmation l’énerve car elle n'est pas son oeuvre.
...vous etes serieux la?

Toutes mes excuses pour ne pas savoir comment citer correctement un autre post sur ce site.

[Uther]

Il n'a pas tord, sauf erreur la spécification de java est aussi grosse que celle du C++, alors que java se devait d'être plus "simple" au départ.

Je suis pas sur que le nombre de ligne de spec soit une métrique pertinente pour mesurer la complexité réelle d'un langage pour l'utilisateur final. Suivant la façon dont c'est rédigé et le niveau de précision des comportements ça peut-être trompeur. Je pense que le temps requis pour apprendre le langage ou le temps requis pour être efficace sont des métriques beaucoup plus pertinentes, et de ce point de vue là je trouve que le Java garde un net avantage sur le C++, même s'il se fait battre par des langages plus modernes comme le Go.
Je dirais que le langage Java, malgré ces évolutions reste relativement simple comparé a C++. Par contre la rigidité des conventions et l'écosystème de bibliothèques fait qu'il est en effet souvent trop surchargé.

L'analogie avec le C ne marche pas: les smart pointers sont implémentés grâce a RAII (ou maintenant appelé CADR (constructeur aquiere, destructeur relache))
On ne peut donc pas faire en C tout ce que l'on peut faire en C++ (il ne s'agit pas de critiquer C, mais de comprendre les différences)

Forcément toute analogie a ses limites, mais celle ci marche plutôt bien à condition de ne pas changer ce que l'on compare en cours de route.

Quand on regarde les capacités du programme final, comme semble le faire Bjarne Stroupstrup, il est vrai que les lifetimes où le contrôle du mouvement à la compilation offerts par Rust n'apportent théoriquement rien aux possibilités et aux performances du logiciel final comparé a un code C++ théorique parfaitement réalisé.
De ce point de vue ce que dit Bjarne Stroupstrup est vrai mais s'applique aussi au C++ car les smart pointers ne permettent au final de faire rien de plus que ce qui est théoriquement faisable en C en gérant les ressources manuellement et sans erreur.

Maintenant on peut aussi regarder du coté des fonctionnalités du langage comme vous le faites avec Aurelien.Regat-Barrel, ce que je trouve moi aussi plus intéressant car les conditions de production ont, en pratique, une incidence sur la qualité du produit final. De ce point de vue, c'est vrai que les smart pointers sont une fonctionnalité impossible en C.
Mais ce que dit Bjarne Stroupstrup n'est plus valable car on peut tout autant dire que la garantie mémoire apportée par les lifetime explicites et le contrôle de l'ownership, ou les macros hygiéniques, qui sont des choses impossibles en C++.

[frfancha]

Juste pour confirmer le post de Aurelien.Regat-Barrel,

>"C'est vrai que techniquement, tout ce qui est faisable en C++ est aussi faisable en C avec des performance identiques."

Non, c'est completement faux, Rust propose des concepts puissants tels que la notion de propriete (ownership) qui fait partie integrante du language alors que C++ l'implemente sous forme d'outils de la librairie standard (smart pointers)
C'est pourquoi Stroustrup affirme que ce qui est faisable en Rust l'est avec C++.

Comprends pas : tu dis complétement faux pour une phrase qui lie C et C++ mais ton explication parle de Rust vs C++

??

[walfrat]

Le Stroustrup, mon premier bouquin sur la programmation, avant le K&R.

J'aurais quand même tendance à croire Stroustrup, qui a tout mon respect, lorsqu'il dit que les concepts de Rust qu'on l'accuse d'avoir piqué, il les avait déjà en tête bien avant.

Et je suis content qu'il pointe le fait que Java qui initialement était vendu comme "simple" est en fait devenu un monstre, horriblement laid de surcroît.

Et puis franchement se "voler" des concepts entre langages c'est pas nouveau et si on cloisonnait les langages seulement aux concepts qu'ils ont pensé, on en aurait plus d'un qui sera dans un très mauvais état.

[Astraya]

le C++ peut fait absolument tout ce que l'assembleur fait et avec des performances similaires

Il va falloir m'expliquer pourquoi il y a 10 pouce rouge sur cette phrase.
On peux faire de l'ASM conjointement avec C++ (Rust souffre du même problème) donc ce qui est dit est vrai à partir du moment où l'on peut écrire de l'ASM directement dans le code. De plus il faut arrêter de confondre les performances de C++ et de la STL! Ça n'a rien à voir, à partir du moment où la STL est implémentée différement selon ce que vous utilisez comme implémentation.
Rust apporte beaucoup sur la détection à la compilation mais pas tout, j'entends parlé constamment de l'argument du ownership et borrowing mais elle a un gros inconvénient c'est la rapidité de prototypage.
Le C++ à des templates avec lesquels on peut bien plus que ce que propose les const de Rust ( Par contre leurs macros est très intéressante mais explosent le temps de compilation).
Rust est fort sur sa gestion des packages même si je trouve la communauté beaucoup trop tourné sur l'utilisation de package partout et j'ai l'impression d'être dans une communauté plus web que "bare metal", je met ça sur le manque de librairie mature et/ou propriétaire ouverte.
À côté C++ à visual studio qui est un outil extrêmement performant avec une capacité de debug très poussé, et quand je vois les efforts pour intégré les outils de LLVM je ne peux que applaudir.

[Uther]

Il va falloir m'expliquer pourquoi il y a 10 pouce rouge sur cette phrase.

Sans doute parce qu'elle a beau ne pas être fausse, lancé comme ça sans plus de détail, c'est juste hors sujet.

[koala01]

Salut,

Il va falloir m'expliquer pourquoi il y a 10 pouce rouge sur cette phrase.

Nous sommes bien d'accord que cette phrase n'est, en tous les cas, pas fausse.

Seulement, si tu te mets à la considérer comme juste et justifiée, il faut suivre le raisonnement jusqu'au bout, dans le sens où, si le C++ permet de faire tout ce que l'assembleur permet (ce qui est juste, à proprement parler) et, sans autre précision de la part de emilie77, on pourrait alors en arriver à la conclusion (hative, je te l'accorde sans problème) que C++ n'apporte strictement rien de plus que l'assembleur.

Et comme on peut faire valoir que tous les langages de faire tout ce que l'assembleur autorise, il n'y a pas un seul langage (en dehors de l'ASM lui-même) pour lequel on ne pourrait pas tirer une conclusion identique.

Arrivé à un tel point, on va vraiment finir par avoir un sérieux problème, car, du coup, il faudra se poser une question qui fâche réellement tout le monde qui est

Oui, mais, si l'ASM permet de tout faire, et si aucun langage n'apporte, au final, absolument rien par rapport à l'ASM, alors, pourquoi se faire ch...er à développer de nouveau langages

Or, le fait est que l'ASM a beau être un langage que l'on a beaucoup trop tendance (de mon point de vue du moins) à ignorer de plus en plus de nos jours, il n'en reste pas moins qu'il est totalement inadapté à une très grosse partie des défis que nous devons relever à l'heure actuelle.

De plus, je ne vais pas forcément parler des autres langages, mais je peux t'assurer que, pour ce qui est du C++ à tout le moins, il est parfaitement possible d'obtenir des performances similaires (si pas meilleures du fait des optimisations auxquelles nous n'aurions sans doute pas pensé par nous même) à celles que nous pourrions obtenir en ASM

J'ai vu, il y a quelques temps, la video d'un type qui reprogrammait le bon vieux pong qui se jouait sur attari du temps de ma jeunesse, et qui aurait parfaitement pu tenir sur une cartouche d'origine, avec des performances tout à fait similaires.

Si j'arrive à remettre la main sur cette video, j'en fournirai le lien