Discussion :

[gangsoleil]

Les inventeurs du langage C/C++ ont eux-mêmes indiqué avoir privilégié la concision au détriment de la lecture.

Hum... Le C et le C++ sont deux langages différents, conçus par des gens différents. Ta phrase n'a donc aucun sens, et tu ne donnes aucune source.

...

Pour le reste, beaucoup d'avis personnels, mais il manque surtout quelques informations à ton post : quel est ce merveilleux langage si parfait que tu utilises ? Pour quels types de développement, qui tournent sur quoi ? Et surtout, pourquoi est-ce que ce langage que tu encenses n'est pas plus utilisé ? Est-ce là encore "à cause des développeurs", ou des clients ?

[wolinn]

Le langage en question doit être Ada...

Pour ce qui est de la concision, je trouve que c'est plutôt une qualité qui facilite la relecture justement, sans atteindre non plus les excès de certains langages (voir les atrocités APL par exemple), en restant raisonnable.
Je suis un "visuel", et je préfère avoir le maximum de code sur une page pour avoir une vue d'ensemble, plutôt que faire défiler des pages et des pages de programme écrites dans un langage verbeux pour la même fonction.
Par ailleurs, je suis allé voir ces règles de codage Misra C++, et il se trouve que je les suis déjà presque toutes naturellement, à 2-3 exceptions près, et elles me paraissent assez souvent relever du bon sens.

[Pol63]

je ne connaissais même pas ce langage
mais bon qu'un langage soit peu utilisé ne signifie en rien qu'il est moins bien (je fais moi même partie d'une minorité ^^)

par contre je suis d'accord qu'un langage plus lisible c'est quand même mieux à plusieurs niveaux dont la maintenabilité

[jlliagre]

par contre je suis d'accord qu'un langage plus lisible c'est quand même mieux à plusieurs niveaux dont la maintenabilité

C'est vrai, mais il n'y a pas toujours consensus sur la quantification de la lisibilité d'un langage. C'est souvent très subjectif. On trouve plus lisible ce à quoi on est habitué, indépendamment de tout autre facteur.

Par exemple, un japonais va probablement dire que le katakana est plus facile à lire que les caractères romains que nous utilisons...

[wolinn]

je ne connaissais même pas ce langage
mais bon qu'un langage soit peu utilisé ne signifie en rien qu'il est moins bien (je fais moi même partie d'une minorité ^^)
par contre je suis d'accord qu'un langage plus lisible c'est quand même mieux à plusieurs niveaux dont la maintenabilité

Ca ne sert pas à faire des jeux, du web, des applis de smartphone, etc. ...
Par contre, c'est utilisé dans l'aérospatiale ou la défense, des domaines moins visibles.
Je m'étais bien intéressé à Ada vers 1993. De plus, ça s'inspirait bien de la syntaxe du Pascal, que je connaissais et appréciais.
Finalement, je n'ai pas retenu cette possibilité parce qu'il y avait quelques caractéristiques qui ne me plaisaient pas beaucoup pour faire du calcul scientifique intensif.

[thierryc]

Hum... Le C et le C++ sont deux langages différents, conçus par des gens différents. Ta phrase n'a donc aucun sens, et tu ne donnes aucune source.



Pour le reste, beaucoup d'avis personnels, mais il manque surtout quelques informations à ton post : quel est ce merveilleux langage si parfait que tu utilises ? Pour quels types de développement, qui tournent sur quoi ? Et surtout, pourquoi est-ce que ce langage que tu encenses n'est pas plus utilisé ? Est-ce là encore "à cause des développeurs", ou des clients ?

Bonjour gangsoleil,
1°) Concernant C et C++, j'ai déjà répondu plus haut.

2°) Il s'agit bien d'un témoignage, et je parle de langages au pluriel. Ils sont toujours très utilisés, simplement un peu moins visibles.
L'argument de l'engouement massif de la communauté vis-à-vis de tel ou tel langage ne m'a jamais convaincu: il y a beaucoup plus de Twingo que de Ferrari sur la route, mais mes clients adorent la Ferrari. Toute analogie est limitée, mais celle-ci est très pertinente. Peu importe le nombre de gens qui utilise C++. Si moi et mes équipes les battons à chaque fois, mes clients sont contents. Si mes clients m'appellent au secours parce que quelqu'un a trop promis lorsqu'il développe en C++, je suis content. Dans tous les cas, je gagne. Et je préfère rouler en Ferrari.

