Discussion :

[marc.collin]

Productif certes car on en a fait des langages au niveau du Visual Basic en simplifiant tout ce qui etait jugé "complexe".
La seule chose pour laquelle je suis d'accord avec toi c'est que le GC est la plus grosse abomination (pour simplifier le boulot des devs faineants qui ne savent pas maitriser un malloc/free).
Pour le reste si tu fais que des applis de gestion effectivement tu peux considerer que le C# est suffisant.
Par contre des que tu fais des applis embarquées necessairement le C/C++ s'impose naturellement. On le vit tous les jours dans ma boite. Le seul endroit ou on a mis du C# c'est sur l'IHM; tout le reste on a laissé tombé car trop lent (c'est tout relatif mais sur un equipement qui doit repondre a tout moment en quelques millisecondes le C# peche).

Ce que je constate dans ma boite c'est que c'est facile de sous traiter en offshore (inde) tous les devpts Serveur/frontend mais tout ce qui touche a l'embarqué c'est beaucoup plus difficile. Du coup ca reste chez nous. Aujourd'hui pour faire du devpt standard (appli gestion) sur PC, c'est a la portee de n'importe qui (meme les debutants en informatique puisqu'ils ont l'impression d'etre les rois du monde en ne maitrisant pourtant pas grand chose).
Quand je vois le niveau des devs C# (je viens du ASM/C/C++ a la base), ca en est risible quand je vois le niveau de comprehension de ce qu'il font.
Heureusement pour nous ces devpts sont de plus en plus sous traités en offshore car ont tres peu de valeur ajouté face a des devps C/C++ qui sont proches du hardware et sont necessairement obligé de comprendre ce qu'ils font (programmation avec fortes contraintes perf/optimisation etc cad tout le contraire de ce que je vois usr les nouveaux devpt C#).

pour la sous-traitance en embarqué c'est en chine que ça se passe

[kilroyFR]

pour la sous-traitance en embarqué c'est en chine que ça se passe

peut etre pour toi mais pour nous depuis 5 ans les softs embarqués en sous traitance c'est juste impossible et ca ne les interesse pas.
par contre tout ce qui est dev sur PC, la il faut reconnaitre qu'ils sont aussi bons que les devps de chez nous.

[koyosama]

Google est en train de créer un nouvel OS pour le tout en un comme Wndows 10 qui s'appelle : fuchsia
Les logiciel et interface vont se eêtre développer avec Flutter, c'est à dire avec Dart. Certain produit android sont déjà développer avec flutter et le grand public ne sait pas.

Mais pour le kernel, ils ont construit un truc appelé Zicron et pourtant c'est fait avec C++ / C.
Lien du dépot miroir

L'âge du projet a environ deux ans (par rapport à dépot). S'il voulait, ils pouvait déjà avec d'autres languages et pourtant ils ont choisi C / C++. Donc je pense que C et C++ ont des beaux jours devant eux.

[liberal1]

À la fois C et C ++ vous permettent d'avoir (plus ou moins) le contrôle total du matériel

En quoi?

[Adequat]

Pas perdre de vue que c'est un langage non-propriétaire, qui ne dépend de Microsoft, Apple ou autre, et avec un standard ISO.

[zecreator]

Ils vont durer encore quelques décennies je pense.

Je crois que la vie d'un langage dépend surtout des technologies en place et du modèle économique. Aujourd'hui, le langage le plus demandé en entreprise, c'est le Java/J2EE. Je ne saurais dire pourquoi on utilise encore ce langage. Sûrement qu'il y a aussi un intérêt économique pour les SSII. Je ne sais pas.

Aujourd'hui, je vois surtout une demande en C/C++ par les studios de jeux. Les frameworks et SDK utilisés sont codés en C/C++, donc c'est normal.

Pour ma part, je crois plus à l'avenir des langages web (HTML5 / Javascript) qu'aux langages compilés. Il faudra bien un jour se débarrasser de cette couche "chaine de compilation/MakeFile et build" indigeste.

Mon avis.

[wolinn]

Ils vont durer encore quelques décennies je pense.

Je crois que la vie d'un langage dépend surtout des technologies en place et du modèle économique. Aujourd'hui, le langage le plus demandé en entreprise, c'est le Java/J2EE. Je ne saurais dire pourquoi on utilise encore ce langage. Sûrement qu'il y a aussi un intérêt économique pour les SSII. Je ne sais pas.

Aujourd'hui, je vois surtout une demande en C/C++ par les studios de jeux. Les frameworks et SDK utilisés sont codés en C/C++, donc c'est normal.

Pour ma part, je crois plus à l'avenir des langages web (HTML5 / Javascript) qu'aux langages compilés. Il faudra bien un jour se débarrasser de cette couche "chaine de compilation/MakeFile et build" indigeste.

