Selon vous, dans quel(s) cas devrait-on penser au c++ pour développer un nouveau projet ? N'existe-t-il pas dans la majorité des cas des solutions plus simples et plus efficaces ?
Conséquence 1 : pourquoi vouloir aujourd'hui apprendre le c++ (pour un jeune, un étudiant ou un débutant) ?
Conséquence 2 : Le c++ doit-il devenir (ou est-il destiné à devenir) un langage très marginal de super-experts pour créer des outils garantissant de hautes performances ? Outils qui seront ensuite utilisés par l'immense majorité des développeurs via des API, des scripts ou des langages plus simples… (Ces questions font volontairement abstraction de la question de la maintenance du code déjà existant dans beaucoup d'entreprises.) En bref le c++ a-t-il de l'avenir oui/non/pourquoi ?
Il faut déjà comprendre qu'un langage de programmation n'est -- comme n'importe quelle languge parlée (comme le francais, l'anglais ou le chinois) qu'un ensemble de conventions qui permettent à deux interlocuteurs de se comprendre, avec leurs propres règles et leur propres "philosophies"
La seule différence pour les langages de programmation, c'est que l'un des interlocuteurs est en fait "aussi bête qu'un ordinateur"
Ainsi, si tu penses à des langages comme java ou comme C# en tant que "solutions plus simples", il faut bien comprendre que, du point de vue de la syntaxe en tout cas, il n'y a absolument aucune différence avec le C++ (et donc avec le C) et pour cause: les développeurs ces langages se sont inspirés de la syntaxe du C++ lorsqu'ils ont décidé de celle du java ou du C#
En outre, il faut peut-être se mettre d'accord sur ce que tu appelles "plus efficace", car il n'y a rien que tu puisse faire en java ou en C# que tu ne puisse pas également faire en C++.
Alors, si tu parle de la rapidité de développement, je peux te garantir que; à situation de départ identique (ou "similaire", devrait on plutôt dire), je ne mettrai pas plus longtemps qu'un développeur java ou C# à obtenir un résultat identique
Par contre, si on parle de rapidité d'exécution et / ou d'efficacité énergétique, il se fait que C++ est sans doute largement plus efficace que java, C# ou python sur ces points
Enfin, il y a également des différences majeures entre java (ou C#) et C++. L'une des principale étant la "philosophie générale" abordée par les développeurs du langage.
Ainsi, le développeur de C++ s'est toujours basé sur le fait que celui qui l'utilisera sait ce qu'il fait, qu'il comprend les différents principes de conceptions (loi de déméter, SOLID) et de mise en oeuvre (comme le RAII), et qu'ile est donc capable de les appliquer.
On pourrait donc dire que les développeurs de C++ se basent sur le principe que "si c'est utile au langage, ca vaut la peine d'être ajouté au langage, même si cela peut s'avérer ''dangereux'' dans certaines circonstances".
A l'opposé, la philosophie générale suivie parles développeurs de java (et donc de C#, qui n'est que la réponse du berger (microsoft) à la bergère (sun) ) est l'utilisateur de leur langage serait un imbécile distrait, qui n'attendra que l'occasion de faire une connerie (de préférence au pire moment qui soit).
Ils vont donc partir du principe que "s'il y a le moindre risque, on va interdire une pratique, quitte à mettre des contournements en place et à mentir à l'utilisateur".
Ainsi, si on s'intéresse -- par exemple -- à l'héritage multiple (dans le respect du LSP), le point de vue de C++ est "c'est utile (bien que dangereux), donc, on va l'accepter tel quel et sans fioriture. A charge pour le développeur de savoir ce qu'il fait".
A l'inverse, le point de vue de java sur le sujet a été "c'est dangereux (ce qui est vrai), on va donc ''officiellement'' l'interdire (c'est ce que tout le monde te dira ), mais, comme on ne peut malgré tout pas s'en passer, on va créer 'artificiellement'' les notions de classe et d'interfaces, ainsi que les termes d'héritage et d’implémentation. Et on va mentir à l'utilisateur en lui disant que ces notions sont totalement différentes, alors que, du point de vue du LSP, c'est exactement pareil".
Après, il est vrai que C++ est parmi les langages les plus complexes que l'on puisse trouver: c'est l'un des seuls langages qui autorise à la fois la programmation impérative pure (les fonctions libres), la programmation orientée objets (avec les fonctions membres intégrées dans les classes / les structures) et la programmation générique (les template) et qui -- mieux encore -- a réussi à intégrer suffisamment les trois pour que l'on puisse les utiliser de manière simultanées.
Seulement, complexe ne veut pas dire difficile. Il n'y a rien de ** difficile ** à comprendre qu'une fonction proche de void foo(MaClasse const & cl) déclare une fonction nommée foo qui ne va rien renvoyer et qui accepte une référence (constante, dans le cas présent) vers une instance de la classe MaClasse qui sera identifiée (au niveau de la fonction ) par le terme cl, n'est ce pas ?
Alors, revenons en au premier point de ma réponse: qu'appelle-t-on "plus facile"?
Selon toi, qu'est ce qui est "plus facile" entre le fait de pouvoir déclarer une fonction void foo(MaClasse const & cl) et celui de devoir systématiquement intégrer une fonction similaire dans une classe en prenant soin de préciser qu'elle est statique afin qu'elle puisse être accessible sans forcément nous forcer à créer une instance de la classe dans laquelle elle se trouve afin d'y faire appel?
Umbre37 a écrit:
Conséquence 1 : pourquoi vouloir aujourd'hui apprendre le c++ (pour un jeune, un étudiant ou un débutant) ?
Oh, pour cela, on pourrait déjà dire que tu y trouverais un intérêt majeur par le simple fait qu'il t'oblige à réfléchir par toi-même: si tu veux pouvoir développer en C++, tu dois comprendre ce que tu fais, et, dans l'idéal, être capable de le justifier.
Cela te fera sortir de ta zone de confort, et cela t'obligera donc à t'intéresser aux principes de base alors que tu n'y penserais sans doute pas forcément en apprenant un autre langage
De plus, le fait de prendre l'habitude de te poser un certain nombre de questions "conceptuelles" pour pouvoir développer "correctement" en C++ ne peut que te simplifier énormément la vie dans les autres langages similaires.
En effet, si tu te pose -- dans une situation similaire -- les mêmes questions, que tu y apporte les mêmes réponses (et que tu peux les justifier) dans un autre langage, ton développement ne pourra être que bien meilleur.
On va faire simple: un développeur C++ "moyen" pourra très facilement devenir un très bon développeur dans n'importe quel autre langage. A l'inverse, même un très bon (ou excellent) développeur java ou C# risque de n'être qu'un développeur C++ "médiocre" à "tout juste passable"
Il faudra donc beaucoup plus de temps pour former un développeur C++ à partir d'un développeur java (ou C#) qu'il n'en faudra pour former un développeur java (ou C#) à partir d'un développeur C++
Umbre37 a écrit:
Conséquence 2 : Le c++ doit-il devenir (ou est-il destiné à devenir) un langage très marginal de super-experts pour créer des outils garantissant de hautes performances ? Outils qui seront ensuite utilisés par l'immense majorité des développeurs via des API, des scripts ou des langages plus simples…
Comme je te l'ai dit plus haut, il n'y a rien que tu puisse faire en java ou en C# que tu ne pourrais pas faire avec la même facilité en C++.
Si donc, on demandais son avis à l'ensemble de la communauté mondiale des développeurs, nous pourrions faire ressortir quatre réponses type:
pour ceux qui ne veulent pas entendre parler de C++; qui y sont allergiques: "C++ pourrait tout aussi bien disparaitre purement et simplement, je ne m'en porterais que mieux"
pour ceux qui ont besoin de performances avant tout: "si je ne peux pas le faire en C++, il faudra prévoir des batteries supplémentaires"
pour ceux qui ont besoin d'être "près de la machine" : "et tu vas faire comment pour que le BIOS lance ta machine virtuelle java?"
pour ceux qui feraient tout et n'importe quoi en C++ : "retire moi C++, je me fais facteur ou fermier".
Bien sur, c'est quelque peu caricatural. Je crois que cela donne malgré tout une idée assez précise des choix principaux
Umbre37 a écrit:
En bref le c++ a-t-il de l'avenir oui/non/pourquoi ?
Bien sur que C++ a un avenir... Comme n'importe quelle technologie éprouvée
Sais tu que le principe utilisé pour produire l'électricité à ta maison est -- somme toutes -- (hormis l'électricité solaire) le même que celui qui a permis d'allumer la première lampe électrique il y a plus de cent ans? On a trouvé d'autres moyens permettant de mettre ce principe en oeuvre, le générateur est sans doute devenu plus efficace (moins de pertes), et il est sans doute actionné de manière différente, mais le principe n'a absolument pas changé
De même, les raisons pour lesquelles C++ a été développé et les principes sur lesquels se basent le langage sont toujours d'actualité et ne vont sans doute pas changer avant "bien longtemps". Il n'y a donc absolument aucune raison pour que C++ (qui continue à évoluer régulièrement, surtout depuis 2011) cesse d'exister
Enfin, il doit y avoir des milliards de lignes de code écrites en C++ de par le monde. Et, si certaines appartiennent à des projets oubliés depuis longtemps, une bonne partie appartient surtout à des projets encore utilisés, voire, même, en développement actif.
Il serait totalement illusoire d'espérer pouvoir traduire tout ce code dans un autre langage
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Merci beaucoup pour cette longue et très belle réponse. Je me reconnais bien dans ton passage sur "les raisons pour un débutant de choisir le c++", c'est exactement ce qui a motivé mon choix quand j'ai voulu apprendre un langage il y a quelques années déjà.
Le point clef de ta réponse, si j'ai bien compris, c'est qu'il n'est pas plus long/difficile de développer un projet en c++ que dans un autre langage. Je suis persuadé que tu as raison ! À condition de ne pas prendre en compte le temps de formation préalable qui est nécessairement plus (voire beaucoup plus) long en c++.
Mais comme la culture va dans le sens du "tout tout de suite", et du maximum de productivité, est-ce qu'à terme les personnes souhaitant "réfléchir par elles-même", "comprendre ce qu'elles font", "sortir de leur zone de confort", pour te citer, ne risquent pas d'être de moins en moins nombreuses ?
D'ailleurs, il me semble qu'existent de plus en plus de solutions de haut niveau pour réaliser toutes sortes de choses. Tu me répondras certainement qu'on peut utiliser ces solutions en c++. Oui, mais la complexité de la syntaxe du c++ se justifie moins dans un contexte de haut niveau me semble-t-il. Car il y a tout de même des différences entre les langages dans la simplicité de mise en œuvre, ne serait-ce qu'à cause de la contrainte d'avoir à compiler, ou à séparer déclarations et définitions par exemple. Ou même dans la syntaxe. Un petit exemple tiré d'internet :
Je pensais aussi au choix de l'éducation nationale (en France je veux dire) de mettre le paquet sur Python… C'est certainement une bonne idée, mais cela signifie que toute une génération d'écoliers sera biberonnée au Python et rien d'autre (dès le collège je crois). Ce qui n'est pas neutre en terme de "philosophie de programmation" si j'ose dire. Pensez-vous que cela puisse avoir un impact ?
Enfin voilà, suite à ces quelques réflexions, je me demandais si l'intérêt pour le c++ ne risquait pas d'avoir tendance à décliner pour les nouvelles générations, en France du moins (si quelqu'un a des chiffres cela m'intéresse). Et avec cela, le nombre de nouveaux projets utilisant le c++. (Je ne parle pas des projets et des personnes qui utilisent le c++ depuis longtemps et qui continuent bien sûr de l'utiliser).
Il faut voir que le C++ est aussi en constante évolution, Beaucoup de syntaxe se son ajoutés pour simplifier le langage. Par exemple, la séparation déclarations et définitions dont tu parles (qui n'est pas obligatoire) devient inutile avec les modules de C++20.
Mais il est vrai que le langage est plus complexe et demande généralement plus de réflexion. En réalité, le système de type et les lifetimes force cette réflexion qui est entièrement gommé dans python par le GC et le typage dynamique de python. Ce dernier pouvant néanmoins amener à de grosse incohérence et pas mal de bug.
Sur l'aspect simplicité, le choix de l'éducation national d'enseigner python n'est pas une mauvaise chose. C'est plus simple à utiliser, la bibliothèque standard est très fournie (à côté, celle de C++ est ridicule). Après, c'est surtout une initiation à la programmation, comprendre les principes de base, la notion de boucle, variable, etc et sur l'aspect logique de programmation, des langages graphiques comme scratch font aussi bien.
Du coup, les gens se tournent vers C++ principalement parce qu'il apprécie le langage et sa philosophie ou parce qu'il y a besoin d'un certain niveau de performance que les autres langages ne permettent pas. Et il y a toujours des projets qui demandent d'être très performants (ressource utilisée, vitesse d'exécution, etc). On peut même se retrouver sur des systèmes restreint où il n'y a pas le choix (embarqué, arduino, etc).
> Après, il est vrai que C++ est parmi les langages les plus complexes que l'on puisse trouver: c'est l'un des seuls langages qui autorise à la fois la programmation impérative pure (les fonctions libres), la programmation orientée objets (avec les fonctions membres intégrées dans les classes / les structures) et la programmation générique (les template) et qui -- mieux encore -- a réussi à intégrer suffisamment les trois pour que l'on puisse les utiliser de manière simultanées.
Ce n'est pas le seul, les langages à typage dynamique sont automatiquement "génériques" et la plupart supportent les fonctions libres et classe: php, python, lua, js, ts pour ne cité qu'eux.
Si je prend un langage proche de C++, on y trouve forcément Rust. Il propose la même chose en mieux (l'OO à base de classe ne respecte pas le principe Open/Close (héritage vs trait)).
Jusqu'à récemment, C et C++ étant les seuls langages qui pouvaient prétendre pouvoir offrir de très bonne performance. Mais depuis quelques années, on peut voir d'autre langage qui permettent plus ou moins la même chose avec leur propre philosophie et manière de faire. C'est le cas de Rust qui se veut aussi plus safe en réduisant ou supprimant des catégories de bug. Mais il y a plein d'autres langages: Nim, Julia, etc qui possèdent leur propre domaine d'expertise. À la longue, pas mal de projet qui aurait été fait en C++ seront fait dans un autre langage. Mais il y aura toujours de nouveau projet C++ et toujours du code à maintenir.
A mon sens, certaines affirmations de koala sont discutables, sur le temps d'apprentissage, les qualités qu'a un dev C++, etc.
Ca dépend trop du niveau attendu, de la courbe de progression d'apprentissage, des besoins, etc.
Umbre37 a écrit:
c'est qu'il n'est pas plus long/difficile de développer un projet en c++ que dans un autre langage.
Ca depend du type de projet. Certains langages vont permettre d'être plus efficace que le C++ sur certains projets. Et pour d'autres projets, ça sera l'inverse.
Par exemple, si tu veux faire une app avec UI simple, tu seras probablement aussi rapide avec C++ et Qt qu'avec d'autres langages. Si tu veux faire des threads, certains langages vont proposer des modèles de prog concurrente plus efficace qu'en C++. Si tu veux écrire un DSL avec 0 surtout, les templates C++ seront très puissants.
Les besoins sont trop divers pour dire qu'un langage est toujours ou jamais bon.
Umbre37 a écrit:
À condition de ne pas prendre en compte le temps de formation préalable qui est nécessairement plus (voire beaucoup plus) long en c++.
Mouais, bof.
Le temps d'apprentissage de la syntaxe de base en C++ ou un autre langage n'est pas critique. Passer 1 mois ou 2 mois, ca n'est pas critique sur le temps de formation des devs. Et si on veut devenir expert, ca prend des années, quelque soit le langage.
Umbre37 a écrit:
Mais comme la culture va dans le sens du "tout tout de suite", et du maximum de productivité, est-ce qu'à terme les personnes souhaitant "réfléchir par elles-même", "comprendre ce qu'elles font", "sortir de leur zone de confort", pour te citer, ne risquent pas d'être de moins en moins nombreuses ?
En termes de nombres de personnes, non. En termes de pourcentage, oui.
Les besoins en info se développent tous les ans, avec de nouvelles technologies, des nouveaux outils, des nouveaux besoins utilisateurs. Et donc de plus en plus de personne qui bossent là dedans. Aussi bien des devs avec une faible qualification (bac, formation courte) pour faire le boulot de routine simple que des chercheurs de très haut niveau, avec tous les niveaux intermédiaires.
Et comme pour tous les domaines, il faudra toujours plus de dev peu qualifiés que de techniciens. Plus de techniciens que d'ingénieur. Plus d'ingénieurs que de chercheurs.
Donc que tu as l'impression que la direction va vers le "tout tout de suite", ce n'est pas étonnant, vu que c'est une partie importante des besoins des entreprises et donc des boulots proposés. Mais ca ne veut pas dire pour autant qu'il y a une diminution des demandes en personnes qualifiées.
Umbre37 a écrit:
D'ailleurs, il me semble qu'existent de plus en plus de solutions de haut niveau pour réaliser toutes sortes de choses. Tu me répondras certainement qu'on peut utiliser ces solutions en c++. Oui, mais la complexité de la syntaxe du c++ se justifie moins dans un contexte de haut niveau me semble-t-il.
Et d'où viennent ces solutions "hauts niveaux" ? De devs qui écrivent les solutions haut niveau en faisant du "bas niveau".
C'est juste un effet loupe. Avant, tu avais 10 devs qui bossent sur des apps "bas niveau". Maintenant, tu as 10 devs qui vont bosser en "bas niveau" sur des frameworks "haut niveau" et 100 devs qui vont utiliser des framework "haut niveau" pour faire des apps.
Umbre37 a écrit:
Car il y a tout de même des différences entre les langages dans la simplicité de mise en œuvre, ne serait-ce qu'à cause de la contrainte d'avoir à compiler, ou à séparer déclarations et définitions par exemple. Ou même dans la syntaxe.
Une stack pour dev une app, c'est complexe de base. Il y a même une spécialisation possible dans le dev pour s'occuper de ca (les dev ops). La compilation n'est qu'une étape parmis beaucoup (gestion des version du code, organisation des fichiers, conception, tests auto, la doc, analyseurs statiques et dynamiques, deploiement, etc).
Une stack pro pour dev une app C++ ne sera pas forcément plus complexe que pour d'autres langages. Après, il est évident que si tu bosses sur un projet sans tests, sans déploiement, sans analyseurs, etc. la stack sera plus simple. Mais c'est une question de choix de dev de l'app, pas du langage.
Et la séparation déclaration et définitions n'est pas du tout obligatoire en C++. Tu peux tout mettre dans un .h (ca se fait pour le code full template ou les libs header-only, comme boost). C'est un choix de dev de faire une telle séparation, parce que cela apporte des avantages. C'est pas une contrainte, c'est un bénéfice (A lire : Lakos, "Large Scale C++"). Au point même où il est classique de voir de genre de séparation dans les langages qui ne sont pas pensés a l'origine comme ca (par exemple Java).
La verbosité (= la quantité de code qu'il faut écrire pour faire quelque chose) est, a mon sens, un critère surestimé. On lit plus souvent du code qu'on en écrit. La productivité moyenne d'un dev (ca va dépendre du type de boulot qu'il fait), ca va être probablement autour de quelques lignes ou centaines de lignes par jour.
Dit autrement, on s'en fout qu'il faut 2 lignes en Python et 10 en C++. L'impact de la verbosité sur le temps de dev global d'une app, c'est accessoire.
Umbre37 a écrit:
Ce qui n'est pas neutre en terme de "philosophie de programmation" si j'ose dire. Pensez-vous que cela puisse avoir un impact ?
C'est pas un choix pire que n'importe quel autre. Beaucoup de formations commencent par le C, qui est un mauvais choix aussi. Ou pas, ça dépend comment c'est présenté. J'ai commencé, pour tester, la formation CS50 d'introduction a la programmation de Harvard (sur edX en ligne). Ils commencent par Scratch puis le C puis Python. Et pédagogiquement, je n'ai rien a reprocher (ils parlent dès le début de qualité du code, de debug et de valgrind). C'est pas une formation de quelques jours ou semaines qui va donner "une philosophie de programmation".
Au pire, ce qu'on pourrait reprocher, c'est que c'est pas des personnes compétentes en programmation qui enseignent Ce qui n'est pas trop un problème au collège et lycée. Et ça fait des dizaines d'années qu'il y a aussi des profs au niveau post bac, qui sont peu compétents dans ce qu'ils enseignent. Voire, certaines "formations" n'ont pas de prof.
Donc disons que ce n'est pas idéal, mais c'est pas catastrophique.
Umbre37 a écrit:
Enfin voilà, suite à ces quelques réflexions, je me demandais si l'intérêt pour le c++ ne risquait pas d'avoir tendance à décliner pour les nouvelles générations, en France du moins (si quelqu'un a des chiffres cela m'intéresse). Et avec cela, le nombre de nouveaux projets utilisant le c++. (Je ne parle pas des projets et des personnes qui utilisent le c++ depuis longtemps et qui continuent bien sûr de l'utiliser).
En france, on a pas mal de retard. L'immobilisme de la fonction publique. (A mon sens). Au niveau international, je dirais qu'il y a un regain d'intérêt pour le C++ (depuis le C++11), parce que plus facile à apprendre et à utiliser. Et que l'on voit à force les limites des autres langages mainstream (par exemple C# a compris que se limiter a Window était très handicapant) et l'absence de nouveaux langages émergent qui pourraient remplacer les anciens langages mainstream (ca fait 20 ans qu'on annonce des langages qui vont mettre au placard le C++, C# et Java).
La tendance est plus vers des apps hybrides, écrites avec plusieurs langages.
Le point clef de ta réponse, si j'ai bien compris, c'est qu'il n'est pas plus long/difficile de développer un projet en c++ que dans un autre langage. Je suis persuadé que tu as raison ! À condition de ne pas prendre en compte le temps de formation préalable qui est nécessairement plus (voire beaucoup plus) long en c++.
Meme pas! Il n'est pas plus long / difficile de développer en C++ qu'en tout autre langage POINT. Car il n'est pas plus long de se former au C++ qu'à n'importe quel autre langage
Du moins, à la condition que le formateur t'apprenne correctement le C++, en respectant un ordre d'apprentissage cohérent avec le langage, au lieu d'essayer d'adapter ce qu'il a l'habitude de faire en C
Le seul point qui pourrait éventuellement demander un peu plus longtemps, c'est la compréhension et l'utilisation des principes de conception (loi de Déméter, principes SOLID, etc) car c'est un point qui est, si pas complètement zappé dans de nombreux cours (que ce soit en C++ ou en n'importe quel autre langage), à tout le moins "vachement bâclé"
Or, il est vrai que tu as peut-être vachement intérêt à te sentir à l'aise sur ce point
Umbre37 a écrit:
Mais comme la culture va dans le sens du "tout tout de suite", et du maximum de productivité, est-ce qu'à terme les personnes souhaitant "réfléchir par elles-même", "comprendre ce qu'elles font", "sortir de leur zone de confort", pour te citer, ne risquent pas d'être de moins en moins nombreuses ?
J'espère bien que non...
Si, un jour, je dois rentrer dans une voiture qui n'a même plus de volant ni de pédales pour la diriger, j'espère bien que le programme qui la fait fonctionner aura été développer par des gens qui savent un minimum ce qu'il font, qu'en penses tu ?
De plus, il faut bien comprendre que l'on perd au final beaucoup moins de temps à prendre "quelques minutes de réflexion" AVANT de faire les choses, alors que la page est "blanche", afin de faire les choses correctement (ce qui ne prendra de toutes facons pas plus de temps que de les faire "à la va comme je te pousse") que de commence à devoir corriger toute la conception parce que le niveau de la dette technique nous empêche de rajouter un truc tout à fait secondaire
Le développement informatique pourrait se comparer au processus de création d'une nouvelle maison: si les plans sont bons et on été effectués avec sérieux, la maison pourra être bâtie et on pourra être sur qu'elle ne risque pas de s'effondrer au premier coup de vent.
Eh bien les plans de l'architecte, c'est la conception du développement informatique. Tout comme les plans doivent s'appuyer sur des études de sol et sur la résistance des matériaux qui seront utilisé, la conception doiit s'appuyer sur des principes pour lesquels aucune dérogation ne devrait être acceptée; a moins qu'elle ne soit vraiment très bien justifiée
Umbre37 a écrit:
D'ailleurs, il me semble qu'existent de plus en plus de solutions de haut niveau pour réaliser toutes sortes de choses. Tu me répondras certainement qu'on peut utiliser ces solutions en c++. Oui, mais la complexité de la syntaxe du c++ se justifie moins dans un contexte de haut niveau me semble-t-il.
Donc, en gros, tu essaye de m'expliquer qu'il n'y a pas forcément besoin de rouler en ferrari F40 sur les routes françaises, qu'une voiture qui serait deux fois moins chère, deux fois moins lourde et deux fois moins rapide pourrait parfaitement faire l'affaire dans de nombreuses situations
Il va de soi que je suis tout à fait d'accord avec toi sur ce point et que je n'obligerai jamais personne à choisir C++ pour développer un de ses projets si python (ou n'importe quel autre langage) lui permet d'obtenir un résultat correct
Seulement
Umbre37 a écrit:
Oui, mais la complexité de la syntaxe du c++ se justifie moins dans un contexte de haut niveau me semble-t-il.
Je suis tout à fait d'accord... à la condition que ton projet se cantonne réellement au "haut niveau". Car, dés le moment où il aura besoin de se rapprocher ne serait-ce qu'un tout petit peu du système, tu risques d'avoir quelques problèmes
Or, tu n'imagines pas le nombre de situations où le "haut niveau" ne peut exister que parce qu'il "lance des ancres" dans le "bas niveau".
Et puis,
Umbre37 a écrit:
Car il y a tout de même des différences entre les langages dans la simplicité de mise en œuvre, ne serait-ce qu'à cause de la contrainte d'avoir à compiler,
il faut bien te dire que ce que tu appelle "contrainte" est en réalité souvent une nécessité à cause du matériel sur lequel ton programme est destiné à fonctionner: il n'y a -- tout simplement -- ni la place pour y faire tourner une machine virtuelle ni les ressources matérielles pour garantir un fonctionnement correct et suffisamment performant au travers de cette machine virtuelle.
Alors, je comprend parfaitement ton point de vue: tu es jeune, tu t'intéresse à l'informatique, tu préfères -- de toutes évidences -- python (choix que je respecte, à défaut de le partager), voire java, et tu vois que ton ordinateur, ton portable, voir ta tablette ou ton smartphone sont parfaitement capables de les utiliser.
Et, du coup, sans réfléchir beaucoup plus loin, tu te dis qu'il du coup n'y a pas vraiment besoin de C ou de C++.
Oui, mais, sais tu que la machine virtuelle de python et celle de java ont été développées en C et en C++?
Sais tu que la machine virtuelle ne fonctionne que parce qu'elle est concue pour pouvoir tourner sous (choisi le nom que tu préfère) windows, linux, android et ios?
Sais tu que ces systèmes d'exploitation ne pourraient tout simplement pas fonctionner sur la machine virtuelle offerte par ces langages, vu vu que leur rôle est, justement, de fournir un tas de ressources (mémoire, processeur, accès disques et autres) au programme de la machine virtuelle?
Sais tu que pour arriver jusqu'au système d'exploitation, il faut partir du BIOS (un programme qui se lance lorsque le courant arrive jusqu'au processeur), que ce BIOS ne peut donc pas nécessiter de machine virtuelle, vu que le système d'exploitation n'est même pas encore lancé?
Sais tu que le BIOS devra aller chercher des informations à un endroit bien précis d'un disque dur afin d'exécuter ce que l'on appelle le "boot loader"; qui ne peut pas d'avantage fonctionner sur une machine virtuelle que le BIOS et que c'est ce bootloader qui permettra enfin de lancer le système d'exploitation souhaité?
Tu demandais, dans ta première question, à quoi sert ou servira le C++. Voici dores et quatre éléments de réponse pour ainsi dire incontournable:
le développement d'autres langages de programmation
la création de systèmes d'exploitation, nécessaire à l'utilisation de ces "nouveaux langages de programmation"
la création de bootloader, nécessaires à l'utilisation du système d'exploitation
le BIOS des ordinateurs, pour lancer le bootloader.
Ces quatre éléments se retrouve systématiquement sur les PC, portables et autres tablettes/smartphone; et je ne me suis même pas encore intéressé aux systèmes qui vont permettre à l'ABS ou aux airbags de fonctionner, voire, qui vont permettre à un mars explorer quelconque d'atterrir après six mois de voyage dans le vide de l'espace, ni à tous ces systèmes -- de plus en plus nombreux -- sur lesquels l'importance de l'informatique est grandissante alors qu'elle dispose de moins en moins de place
Umbre37 a écrit:
Bonjour Koala01,
Je pensais aussi au choix de l'éducation nationale (en France je veux dire) de mettre le paquet sur Python… C'est certainement une bonne idée, mais cela signifie que toute une génération d'écoliers sera biberonnée au Python et rien d'autre (dès le collège je crois). Ce qui n'est pas neutre en terme de "philosophie de programmation" si j'ose dire. Pensez-vous que cela puisse avoir un impact ?
Alors, là, je crois qu'il faut scinder la question en deux car il faudra
d'une part, s'intéresser à la décision "gouvernementale" de fournir -- fusse de manière "simplifiée" une base en développement infomratique et
d'autre part à la manière dont cet apprentissage est concrètement mis en oeuvre par les différents profs qui ont cela dans leurs attributions.
Je crois, en effet qu'il ne peut être que bénéfique pour tout le monde d'avoir une "initiation" au développement ne serait-ce que parce que c'est le moment idéal pour initier les gens à la logique et au rasoir d'ockham (au fait de découper des problèmes complexes en plusieurs problèmes plus simples à résoudre).
Je crois sincèrement que peu importe le langage (même si je n'ai jamais caché que python n'est pas mon langage préféré) si les gens arrivent déjà à comprendre que n'importe quel programme n'est jamais qu'un ensemble de données, d'instructions, de conditions et de boucles effectuées dans un ordre particulier, logique et cohérent (une recette de cuisine, en sommes )
Par contre, je crois que le vrai impact, celui qui fera le plus de bien ou de mal à l'étudiant, ce sera celui du prof qui lui donne cours.
Car le véritable problème, c'est qu'on va trouver de tout: on va trouver des profs qui se seront correctement formés au langage qu'ils tentent d'apprendre à leurs élèves, voir, qui le pratiqueront de manière régulière et même suivront (peut-être) son évolution et, à l'opposé, on peut tout aussi bien trouver un prof quelconque (de math, par exemple) qui n'a aucun gout pour le langage qu'il doit enseigner (qui n'a d'ailleurs aucun gout pour le développement informatique) et qui ne l'enseignera que parce qu'on lui aura dit "écoute, tu es le seul disponible / le dernier arrivé / celui dont la spécialisation s'en rapproche le plus, c'est donc à toi de jouer".
On peut donc espérer que les premiers vont fournir une formation vraiment enrichissante et "de qualité" à leurs étudiants et, pourquoi pas, qu'ils leur fassent comprendre ce que j'expliquais dans ma première intervention: un langage de programmation n'est qu'un ensemble de convention permettant à deux interlocuteurs de se comprendre.
Est ce que le fait que les élèves aient étudié python et non C++ aura un impact? Pas plus que le fait d'avoir mangé de la confiture au fraises (python) au petit déjeuner ne t'auras empêché un jour de gouter la confiture aux cerise (C++)
Tu aimeras, ou tu n'aimeras pas, pour des raisons qui te seront forcément personnelles. Si tu aimes, tant mieux. Si tu n'aimes pas, tant pis.
Par contre, la deuxième sorte de profs que j'ai envisagée (et qui est clairement caricaturale, il faut l'admettre) va clairement avoir un impact négatif. Ne serait-ce que parce qu'il y a de grandes chances qu'ils dégoutent purement et simplement leurs élèves du développement informatique.
Et pourtant, je préfèrerais de très loin -- en tant qu'intervenant régulier sur un forum dédié au C++ -- que ces profs donnent un mauvais cours de python qu'un mauvais cours de C++.
Pour les élèves d'abord. Car je crois sincèrement que, même avec un mauvais cours de python, les élèves gardent quand même de bonnes chances d'obtenir quelque chose de "raisonnablement correct", et donc, d'obtenir leur notes, alors qu'un mauvais cours de C++ pourrait aller jusqu'à les placer dans une situation dans laquelle ils ne pourront même plus obtenir quelque chose de potable
Et pour les intervenants sur ce forum (dont je fais partie, bien sur) ensuite. Car tu n'imagines pas l'énergie que cela peut demander pour arriver à faire comprendre à quelqu'un qu'il doit oublier tout ce qu'il a appris et repartir sur des bases saines, voire de lui faire comprendre qu'il a pris de très mauvaises habitudes et qu'il va absolument devoir les abandonner.
jo_link_noir a écrit:
ICe n'est pas le seul, les langages à typage dynamique sont automatiquement "génériques" et la plupart supportent les fonctions libres et classe: php, python, lua, js, ts pour ne cité qu'eux.
C'est bien pour cela que j'ai dit "parmis les langages les plus complexes" et "l'un des seuls" (même si il y en a en fait plus que l'on pourrait croire :D)
jo_link_noir a écrit:
(l'OO à base de classe ne respecte pas le principe Open/Close (héritage vs trait)).
Humm... je ne vais certainement pas craché sur les traits et les politiques (qui vont souvent de pair).
Par contre, je crois qu'il faudrait vraiment que l'on aie une discussion pour se mettre d'accord sur ce que l'on entend par les termes OO et "open /close". Cette discussion n'étant peut-être pas le meilleur endroit
Car, si j'admets que la mise en oeuvre "classique" de l'OO ne pousse pas "particulièrement fort" au respect de l'open close, entre autres à cause de cette accessibilité protected qui accepte "tout et n'importe quoi", je crois pour ma part que l'open close est "globalement bien respecté" ou, du moins, qu'il y a moyen de le respecter de manière particulièrement correcte, jusque et y compris la notion de polymorphisme (par inclusion, dans le cas présent).
Cependant, de nombreux arguments risquent d'être échangés d'un coté comme de l'autre sur ce point, et, bien que je sois persuadé que la discussion serait profitable (au moins pour moi ), je propose qu'on l'aie "ailleurs" pour ne pas perdre notre ami Umbre en cours de route
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
> Tu demandais, dans ta première question, à quoi sert ou servira le C++. Voici dores et quatre éléments de réponse pour ainsi dire incontournable:
>
> le développement d'autres langages de programmation
> la création de systèmes d'exploitation, nécessaire à l'utilisation de ces "nouveaux langages de programmation"
> la création de bootloader, nécessaires à l'utilisation du système d'exploitation
> le BIOS des ordinateurs, pour lancer le bootloader.
Ces points sont de moins en moins vrais. Par exemple, il y a des outils beaucoup plus simples pour écrire un nouveau langage et pas mal de langage mature son écrit eux-mêmes dans le langage qu'ils compilent/interprètent. Et on trouve plein d'exemple:
Rust écrit à l'origine en OCaml puis en Rust (les langages fonctionnels sont pas mal appréciés pour dans ce domaine).
WebGPU dont une implémentation est entièrement en rust (c'est une api et un langage).
Nim initialement écrit en Pascal puis en Nim.
Pypy, un interpréteur python en python.
Etc
Tu peux me rétorquer que si on regarde les lib ou implémentation des langages utilisés, on tombe sur du C/C++. Certes, mais je pourrais aussi dire que les compilateurs C et C++ ont d'abord était fait en assembleur, est-ce pour autant qu'il faudrait promouvoir un assembleur ? Non, on va rester sur du haut niveau (du point de vue de l'asm, C et C++ ont un haut niveau d'abstraction).
La création d'OS, bootloader et BIOS n'ont pas réellement besoin de C ou C++, on peut en trouver dans différents langages. Le plus important étant surtout un moyen d'écrire de l'assembleur, car pour certaines parties il n'y a pas le choix. D'ailleurs, pour parler OS, Linux autorise maintenant certain bout en Rust. Mais on commence à être dans du domaine très spécifique, c'est une toute petite minorité de projet.
En réalité ce qui fait qu'on utilise du C ou du C++ est tout l'outillage disponible derrière et les paquets d'années qui on permit de le roder (notamment ceux liés à la preuve de programme où le C est très bien équipé, mais Ksass Peuk pourra mieux en parler). Sauf que depuis qu'on a LLVM, les nouveaux processeurs peuvent implémenter plus facile un compilateur C++ (c'est principalement associer des instructions à l'IR de LLVM) et si finalement ce n'est que ça, on pourrait brancher n'importe quel frontend qui pond une IR LLVM (et il y en a un paquet).
Mais les nouveaux langages qui pourraient détrôner C++ n'ont pas un écosystème aussi riche, ils sont trop jeunes. Pendant un temps, le choix en sera un par défaut, mais cela devrait être de moins en moins vrai au fils du temps. Viens aussi le fait que les personnes expérimentées dans un langage n'ont pas forcément envie de recommencer presque à zéro dans un autre et une personne peu expérimentée n'aura pas forcément envie de voir ce qui se fait ailleurs. Il y a toute un aspect psychologique où même s'il y a mieux sur tous les tableaux le choix sera C++.
Mais il y aura toujours plus de dév python, parce que c'est plus simple, parce qu'il y a plus de chose par défaut, parce qu'ils ont simplement commencés avec. Et à côté on aura toujours besoin de performance pour des morceaux critique, ce que python ne permet pas. Le choix du langage est toujours un ensemble de compromis et C++ rentre encore dans les cases.
> Humm... je ne vais certainement pas craché sur les traits et les politiques (qui vont souvent de pair).
J'ai hésité à le préciser, mais les traits de rust n'ont rien à voir avec ceux de c++.
En gros, un trait est une interface que les struct vont implémenter. Une personne qui crée une struct peut implémenter n'importe quel trait. Une personne qui crée un trait peut faire en sorte que n'importe quelle struct implémente son trait ou que son trait est implémenté à partir du moment où tel ou tel trait est implémenté ; là où en C++ une nouvelle interface ne peut pas être implémentée par une classe existante.
Au final cela permet pas mal de souplesse et facilite la création de petit trait (à la manière des concepts de c++20, même si les concepts sont plutôt un sous-ensemble des traits rust).
Si tu veux en discuter plus, je t'invite à faire un nouveau sujet
Bon en fait, l'utilisation des langages évolue vers des niches, où ils sont adaptés soit par leurs points forts particuliers, soit par l'inertie liée au poids (la masse, pardon) de l'existant, tant pour le code, les plateformes, que pour la formation des personnels (allez convaincre un programmeur de changer de langage après 30 ans d'usage du même).
Merci beaucoup à tous pour ces réponses variées, très complètes et instructives ! Je vois qu'il ya pas mal de divergences entre vous. Normal ! l'avenir n'est pas une science exacte Tout cela m'a donné amplement matière à réfléchir. Bonne soirée !
En fait, ce qu'il faut surtout retenir de tous ces points de vue, c'est que, au pire, C++ deviendra un "langage de niche", comme tant d'autres langages avant lui, mais que, quoi qu'il arrive, il continuera d'exister pendant encore longtemps... Même après que tu aies atteint l'age de la pension
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
À quoi sert (ou servira) le c++ ?
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Discord NaN. Mon site.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html