J'ai développé dans l'industriel, dans le temps-réel dur, dans la très haute disponibilité, dans la très haute sûreté de fonctionnement, dans la banque, dans l'industrie pharmaceutique, dans l'industrie automobile, dans l'industrie spatiale et aéronautique, etc. Plus les exigences sont sévères, plus ces autres langages sont supérieurs. Deux langages sont infiniment supérieurs à C++, par exemple: Ada et Eiffel. Si nécessaire, il m'est arrivé de développer des langages spécifiques pour des clients, comme par exemple un langage synchrone orienté-objet destiné à développer du logiciel temps-réel prouvé. Il n'y aucun moyen en C++ de démontrer une quelconque propriété que ce soit.

En fait, je ne vois aucune raison d'utiliser C++ pour un nouveau développement. Pour moi, c'est une faute professionnelle lourde. Cela n'empêche pas qu'il y a un lourd passif à gérer.

Bien cordialement,

[_Bérenger_]

Plus les exigences sont sévères, plus ces autres langages sont supérieurs. Deux langages sont infiniment supérieurs à C++, par exemple: Ada et Eiffel.

Je me méfie des superlatifs en ce qui concerne les langages de programmation. Dans les années 90, Java allait résoudre tous les problèmes de ces langages préhistoriques qu'étaient le C et le C++. Résultat, certains problèmes sont peut-être résolus, d'autres sont apparus (je pense aux performances en particulier), et la majorité des problèmes existants sont encore là.
En ce qui concerne Ada et Eiffel, le consensus actuel est qu'ils ont apporté des solutions intéressantes (génériques, programmation par contrat) mais qui ont été depuis reprises dans les autres langages. Le consensus peut se tromper, mais c'est quand même étonnant que la majorité des industriels, universitaires et créateurs de nouveaux langages les oublient complètement (à part les apports historiques). Je n'ai connaissance d'aucune explication longuement argumentée datant de moins de 10 ans en faveur de Ada et Eiffel, que ce soit pour des considérations techniques, pragmatiques ou d'expérience.
Quelles sont vos sources ? Voici les miennes :
- Alexander Stepanov a proposé dans les années 90 d'intégrer au C++ des génériques inspirés de Ada. Une fois disponibles (les templates), il a implémenté la STL en C++. Il faut croire qu'il manquait des fonctionnalités à Ada pour implémenter efficacement des algorithmes génériques.
- Robert C. Martin (Clean Code) reconnaît les apports de Eiffel, pour autant je ne l'ai jamais entendu dire que Eiffel était supérieur à C++/Java...

En fait, je ne vois aucune raison d'utiliser C++ pour un nouveau développement. Pour moi, c'est une faute professionnelle lourde. Cela n'empêche pas qu'il y a un lourd passif à gérer.

Peut-être dans votre domaine, mais dans le mien, personne ne connaît même l'existence de Eiffel ou Ada. Comment suis-je censé les convaincre qu'on a bien tord de ne pas utiliser des technologies qui n'ont jamais vraiment décollé depuis 30 ans ?

et la qualité atteignait le 99,99%.

Honnêtement, j'ai du mal à y croire. Qu'est-ce que vous entendez par 99,99% de qualité ? Avec 4 chiffres significatifs, ça me paraît un peu trop beau pour être vrai. Je ne dis pas que c'est impossible, mais donner le chiffre sans contexte de ce qui est mesuré, et sans dire ce qu'on entend par qualité, ça n'est pas très parlant.

[thierryc]

Je me méfie des superlatifs en ce qui concerne les langages de programmation. Dans les années 90, Java allait résoudre tous les problèmes de ces langages préhistoriques qu'étaient le C et le C++. Résultat, certains problèmes sont peut-être résolus, d'autres sont apparus (je pense aux performances en particulier), et la majorité des problèmes existants sont encore là.

Je suis d'accord avec vous : Java n'a rien résolu et a apporté des problèmes supplémentaires.