Mon avis.

Pour la simulation et la CAO, on a besoin de toute la puissance de calcul disponible, on en a jamais assez pour faire tourner des modèles météorologique, simuler des galaxies, ou des écoulements de fluides, ou des assemblages mécaniques de plus en plus complexes.
Les IHM peuvent bien être en langages interprétés, mais au final, on appelle toujours du code compilé écrit en C, C++ ou FORTRAN pour inverser une matrice 1000*1000 ou résoudre un système d'équations différentielles, même si c'est enfoui dans des bibliothèques.

[el_slapper]

(.../...)Je crois que la vie d'un langage dépend surtout des technologies en place et du modèle économique. Aujourd'hui, le langage le plus demandé en entreprise, c'est le Java/J2EE. Je ne saurais dire pourquoi on utilise encore ce langage. Sûrement qu'il y a aussi un intérêt économique pour les SSII. Je ne sais pas.(.../...)

Avis qui n'engage que moi : parce-qu'il n'est pas trop difficile de former des gens à Java.

[arachnida93]

A mon avis, pour les langages populaires, l'avenir existe au moins pour maintenir les logiciels existant et c'est le cas pour C, C++, Java, C#, Python qui grimpe...
A partir du moment où il y a des évolutions sur les sdk, c'est que ça vit.

Pour revenir à C et C++ et des nouveaux développements, ils sont utilisés sur de l'embarqué et dans la plupart des objets connectés qui pourraient constituer un marché important demain.

Avec le développement du cloud, les contraintes d'optimisation des tâches et du code reviennent à l'ordre du jour et si développer en C/C++ peut constituer une économie importante sur de gros batch quotidiens, il peut être tentant pour les entreprises d'y revenir...

Les succès de Python et R dans le calcul scientifique sont souvent dus à l'intégration dans l'écosystème de bibliothèques écrites en C/C++ ou fortran.

Les jeux video utilisent également encore beaucoup C et C++

Les vrais concurrents de ces 2 langages encore très populaires sont Rust, Go (peut-être d'autres), qui peuvent produire du code machine, mais je pense qu'ils ne les égalent pas encore en terme de performance.

https://benchmarksgame.alioth.debian...g=go&lang2=gcc

Donc plutôt d'accord avec Peter Wright

[thierryc]

Bonjour,

1°) Dès l'invention du C et du C++, ces langages ont été controversés. Ils ont connu une large diffusion à l'origine car leur compilateur était le seul gratuit pendant l'heureux temps où le système d'exploitation qui a permis leur diffusion devait être recompilé pour ajouter une imprimante.

2°) Le DoD étasunien a reconnu son incapacité à utiliser C et C++ sur de gros projets et a défini un langage Ada (83) pour programmer de manière bien plus rigoureuse ET lisible. Ada a évolué aujourd'hui (1995, puis 2005 puis 2015). Il a toujours les mêmes qualités et supériorités qu'à l'époque. Les faits sur le F-35 (retards de développements, défauts logiciels rédhibitoires) ne sont pas entièrement dus aux défauts intrinsèques de ces langages mais ces défauts y ont contribué.

3°) A l'origine, les inventeurs du langage Java ont présenté leur nouveau langage à la mode comme "le C++ sans les défauts". Sous la pression des développeurs, tous les défauts de C++ y ont été ré-introduits par la suite. On pourrait aujourd'hui ajouter ce langage à la question initiale.

4°) L'organisme chargé de la détection des défauts logiciels en cybersécurité indique qu'entre 25% et 50% de toutes les vulnérabilités d'un programme C ou C++ sont dus à des défauts de pointeurs impossibles à pratiquer dans de nombreux autres langages.

5°) Il y a donc de nombreuses sources pour indiquer de manière objective que ces langages comportent des défauts rédhibitoires que n'ont pas de nombreux autres langages.

6°) A titre personnel, j'ai eu l'honneur de diriger de grandes équipes de développeurs, et nous nous sommes efforcés de construire les meilleurs logiciels pour nos clients. A chaque fois que nous avons eu liberté de manœuvre, nous avons vendu nos développements au forfait avec une garantie de correction des anomalies sur 3 ans après la fin de la recette (ou plus selon demande client). Nous avons systématiquement battu nos compétiteurs qui utilisaient C++ ou Java comme plateforme de développement. Nos développeurs avaient pour résultats généraux un taux de défauts de l'ordre de 10 à 100 fois moins que la concurrence, dans les délais prescrits et des marges brutes par projet tout à fait confortables de 30% à 45%. Dans un cas, nous avons fourni un logiciel complet avec cahier des charges, dossier de conception, manuel utilisateur, dossier de tests et de recette en 5 jours ouvrés. L'équipe était constituée de quatre binômes maîtrise d'ouvrage/maîtrise d’œuvre tout en s'inspirant des meilleures pratiques agiles. L'équivalent d'environ 100 000 lignes de C++. Bien développer n'implique pas d'aller lentement.

7°) Dans un cas, nous avons été mis en concurrence par un client (sans le savoir initialement) avec une autre équipe qui développait en C++. Le client, malgré nos recommandations, a exigé que nous développions son produit en C++. C'était un bon client et nous avons accepté, et nous avons même vendu la prestation au même prix que si nous avions utilisé quelque chose de plus sûr. Nous avons cependant exigé la présence d'un membre de son équipe chez nous pendant le développement afin que celui-ci soit le plus transparent possible et nous n'avons rien caché de nos difficultés (inévitables) malgré le haut niveau de compétences de nos équipes et leur savoir-faire. Nous avons développé le résultat attendu avec un dépassement du budget de 50%, un dépassement du délai de 100% et 100% des fonctionnalités et performances attendues et un bon niveau de qualité pour un développement C++. L'équipe adverse, nous l’apprîmes plus tard, pleine de confiance dans ses capacités, échoua complétement et ne livra rien d'utilisable. En conclusion, nous eûmes le monopôle du développement chez ce client, sur des technologies bien plus adaptées à ses besoins. Jusqu'à 40 développeurs travaillèrent en parallèle pour ce client pour produire une variété de logiciels industriels basés sur une infrastructure de composants logiciels réutilisables. A la fin, la réutilisation par projet atteignait en moyenne 95% (5% de nouveau code), les délais de développement étaient réduits de 70%, et la qualité atteignait le 99,99%.

8°) En tant que chef de projet responsable des coûts, délais et qualité, mes observations tendent à prouver que 90% du temps de mes équipes sont consacrées à la lecture du code et à sa vérification plutôt qu'à l'écriture. Les inventeurs du langage C/C++ ont eux-mêmes indiqué avoir privilégié la concision au détriment de la lecture. L'optimisation d'un langage informatique pour 10% des activités passées est une aberration, une faute professionnelle. Notons bien que le mot de "langage" lui-même implique la notion d'échange et de communication. Je n'ai jamais vu d'équipe de la maîtrise d'ouvrage comprendre les développements. Ils n'en avaient pas les moyens. La maîtrise d’œuvre elle-même ne communique jamais en C/C++ mais par d'autres moyens. D'ailleurs je m'oppose à l'emploi du mot "codage" pour évoquer les activités de développement ou de programmation. Ce mot indique bien en effet l'action de produire un logiciel en C++, celui de l'obscurcissement de la compréhension.

9°) Je suis également un professionnel certifié de la sureté de fonctionnement. Les règles Misra C/C++ et le mode SPARK pour Ada ne sont en rien comparables en termes d'efficacité ou de résultats en termes de sureté de fonctionnement. L'ancienne version de la norme 61508 mettait bien l'accent sur ce point. La nouvelle norme a évidemment été réécrite pour tenter de masquer la difficulté d'utiliser le C++ et "d'être pragmatique" face à la déferlante C/C++. Il faut avouer que lorsqu'on on est en position d'auditeur et certificateur, c'est à la fois agréable de ne pas être à la place du développeur et attristant de devoir bloquer les projets jusqu'à ce que le niveau de sureté soit atteint et démontré. Parfois, il ne l'est jamais.

10°) Il est vrai que par rapport à l'assembleur, le C et le C++ peuvent être considérés comme des assembleurs de plus haut niveau, et apporter davantage de confort. Cet avantage paraît aujourd'hui tout relatif et limité à des développements spécifiques au niveau du noyau. Un développement en couche applicative ne devrait jamais avoir besoin d'utiliser un tel langage.

11°) Cependant, Niklaus Wirth et ses successeurs ont montré au Polytechnicum de Zurich (l'une des dix meilleures universités au monde) que l'on pouvait pouvait développer un système d'exploitation graphique entièrement à base d'agents (composants logiciels munis de leurs propres "threads"), plus compact que Unix, Windows ou tout autre système d'exploitation comparable en termes de fonctionnalités. De nombreuses publications en attestent. Aucun autre système d'exploitation ne dispose d'une telle architecture, d'une telle compacité. Tout ceci a été développé avec une modeste équipe de quelques développeurs et thésards.

13°) A l'inverse, une grande société productrice de matériels et éditrice de son système d'exploitation a indiqué très récemment ne pas pouvoir fournir de date pour la correction des défauts les plus graves de la nouvelle version, malgré les 250 milliards de dollars et plus qu'elle a en banque. Ceci n'est qu'un autre exemple.