- Alexander Stepanov a proposé dans les années 90 d'intégrer au C++ des génériques inspirés de Ada. Une fois disponibles (les templates), il a implémenté la STL en C++. Il faut croire qu'il manquait des fonctionnalités à Ada pour implémenter efficacement des algorithmes génériques.

Effectivement les génériques manquaient à C. En revanche, l'implémentation du concept de génériques par les "templates" C++ est défectueuse et ne fournit pas les mêmes sécurités. Comme vous l'écrivez vous-mêmes, l'objectif de Stepanov n'était pas d'implémenter la STL en Ada. S'il l'avait fait, il aurait eu la même performance.

- Robert C. Martin (Clean Code) reconnaît les apports de Eiffel, pour autant je ne l'ai jamais entendu dire que Eiffel était supérieur à C++/Java...

Je reste effaré par le nombre de livres sur comment écrire du code C++ propre... R. Martin fait comme moi: il profite des défauts du C++ / Java. Contrairement à moi, il est hypocrite, car sa clientèle est constituée de développeurs C++ qui espèrent trouver un jour comment "bien" programmer.

Peut-être dans votre domaine, mais dans le mien, personne ne connaît même l'existence de Eiffel ou Ada. Comment suis-je censé les convaincre qu'on a bien tord de ne pas utiliser des technologies qui n'ont jamais vraiment décollé depuis 30 ans ?

L'argument de popularité n'a aucune valeur. Cf plus haut Twingo vs Ferrari.

Quel est votre domaine? Les miens sont : le spatial, l'aéronautique, l'électro-nucléaire, la distribution électrique, l'automobile, la pharmacie, la finance, la banque, le maritime, la défense, l'optoélectronique, les plasmas, la fusion nucléaire et la relativité générale...

Dans tous ces domaines, je n'ai pas trouvé de projet où il n'aurait pas été possible de remplacer C/C++/Java par un ou une combinaison d'autres langages, avec profit. Comme nos équipes sont professionnelles, si après nos mises en gardes, le client continue d'exiger une telle contrainte de réalisation, nous faisons au mieux et nous faisons un profit tout en satisfaisant le client. Dire du mal de C/C++/Java n'implique pas de ne pas savoir réaliser des projets avec, bien au contraire.

En général, pour convaincre, nous proposons de réaliser un premier projet ou démonstrateur au forfait, en utilisant la combinaison de méthodes et techniques les plus adéquates pour répondre au besoin du client. Souvent, nous commençons par mettre en place des méthodes d'écriture de cahier des charges, les problèmes commençant dès cette étape.

Honnêtement, j'ai du mal à y croire. Qu'est-ce que vous entendez par 99,99% de qualité ? Avec 4 chiffres significatifs, ça me paraît un peu trop beau pour être vrai. Je ne dis pas que c'est impossible, mais donner le chiffre sans contexte de ce qui est mesuré, et sans dire ce qu'on entend par qualité, ça n'est pas très parlant.

C'est une bonne remarque. Je faisais référence à une série de projets où nous avions automatisé une usine fabriquant des produits de haute technologie et nécessitant des mises à jour fréquentes. Ce taux de 99.99% est le taux de disponibilité des systèmes (matériels et logiciels inclus) fournis par mes équipes. Si la chaine de production s'était arrêtée, le directeur de l'usine serait venu nous dire deux mots. Cela n'est pas arrivé. 10e-4 de fiabilité est assez facile à atteindre. L'atteindre vite est un peu plus difficile mais il suffit de s'organiser. Comme indiqué plus haut, nous développions vite: le logiciel pour un nouvel équipement sur la chaine était développé en moins de 3 semaines avec 95% de réutilisation, recette incluse. Nous n'avons pas fait d'efforts supplémentaires pour accroitre encore notre vélocité, car les achats n'arrivaient pas à suivre pour nous procurer le matériel.