14°) Rationnellement, l'engouement pour le développement en C++ provient de l'attrait de la nouveauté dans un premier temps, d'une réticence à payer pour des outils de développements performants de la part de financiers ou gestionnaires incompétents, de l'incapacité des chefs de projets à en comprendre l'impact sur le projet, sur l’hybris des développeurs qui se croient tous experts en C++ et capables d'éviter les chausse-trappes dans lesquels tous leurs collègues sont tombés, et enfin, dans la sécurité de l'emploi que procure un développement initial réalisé en C++ : le développeur qui a réussi à développer quelque chose devient indispensable à son entreprise et à son client pour éliminer les (nombreux) défauts et à ajouter des fonctionnalités (de plus en plus lentement. Voir la notion de dette technique).

14°) Malgré tout ceci, la masse même des développements C/C++/Java fait que ces langages seront présents pendant longtemps encore, tant que la notion de vice caché, présente dans toutes les autres industries, ne sera pas présente dans l'industrie du logiciel.

15°) En tant que maitrise d'ouvrage, directeur de projet, auditeur, chef de projet, architecte et développeur, je pourrais me désespérer de cette situation. En réalité, je m'en accommode et je m'en réjouis car ces logiciels en C/C++/Java vont me donner des occasions infinies de fournir des prestations d'audit, de conseil, de formation, de monter des équipes de secours pour sauver des projets en détresse, de ré-développer proprement des logiciels qui auraient du être fonctionnels du premier coup, de voyager aux quatre coins du monde où mon expertise est reconnue et activement recherchée. Longue vie au C/C++/Java!

[el_slapper]

(.../...)
8°) En tant que chef de projet responsable des coûts, délais et qualité, mes observations tendent à prouver que 90% du temps de mes équipes sont consacrées à la lecture du code et à sa vérification plutôt qu'à l'écriture. Les inventeurs du langage C/C++ ont eux-mêmes indiqué avoir privilégié la concision au détriment de la lecture. L'optimisation d'un langage informatique pour 10% des activités passées est une aberration, une faute professionnelle. Notons bien que le mot de "langage" lui-même implique la notion d'échange et de communication. Je n'ai jamais vu d'équipe de la maîtrise d'ouvrage comprendre les développements. Ils n'en avaient pas les moyens. La maîtrise d’œuvre elle-même ne communique jamais en C/C++ mais par d'autres moyens. D'ailleurs je m'oppose à l'emploi du mot "codage" pour évoquer les activités de développement ou de programmation. Ce mot indique bien en effet l'action de produire un logiciel en C++, celui de l'obscurcissement de la compréhension.

La raison pour laquelle j'ai adoré mes années COBOL(et mis +1 à ton message). Même un gnou peut faire du COBOL presque lisible. (bon , à deux exceptions près, obsolètes depuis longtemps, mais qu'on croise encore parfois, l'usage du point comme terminateur de toutes les boucles ouvertes précédemment, ainsi que l'immonde Alter Proceed qui change la cible d'un Go To).

Après, le coté "assembleur de haut niveau" est quand même super intéressant en embarqué, ou pour faire du bas-niveau genre jeu Vidéo.

[Betameche]

Bonjour,

Petite réponse à ce message:

Bonjour,

1°) ....

Je vais pas commenter tous les points un à un, mais en tous cas les 3 premiers sont un peu des fakes news si je puis me permettre.

1) Le C n'a pas fait controverse à son invention, il à été designer dans un objectif précis: porter Unix sur PDP-11. Et pourquoi ne pas utiliser un autre langage (comme le B, qui fut une option)? -> Le manque de possibilités offertes dans les autres, comme par exemple l'adressage des bytes. Il a ensuite percé car il répondait à un besoin !
La seule controverse que je vois, c'est celle de son utilisation aujourd'hui.

2) Le DoD était effectivement incapable d'utiliser le C++, celui-ci n'existant pas !!! Petit rappelle: Ada est plus vieux que C++. Par ailleur, Bjarne Stroustrup c'est lancé dans le C++ (à ce moment le C with classes) justement parce qu'il estimait que le C était trop peu praticable pour de gros projets.
De plus, c'est le nombre de langages (plus de 400) utiliser dans les projets qui a poussé le DoD à en chercher un qui pourrait répondre au maximum de leur besoin et à finalement choisir d'en créer un nouveau.
Pour le F35, j'ai vu parler de problème de structure, de problème d'algorithme mais je ne trouve pas de source sur des problématiques liées aux langages utilisés, je ne trouve même pas lesquels ont été utilisé ! Une aide serait la bien venue.

3) Le Java vient apparemment bien de l'insatisfaction (cf. Wikipedia) d'un ingénieur sur le C++, maintenant:
Quels défauts enlevés ont été réintroduit ?
Source sur la pression des développeurs voulant tellement faire du C++ qu'ils en changent Java !

4) Source + comparatifs avec les autres langages ???

5) de nombreuses sources, oui. Mais lesquelles ???

6-15) beaucoup d'avis personnel avec des stats sorties de nul part, donc rien à dire.

Et de manière général je suis toujours méfiant quand je vois quelqu'un écrire C/C++ et en parler comme d'un seul et même langage.

Pour info: Un petit coup de Wikipedia pour le dates (en, fr, de, toutes concordantes) pour mes sources et 2-3 premiers liens de recherche google simple pour le F35 (dont le rapport du DOT&E).

[jlliagre]

+1

Le langage C est né en 1972, le C++ en 1983. Il y a quand même onze ans d'écart. Le langage C, qui était intimement lié à Unix, a surtout été controversé par les défenseurs d'architectures fermées qui voyaient là, à juste titre, un concurrent dangereux. Dans les universités, la recherche et la presse informatique, Unix et C avaient au contraire une très bonne image.

A l'origine, les compilateurs C étaient payants comme ceux des autres langages, soit en tant que logiciels externes (ex: GreenHills, Manx), soit inclus dans un OS payant lui-même (pcc AT&T).

C'est un abus de langage de dire que le système d'exploitation (Unix, pour ne pas le nommer) qui a permis leur diffusion devait être recompilé pour ajouter une imprimante. Heureusement, ça n'a jamais été nécessaire, ni même possible quand les utilisateurs ne disposaient pas du code source des Unix propriétaires. Ce que l'on appelait la "recompilation du noyau" était en fait une méthode de reconfiguration qui consistait effectivement à créer un nouveau binaire avec un compilateur C, mais sans qu'aucun code source C du noyau ou de drivers n'intervienne dans l'opération. Ce n'était donc techniquement qu'une édition de liens.

Les noyaux modulaires ont mis fin à ce besoin dès la fin des années 80. Ils ont permis d'éviter de devoir rebooter après l'ajout d'un driver, mais on n'ajoutait pas un driver tout les jours non plus.

[Pol63]

@thierryc quel langage miraculeux utilises tu ?

concernant le 7° je pense que ca vient aussi du fait qu'un développeur est plus efficace avec un langage qu'il maitrise, donc si ton équipe est passé sur c++ avec moins d'expérience que sur un autre langage c'est normal qu'ils mettent plus de temps et aient plus de difficultés

certains disent qu'un développeur c'est un développeur et qu'il peut passer d'un langage à l'autre sans soucis, d'autres ont un cv rempli de tous les langages et framework du moment, personnellement je ne suis pas de cet avis, si ça peut prendre plusieurs années pour faire le tour d'un langage ca fait forcément une différence de niveau

[thierryc]

@thierryc quel langage miraculeux utilises tu ?

concernant le 7° je pense que ca vient aussi du fait qu'un développeur est plus efficace avec un langage qu'il maitrise, donc si ton équipe est passé sur c++ avec moins d'expérience que sur un autre langage c'est normal qu'ils mettent plus de temps et aient plus de difficultés

certains disent qu'un développeur c'est un développeur et qu'il peut passer d'un langage à l'autre sans soucis, d'autres ont un cv rempli de tous les langages et framework du moment, personnellement je ne suis pas de cet avis, si ça peut prendre plusieurs années pour faire le tour d'un langage ca fait forcément une différence de niveau

Bonjour Pol63,
Merci pour ton retour.

Je suis formateur C++ et j'ai dirigé avec succès des équipes qui ont développé des logiciels en C/C++ à plus de 4 millions de lignes de code. J'ai fait de même dans d'autres langages, dépassant allégrement le millions de lignes de source. En général, les équipes sont plutôt moins formées initialement dans ces autres langages vu que leur diffusion est un peu plus restreinte. L'hypothèse que tu fais comme quoi il s'agit d'une différence d'expérience est erronée, du moins pas dans le sens que tu crois. Je maintiens mon témoignage.

Concernant ton deuxième point, j'observe chez les développeurs que plus ils maîtrisent de langages, de natures variées (Ada, C++, Java, SQL, Assembleur, Lisp, Prolog, Eiffel, Delphi, Esterel, Active Oberon, Matlab, sans compter les langages de conception et les motifs de conception), plus leurs capacités croissent. En revanche, cela nécessite un peu de travail et beaucoup de flexibilité intellectuelle.

Bien cordialement

[thierryc]