Dans le pétrole ou le maritime, nous visons plutôt du 10e-6. Dans l'aéronautique, le nucléaire et l'automobile, plutôt autour de 10e-8 à 10e-11. Le zéro défaut est également possible, mais nous utilisons alors des techniques formelles et la génération de code. C/C++ n'est alors qu'un assembleur qu'aucun développeur n'a besoin de voir. Il faut toutefois remarquer que ces chiffres sont mesurés sur le système entier. Sur le logiciel seul, qui est un équipement déterministe, la notion de fiabilité probabiliste est assez peu satisfaisante (cf. le premier vol d'Ariane 5). Personnellement, je préfère utiliser le concept de "gisement de défauts".

C'est dommage, il semble que vous n'ayez pas vécu ce genre de projets, c'est extrêmement satisfaisant de passer le cahier de recette (très complet) sans enregistrer un défaut, puis de voir passer la période de garantie sans avoir de corrections à effectuer. Les managers sont contents aussi au vu du profit réalisé. Et le client revient, sans mise en concurrence.

[ElGatao]

Cobol est un cas particulier. Ce langage de programmation ne subsiste que par la raison de l'installé : applications de gestion financières, et son plus gros utilisateur privé SAP. Car SAP continue a utiliser ce langage, pas par choix réel d'efficacité, de sécurité, ou encore de performances. Non juste parce que migrer l'ensemble des applis existantes vers Java, C# ou Python, voire ADA, serait long, coûteux et surtout obligerait a ouvrir le code.
Hors SAP, et le monde financier ne sont pas vraiment communiquant. Un argument souvent sortit est la sécurité, qui ne vient que par l'absence de connexions des systèmes à des réseaux ouverts (donc un mensonge). Un autre argument est la performance, qui elle en fait tient surtout à la dépendance logicielle des utilisateurs, et les contraintes légales d'usage (tout module complémentaire doit être développé en Cobol, et approuvé par SAP). Un argument sympathique est aussi la fiabilité, qui en fait repose sur l'absence d'informations concernant le fonctionnement des logiciels développés par SAP.
Cobol est vieux, très vieux, et comme tous les langages s'il n'évolue pas, il meurt. On peut le comparer au latin, qui n'est plus utilisé qu'au Vatican, et dans les ordres religieux. A plus de 60 ans d'age, il a franchit une vingtaine de générations (informatiques), sans changer ses bases. Sa grammaire, son vocabulaire, sa structure syntaxique, sont globalement les mêmes qu'à sa naissance. Mais les matériels employés (ordinateurs, CPU, réseaux, etc.), ont eux évolués, changés, les voies sans issues ont été fermées. Trouver une formation à Cobol en cette année relève d'un parcours impossible ou presque.
La seule raison qui permet à Cobol de continuer est l'existence d'une large base installée de logiciels, orientés vers la gestion financière, et le poids des quelques compagnies qui en font usage (contraint), dont la plus connue est SAP. Or SAP utilise pour matériel des machines IBM, qui donc continue a fournir des outils de développement Cobol, bien que sachant que c'est une erreur. Cobol est dur à lire, compliquer à coder, et surtout reste fermé. C'est pourquoi ce langage n'est pas fiable. Qui peut sortir l'équivalent assembleur de Cobol ? Comment fonctionnent vraiment la gestion mémoire, le traitement des données, les appels réseaux, sous quelles formes sont donc traitées les informations en Cobol.
Oui, C/C++ sont vieux aussi, ADA de même, mais ils sont ouverts, complètement documentés, et surtout on peut suivre les process durant l'usage. Essayez de faire de même avec une appli bancaire. De plus le manque réel d'ouvrages pour appuyer Cobol, ainsi que la quasi inexistence de formations pour Cobol en font un zombie.
Alors oui, Cobol n'est pas encore mort, mais comme un mort-vivant de Z-Nation, il n'en finit pas de mourir et d'entrainer des victimes avec lui. Juste un rappel pour finir, en 2011 une crise financière eu lieu, déclenchée par une incompréhension du fonctionnement des systèmes de trading logiciel (dont une partie liée aux systèmes de gestion financière). Le manque d'infos sur les systèmes logiciels et matériels, le secret qui entoure ce milieu d'activité, et surtout le refus de communication du monde financier sur son propre fonctionnement en sont responsables.
Mais si les idiots continuent a croire que l'ignorance est garante de sureté, fiabilité et performance, alors allez vers Cobol, et laissez C/C++, Java, Python, D et autres. Développez sans documenter, codez sans vérifier, déployez sans informer, mais quand vous tomberez, et vous tomberez, personne ne vous ramassera.