Bonjour,
[...]
1) Le C n'a pas fait controverse à son invention,
[...]
2) Le DoD était effectivement incapable d'utiliser le C++, celui-ci n'existant pas !!! Petit rappelle: Ada est plus vieux que C++. Par ailleur, Bjarne Stroustrup c'est lancé dans le C++ (à ce moment le C with classes) justement parce qu'il estimait que le C était trop peu praticable pour de gros projets.
De plus, c'est le nombre de langages (plus de 400) utiliser dans les projets qui a poussé le DoD à en chercher un qui pourrait répondre au maximum de leur besoin et à finalement choisir d'en créer un nouveau.
Pour le F35, j'ai vu parler de problème de structure, de problème d'algorithme mais je ne trouve pas de source sur des problématiques liées aux langages utilisés, je ne trouve même pas lesquels ont été utilisé ! Une aide serait la bien venue.

3) Le Java vient apparemment bien de l'insatisfaction (cf. Wikipedia) d'un ingénieur sur le C++, maintenant:
Quels défauts enlevés ont été réintroduit ?
Source sur la pression des développeurs voulant tellement faire du C++ qu'ils en changent Java !

4) Source + comparatifs avec les autres langages ???

5) de nombreuses sources, oui. Mais lesquelles ???

6-15) beaucoup d'avis personnel avec des stats sorties de nul part, donc rien à dire.

Et de manière général je suis toujours méfiant quand je vois quelqu'un écrire C/C++ et en parler comme d'un seul et même langage.

Pour info: Un petit coup de Wikipedia pour le dates (en, fr, de, toutes concordantes) pour mes sources et 2-3 premiers liens de recherche google simple pour le F35 (dont le rapport du DOT&E).

1°) Niklaus Wirth a critiqué C dès sa création, et C++ par la suite.
2°) Le DoD était incapable d'utiliser le C, d'où la création d'Ada. C fut estimé par le DoD et reste jugé inutilisable sur les gros projets. C++ a été conçu au départ comme un pré-processeur au-dessus du C. C'est fondamentalement le même langage, le même style, les mêmes défauts.
3°) F35: par exemple, le viseur de casque. Par ailleurs, il est normal que le DoD NE peux PAS admettre avoir pris la mauvaise décision...
4°) et 5°) Trouve les sources. C'est facile.
6-15°) J'ai dirigé des projets en C++ jusqu'à 4 millions de lignes de code C++, et audité des programmes dépassant les 30 et 50 millions de lignes de code. Dans ces cas, le coût cumulé des défauts et de la dette technique du au C/C++ dépasse les 100 millions d'€. J'ai également développé de gros projets dans de nombreux autres langages ou en multi-langages dépassant le million de lignes de source. Ceci est mon témoignage.

C/C++ est le même langage: il n'y a quasiment plus de compilateur dédié à l'un seul de ces langages. La plupart du temps, les projets ont du vécu et mélangent allégrement des parties en C et des parties en C++. Je me méfie toujours de développeurs qui surestiment leurs capacités. Ne pas comprendre la communalité fondamentale du C et du C++ est une grave erreur.

Nos avis diffèrent. Ceci dit, plus des gens comme toi développent en C/C++, plus des gens comme moi auront du travail :-). J'en sors gagnant à tous les coups.
Bien cordialement

[Betameche]

Allez, juste pour le plaisir après une longue journée. Ce coup ci j'ajoute directement les infos importantes pour éviter des recherches à mes lecteurs

1°) Niklaus Wirth a critiqué C dès sa création, et C++ par la suite.

Professeur à l'ETH Zürick, Designeur de Pascal et Oberon entre autre.
Niklaus Wirth a critiqué Ada ... et C++, C, Fortran, Pascal (son propre langage) pour leur complexité, d'où sa démarche de créer Oberon.
Ça en fait difficilement une controverse je trouve.

2°) Le DoD était incapable d'utiliser le C, d'où la création d'Ada. C fut estimé par le DoD et reste jugé inutilisable sur les gros projets. C++ a été conçu au départ comme un pré-processeur au-dessus du C. C'est fondamentalement le même langage, le même style, les mêmes défauts.

Le DoD a fait une étude sur tous les langages, aucuns ne répondaient à leur critères donc le C non plus naturellement (et c'est pas vraiment un question de taille de projet). Ada, à l'instar du C, a été créé pour répondre à un besoin avec des critères spécifiques au militaire, qui est par ailleurs cité dans mon dernier message (le besoin, pas les critères).
C++ est effectivement une amélioration de C (Le terme pré-processeur est mal choisi pour le coup), mais aussi influencé par le Simula, l'ALGOL et ... Ada. Il a une syntaxe similaire au C, comme de nombreux autres langages, et est en partie compatible avec le C++ l'inverse n'étant pas vrai. Et l'unicité du sens de compatibilité va de paire avec un style fortement différent lorsque les deux sont écrit proprement.
Parlons des défauts, peux-tu les expliciter ? Car tant qu'ils ne sont pas cités, ils n’existent pas dans cette conversation.

3°) F35: par exemple, le viseur de casque. Par ailleurs, il est normal que le DoD NE peux PAS admettre avoir pris la mauvaise décision...

Exemple: le viseur de casque.
Beaucoup de défaut, difficulté à combiner les différentes informations des radars et caméra. Dédoublage des cibles dans le cas de vol en formation (les informations étant échangées entre les avions mais mal combinées). Rien de tout ça ne me fais penser à un problème de langage, c'est clairement algorithmique.
Je réitère ma question, quel langage est utiliser pour programmer les systèmes du F35 ? Je ne trouve pas l'information moi !
Et le rapport de 62 page cité dans mon précédent message ressemble à une admission, si ce n'est de mauvaises décision, en tout cas d'une mauvaise mise en oeuvre.

4°) et 5°) Trouve les sources. C'est facile.

Tellement simple à trouver, si dur à poster !

6-15°) J'ai dirigé des projets en C++ jusqu'à 4 millions de lignes de code C++, et audité des programmes dépassant les 30 et 50 millions de lignes de code. Dans ces cas, le coût cumulé des défauts et de la dette technique du au C/C++ dépasse les 100 millions d'€. J'ai également développé de gros projets dans de nombreux autres langages ou en multi-langages dépassant le million de lignes de source. Ceci est mon témoignage.

C/C++ est le même langage: il n'y a quasiment plus de compilateur dédié à l'un seul de ces langages. La plupart du temps, les projets ont du vécu et mélangent allégrement des parties en C et des parties en C++. Je me méfie toujours de développeurs qui surestiment leurs capacités. Ne pas comprendre la communalité fondamentale du C et du C++ est une grave erreur.

Nos avis diffèrent. Ceci dit, plus des gens comme toi développent en C/C++, plus des gens comme moi auront du travail :-). J'en sors gagnant à tous les coups.
Bien cordialement

Je ne remet pas en cause qu'il y ai des dettes techniques, on en voit autre part qu'en C ou C++, en fait dans un peu près tous les projets débutés trop vite et sans préparation (j'entend par là coder sans designer, à l’arrache quoi).

Les compilateurs C et C++ viennent effectivement souvent ensemble (tu peux facilement en avoir un pour C et pas C++), ça ne veut pas dire que ce sont les mêmes compilateurs pour les deux langages. Exemple: GCC (GNU Compiler Collection) à des front-ends pour C, C++, Objective-C, Fortran, Ada, et Go. Je n'en déduis pas automatiquement que tous ces langages sont les mêmes !
J'ajouterai même que des compilateurs C qui ne font pas de C++ il y en des pléthores en embarqué.
Quand bien même, avoir un compilateur dédié ne rend pas un langage plus "unique" ou "différent".

Mon avis est que confondre C et C++ ne peut que mener à mal faire les deux, et ceux dans toutes les phases de la création logiciel. Une des bases, c'est de connaitre ses outils de travail, sinon le projet est plombé avant d'avoir commencé. Leur "communalité" est purement historique aujourd'hui, faire du C++ comme en 85 (ou même du C) est une bêtise hors contrainte particulière.

Je suis pas spécialement développeur C ou C++/python/Ada/Fortran/Java. Je me tiens juste un peu au courant de l'évolution des différents langages que je suis amené à côtoyer. Et aujourd'hui c'est Tensorflow & cie, donc du python3 et du C++ (et j'ai dû apprendre les nouveautés), mais demain ce sera autre chose.

Dans un autre poste tu parle de Ada et Eiffel comme très supérieurs, je ne donnerais pas mon avis (ne connaissant pas Eiffel), je me contenterai de te poser une question même si je crois connaître ta réponse (aux vu d'un autre de tes postes):
Ne pense-tu pas que si l'un des deux langages était au stade d'utilisation et de popularité de Java ou C++, on trouverait autant de mauvais codes/projets écrit avec ?

Bonus, critique du C++: ça évolue trop vite, thierryc a pas le temps de suivre ! (c'est de l'humour, pour détendre)

[thierryc]

Tellement simple à trouver, si dur à poster !

Sur Qwant, en 30" chrono:
- F-35, viseur de casque et utilisation prédominante du C/C++ : https://en.wikipedia.org/wiki/Lockhe...s_and_avionics
wikipedia est une très bonne source secondaire. Je renvoie aux sources primaires.
Personnellement, j'aime bien:
* "Much of the F-35's software is written in C and C++ because of programmer availability", LOL, ils ne savent pas former des développeurs?
* "General Norton Schwartz has said that the software is the biggest factor that might delay the USAF's initial operational capability". Re-LOL.
* "In 2010, Pentagon officials discovered that additional software may be needed.". Re-re-LOL.
Le plus amusant, c'est que nos amis étasuniens ont été piratés par les Chinois sur le F-35 et que les chinois vont copier le code étasunien ...

- sur C++, le maître lui-même, notre vénéré Stroustrup: https://www.quotes.net/quote/9012 :
" C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, it blows away your whole leg". Traduction sémantique en français: le C est un pistolet chargé sans sécurité. Attention où vous visez. C++ est une grenade dégoupillée. Attention où vous la lancez... LOL
Sérieusement, si l'inventeur du langage dit des choses comme cela, comment peut-on s'en servir pour des développements industriels avec des contraintes de délais, de charge, de budget, avec les développeurs que l'on a et pas ceux qu'on aimerait avoir?

- sur l'adéquation du C/C++ pour le développement d'OS: http://www.ocp.inf.ethz.ch/wiki/OCP/Home
Oberon est un système d'exploitation complet, graphique, avec une architecture à base d'agents, développé pour une fraction de l'effort et du temps passé sur U...X sans parler de W..S ou de M..S. La petite taille d'Oberon, en termes de lignes de source, est également impressionnant.
Ceci démontre aisément qu'il n'est pas nécessaire d'utiliser un langage de bas niveau comme C/C++ pour développer un système d'exploitation complet.

Comme dit plus haut, les sources sont nombreuses. Mais il faut savoir chercher...

[Madmac]

[QUOTE=Betameche;9960645]Allez, juste pour le plaisir après une longue journée. Ce coup ci j'ajoute directement les infos importantes pour éviter des recherches à mes lecteurs

Professeur à l'ETH Zürick, Designeur de Pascal et Oberon entre autre.
Niklaus Wirth a critiqué Ada ... et C++, C, Fortran, Pascal (son propre langage) pour leur complexité, d'où sa démarche de créer Oberon.
Ça en fait difficilement une controverse je trouve.

Dans le cas de Ada, ce langage n'est pas à évaluer selon les mêmes critères le développement de ce langage n'était de créer le meilleur langage, mais de créer le meilleur langage qui permettait de convertir en un langage unique tous les programmes en différent langage en des programmes plus solide et plus rapides, en des programmes d'un seul langage. Ada était un très bon langage pour ce travail ingrat. Wirth a cherché a développé un langage plus dépouillé que que Pascal et C++, inspiré de CLU.. Il croyait que le concept d'objet, était un progrès. Et accidentellement, il a crée le concept de navigateur, qui par la suite allait être intégré dans tous les navigateurs internet.

Si vous êtes intéressé par l'histoire des langages de programmations et des idées qui étaient exploré. Essayer de mettre la main sur " Programming langages: An interpreter approach" de Samuel n. Kamin.


. C'est le livre le plus passionnant que j'ai eu la chance de lire sur la programmation

[thierryc]

Dans un autre poste tu parle de Ada et Eiffel comme très supérieurs [...]

L'un des défauts majeurs présents dans C/C++/Java est la possibilité de dépendances cycliques. Elles sont toujours présentes dans tous les projets que j'ai audités.
C'est tout simplement impossible en Pascal Objet, Ada ou Eiffel. Cette simple différence rend les seconds infiniment supérieurs aux premiers, dès lors qu'on travaille sur des vrais projets et pas de petits développements sans importance.

L'autre défaut majeur est la non-lisibilité des premiers par la maîtrise d'ouvrage. Le Pascal (et ses descendants ) est basiquement de l'anglais structuré. Lorsqu'il est utilisé comme tel, il devient un langage de spécification et conception, lisible par les utilisateurs et les clients. Accessoirement, il compile (très très rapidement) et produit un logiciel achevé efficace. On développe dans ces langages et on "code" en C/C++/Java. Sur les projets que je dirige, la première règle qualité est que si le source n'est pas lisible par le client, il n'est pas recettable et doit être réécrit, même s'il est juste. La deuxième règle est qu'il ne faut pas commenter le source, sauf quelque exceptions très spécifiques (intentions, liste à faire, traçabilité, ...). En moyenne, nous économisons entre 30% et 70% de temps de développement par rapport à un développement en C/C++/Java équivalent. Et 75% à 95% en maintenance corrective. En revanche, les spécifications et la conception prennent davantage de temps, de même que la revue des sources et l'écriture du cahier de recette. La balance est très favorable. Il faut comprendre que le métier de développeur est un métier essentiellement humain, où l'essentiel de l'activité est basée sur la communication entre équipes et entre membres des équipes. Il faut communiquer les besoins, l'architecture, la conception, les tests, les défauts, etc.