Discussion :

[Luc Hermitte]

Je vous invite à regarder le webinar suivant:
https://community.embarcadero.com/al...-linux-cluster
vous verrez bien qu'il n'y a aucune difficulté particulière, bien au contraire, à faire du calcul à hautes performances en Pascal.
Ada possède les mêmes propriétés.

Mouais. Je trouve pas de références facilement sur le sujet. -- "Delphi", "Pascal"... concernent d'autres choses dans le contexte du HPC. Il y a donc un webinar auquel il faut s'inscrire etc etc. Peu d'informations ou de benchs faciles d'accès donc. Ce ne donne pas envie de creuser. Surtout avec une licence payante.

Il faut voir qu'il y a déjà une différence de performances sensible entre deux compilateurs concurrents pour un même langage pour le HPC -- typiquement Intel met les moyens dans ses compilateurs (Fortran, C, et C++) pour vendre ses puces. L'industriel derrière Delphi met-il autant d'effort sur ce sujet de niche ? J'aimerai bien avoir des mesures plus concrètes que "essaies tu vas voir, c'est rapide" (c'est tout ce que j'ai trouvé sur un commentaire dans un blog)

Pour les chaînes, le C++ est revenu en arrière sur le COW car justement ce n'est pas aussi rapide que cela -- nous sommes dans des environnements multiprocesseurs, et il faut blinder les accès concurrents ce qui a malgré tout un prix dont on peut se passer à 99% du temps. Maintenant, si la chaîne est manipulée via une référence dans un GC, le surcoût du COW est peut-être gommé, je ne sais pas comment marche Delphi aujourd'hui. Est-ce qu'il a gardé le passage de paramètres de Pascal où tout est passé par valeur, sauf s'il y a un "var" qui dit "par référence"?
Quand vous parlez de "manipuler des objets", j'en déduis qu'il existe un type référence vers objet. C'est bien ça? J'en étais resté aux objets qui se manipulaient via des pointeurs (et tous les problèmes qui s'en suivent)


Ce qui me fait penser avec toutes ces histoires de "les choses évoluent". Avez-vous jeté un oeil aux C++CoreGuidelines ? À cette mouvance qui cherche à introduire des types opaques en C++ (des décennies après Ada, certes) ? Cette volonté d'éliminer les pointeurs bruts ? Et dans le cas de chaîne et tableau de disposer de types pour les unifier tous tout en sécurisant au maximum la manipulation de la mémoire (string_view, span...).
On en arrive au problème qu'il faut mettre à jour les développeurs ensuite pour qu'ils oublient les saletés qu'ils devaient faire auparavant, et c'est ça le plus compliqué.


Concernant les dépendances cycliques. J'en écrivais avec Turbo Pascal 5.5 (ou 5.0?). C'est parfaitement possible. Ce qui change vraiment, c'est la notion de module qui fait effectivement cruellement défaut. Des versions expérimentales sont en cours de réalisation/étude sur les 3 principaux compilateurs avec l'espoir de converger pour le C++20, tout en gardant une rétrocompatibilité avec le fonctionnement hérité du C...

[SofEvans]

J'ai peur que SofEvans ait une connaissance plus qu'obsolète du pascal, ou de l'Ada, comme le montre son post.

Il serait plus exact de dire que ma connaissance est très limité plus que de dire qu'elle est obsolète.
J'ai cherché à comprendre pourquoi les string en Pascal sont si parfaite (et par la même, pourquoi celle du C ne sont pas du niveau du Pascal), et la seule explication que j'ai pu trouver c'est qu'il existe un type de string en Pascal où l'indice 0 correspond à sa taille (bien pratique pour la concatenation, par exemple).

Maintenant, je ne dis pas que le Pascal ou l'Ada sont moins bon que le C/C++, je dis que pour affirmer qu'un langage est plus optimisé qu'un autre, il faut le prouver.
Merci donc de bien vouloir me démontrer comment et pourquoi les string en Pascal, c'est trop de la balle, et les string en C, c'est trop dépassé (wesh wesh, ca rime ! tavu !).

C'est très fréquent chez les ayatollah du C/C++.

Le langage C est effectivement mon langage de prédilection, mais dès que je peux m'en passer, je le fais. Je vais pas faire des scripts web en C, ni des tout petit programmes qui ne sont pas du tout destinés à évoluer.

Là où je parle de ce que je sais, ayant développé de très gros logiciels à la fois en Pascal, en Ada, en C++, en Java et encore d'autres langages et me tenant à jour des évolutions de ces langages, les thuriféraires du C++ sont bien ignorants et restent coincés dans l'espace-temps autour de 1970. CQFD.

CQFD ? Euh, pourriez-vous être plus explicite sur ce que vous vouliez démontrer ?
Encore une fois, vous affirmer quelque chose sans en apporter la preuve.
Dire que le langage Perl est plus lent que le langage C, c'est logique et facile à démontrer. (L'un des points fort du C est la vitesse d'exécution, et ce n'est pas le cas du Perl)
Dire que les langages Pascal / Ada sont plus rapide que le langage C, c'est déjà plus difficile, la vitesse d'exécution étant l'un des points fort du C.

Aujourd'hui, les chaînes de caractères ont par défaut un compteur de références et une copie de chaine ne coûte rien. Lorqu'une nouvelle chaine doit être créée en modifiant une chaine existante, c'est fait au dernier moment possible. La taille des chaines Pascal peut dépasser les 2 GB si nécesaire.

Cool. Vous savez, en C (ou tout autre langage), quand on COPIE une chaîne de caractère, c'est parce que la chaine1 et/ou la chaine2 vont être modifié chacune de leurs côté. Si vous voulez juste avoir une 2ème variable qui ait la même valeur que la chaîne de caractère, on utilise un pointeur constant. Et l'affectation d'un pointeur, c'est 8 octets (oui je sais, en vérité, ca dépend, mais bon, 4 ou 8 octet ...).
Et la taille d'une string en C est limité uniquement par l'espace mémoire contiguë disponible (que ce soit la RAM ou le swap ...). Comme tout les tableaux en C en fait. Et comme les tableaux en C++, Java, et peut-être même Pascal et Ada ?

Et un post plus haut indique bien que le compilateur Pascal, ou l'Ada, optimise tout le code. L'exemple des chaines de caractères n'est qu'un exemple. Il faut vraiment lire de travers pour comprendre autrement, et prendre les gens qui lisent ces posts pour des billes pour recommander -o2 ou -o3. (A propos, ces options sont interdites lorsqu'il faut produire du code sûr de fonctionnement. Ça n'aide pas pour la perfo...)

Non, je ne lis pas de travers. Je ne dis pas non plus que le compilateur Pascal ou Ada n'optimise que les chaine de caractère.
Je dis simplement que prendre UN seul aspect du langage et dire que le compilateur est capable de l'optimiser pour "démontrer" la "supériorité" d'un langage est idiot.
Dans le meilleur des cas, vous auriez démontrer (et encore) qu'avec un compilateur Pascal (il en existe plusieurs, j'imagine, comme pour le C ?) et un code sur un aspect particulier, le binaire produit est "mieux" que le même code en C optimisé par l'un ds compilateur C.

De plus, même si je comprends pourquoi o3 serait interdit (c'est clairement indiqué dans la doc de gcc que cette option est trop "agressive"), je ne vois pas en quoi o2 ou même o1 serait un problème (à moins évidemment, d'introduire des comportement indéterminé dans le programme, mais là ça relève plus du développeur que du compilateur).
L'optimisation faite par gcc en o1 ou o2 produit le résultat escompté.
Pour finir, dire que o2 n'aide pas pour la performance .... c'est un peu le BUT de l'option o2, d'aider à la performance en terme de rapidité d’exécution.
Je pense, sans pouvoir l'affirmer, que si l'option o2 produisait l'effet contraire de ce pourquoi elle est employé, ce léger détail serait dans la doc de gcc, non ?

[Invité]

les thuriféraires du C++ sont bien ignorants et restent coincés dans l'espace-temps autour de 1970. CQFD

bien-sûr, la fameuse époque du C++77...

[thierryc]

@Thierryc, avez-vous déjà audité des logiciels ADA et Pascal?
quels points auditez-vous?
Quelle méthodologie utilisez-vous?

Concernant le C++, est-ce que vous vous concentrez uniquement sur la syntaxe, du type si vous voyez un pointer alors c'est mal?

Bonjour epsilon68, tout dépend du périmètre d'audit, s'il couvre le produit, le process, la maîtrise d’œuvre et/ou la maîtrise d'ouvrage.

Le process est audité en utilisant les techniques d'audit du CMMI (https://www.sei.cmu.edu/cmmi/), complétées éventuellement par des aspects spécifiques à la gestion de la sureté de fonctionnement. C'est applicable aussi bien pour le process maitrise d'ouvrage que pour le process maitrise d’œuvre. Un audit full-CMMI est plus onéreux en général, mais n'apporte pas grand-chose de plus sauf en cas de certification. Je préfère réaliser des audits plus rapides et donnant déjà de nombreux résultats exploitables, d'attendre que les équipes aient progressé (beaucoup) avant de faire un audit full-CMMI.

Le produit est audité en utilisant SQALE : http://www.sqale.org/, complétée éventuellement par des aspects spécifiques à la mise en œuvre de la sureté de fonctionnement. C'est applicable en général sur la maitrise d’œuvre, et parfois sur la maitrise d'ouvrage lorsqu'on voit des équipes intégrées. On peut y intégrer ou non les composants réutilisés, et y intégrer ou pas les sources générées (à partir d'UML, grafcet, Esterel ou tout autre formalisme de plus haut niveau), y intégrer ou pas les sources des tests unitaires, s'ils existent. Un audit SQALE se conduit sur (tous) les sources, avec un outil et ensuite en analysant les résultats obtenus et en faisant en parallèle une revue ciblée des sources. La règle des 80/20 s'applique, c'est-à-dire que les défauts ne sont pas uniformément distribués, mais une majorité d'entre eux résident dans une petite minorité des sources. Jean-Louis Letouzey a publié des articles sur l'emploi de SQALE avec C++ et Java. Il a obtenu que SQALE soit outillé par des analyseurs de code pour ces langages, qui sont disponibles dans le commerce. Il me semble également que si des règles de nommage sont précisées, certains outils sont capables de les vérifier également. Jean-Pierre Rosen a publié des articles sur l'emploi de SQALE en Ada. J.P. Rosen dispose des outils nécessaires pour mener à bien une analyse. Et bien entendu, je dispose d'un outil SQALE pour les développements en Pascal. Suivant la cible, il y a de 25 à 60 points de mesure automatisés. Il n'est pas possible d'échapper à un diagnostic complet, même en "rusant". Si on voulait, on pourrait utiliser 300 points de mesure ou plus, mais cela ne change pas fondamentalement le diagnostic et complexifie l'audit. L'avantage de SQALE par rapport à d'autres méthodes de mesure de la non-qualité des sources, c'est qu'elle est beaucoup plus générale et priorise les défauts à corriger, afin d'obtenir le plus rapidement possible l'objectif à atteindre, que ce soit la fiabilité, la performance, la maintenabilité, etc. Egalement, la méthode raisonne en termes de dette technique et permet de comparer les technologies entre elles.

L'équipe d'audit est constituée de 2 à 6 personnes suivant le périmètre et la taille du projet. Le rapport est en général produit en temps réel, pour avoir le retour des équipes et des clients. Il y a de nombreux graphiques et des exemples de sources "typiques". Le rapport corrèle les défauts de processus avec ce que l'on voit dans les sources. En général, les plus réticents à admettre les résultats d'audit ne sont pas les développeurs, qui connaissent parfaitement la qualité de ce qu'ils développent, mais les managers, qui n'ont pas su voir ou n'ont pas voulu voir la réalité de leur projet.

Vous ne pouvez pas trouver de meilleurs auditeurs que Jean-Louis ou Jean-Pierre.

Pour répondre enfin à tes questions:
- En général, les défauts de syntaxe en C++ ne contribuent que peu, individuellement, à la non-qualité. S'il y en a beaucoup, il peut y avoir un effet de masse.
- Oui, eux et moi avons audité de nombreux projets C/C++/java/Ada/Pascal, etc, réalisés dans un seul langage ou en combinant plusieurs.

Ai-je répondu à tes questions?
Bien cordialement,
Thierryc

[thierryc]

Mouais. Je trouve pas de références facilement sur le sujet. -- "Delphi", "Pascal"... concernent d'autres choses dans le contexte du HPC. Il y a donc un webinar auquel il faut s'inscrire etc etc. Peu d'informations ou de benchs faciles d'accès donc. Ce ne donne pas envie de creuser. Surtout avec une licence payante.

Il faut voir qu'il y a déjà une différence de performances sensible entre deux compilateurs concurrents pour un même langage pour le HPC -- typiquement Intel met les moyens dans ses compilateurs (Fortran, C, et C++) pour vendre ses puces. L'industriel derrière Delphi met-il autant d'effort sur ce sujet de niche ? J'aimerai bien avoir des mesures plus concrètes que "essaies tu vas voir, c'est rapide" (c'est tout ce que j'ai trouvé sur un commentaire dans un blog)

Pour les chaînes, le C++ est revenu en arrière sur le COW car justement ce n'est pas aussi rapide que cela -- nous sommes dans des environnements multiprocesseurs, et il faut blinder les accès concurrents ce qui a malgré tout un prix dont on peut se passer à 99% du temps. Maintenant, si la chaîne est manipulée via une référence dans un GC, le surcoût du COW est peut-être gommé, je ne sais pas comment marche Delphi aujourd'hui. Est-ce qu'il a gardé le passage de paramètres de Pascal où tout est passé par valeur, sauf s'il y a un "var" qui dit "par référence"?
Quand vous parlez de "manipuler des objets", j'en déduis qu'il existe un type référence vers objet. C'est bien ça? J'en étais resté aux objets qui se manipulaient via des pointeurs (et tous les problèmes qui s'en suivent)


Ce qui me fait penser avec toutes ces histoires de "les choses évoluent". Avez-vous jeté un oeil aux C++CoreGuidelines ? À cette mouvance qui cherche à introduire des types opaques en C++ (des décennies après Ada, certes) ? Cette volonté d'éliminer les pointeurs bruts ? Et dans le cas de chaîne et tableau de disposer de types pour les unifier tous tout en sécurisant au maximum la manipulation de la mémoire (string_view, span...).
On en arrive au problème qu'il faut mettre à jour les développeurs ensuite pour qu'ils oublient les saletés qu'ils devaient faire auparavant, et c'est ça le plus compliqué.


Concernant les dépendances cycliques. J'en écrivais avec Turbo Pascal 5.5 (ou 5.0?). C'est parfaitement possible. Ce qui change vraiment, c'est la notion de module qui fait effectivement cruellement défaut. Des versions expérimentales sont en cours de réalisation/étude sur les 3 principaux compilateurs avec l'espoir de converger pour le C++20, tout en gardant une rétrocompatibilité avec le fonctionnement hérité du C...

Quand je vous lis, c'est désespérant. Pour vous. D'après votre propre post, C++ a 30 ans de retard en termes de modularité, et ne sera jamais lisible. Des efforts inouïs sont faits pour tenter de pallier des défauts intrinsèques. Ces efforts seraient louables s'ils changeaient en profondeur le langage. Mais ce ne serait plus du C++, mais de l'Ada :-). Mais laissez-le donc tomber, ce langage! il ne vaut pas grand-chose et tous les ajouts ne font que le complexifier davantage au détriment de la règle d'Antoine de Saint-Exupéry (ou du rasoir d'Occam, selon).

La performance que vous visez n'y est obtenue qu'aux prix de contorsions qui rendent le code non-maintenable.

Comme indiqué plus haut, moi, j'y gagne à tous les coups : plus il y a des gros projets en C++/Java, plus cela me donne du travail. Les seuls que ça touche et qu'on ignore dans tout cela, ce sont les clients et les utilisateurs. Le temps que je passe dans ces posts est donc complétement désintéressé. C'est uniquement parce que cela m'afflige de voir tant de jeunes gens passer à côté de ce qui est passionnant dans le métier pour se coltiner un code "imbitable" à longueur de journée. Je vous prie d'excuser mon langage. Le plus rigolo, c'est quand je montre son bug à un de ces jeunes gens qui débogue un gros paquet de code et qui n'a pas vu son erreur en C++ ou en Java et qui me demande sincèrement, vu mon âge canonique, comment se fait-il que je sache lire du code moderne :-).

Étant développeur professionnel, je ne vois pas où est le mal de payer un bon compilateur au juste prix, réalisé par d'autres développeurs professionnels.
Sur les licences payantes, Delphi Architect est très rapidement rentabilisé. Mais si ton directeur financier ne sait pas investir dans des outils puissants, il existe un starter kit gratuit pour Delphi, il existe aussi une licence libre d'Ada, pour des logiciels non-commerciaux. Il existe aussi un excellent compilateur open source : Free Pascal Compiler (FPC). et la version Pascal dans GCC, etc. N'oublie pas, si tu ne payes pas, c'est que c'est toi le produit...

Bien cordialement,
Thierryc

[Luc Hermitte]

a- Quand je vous lis, c'est désespérant. Pour vous. D'après votre propre post, C++ a 30 ans de retard en termes de modularité, et ne sera jamais lisible. Des efforts inouïs sont faits pour tenter de pallier des défauts intrinsèques. Ces efforts seraient louables s'ils changeaient en profondeur le langage. Mais ce ne serait plus du C++, mais de l'Ada :-). Mais laissez-le donc tomber, ce langage! il ne vaut pas grand-chose et tous les ajouts ne font que le complexifier davantage au détriment de la règle d'Antoine de Saint-Exupéry (ou du rasoir d'Occam, selon).

b- La performance que vous visez n'y est obtenue qu'aux prix de contorsions qui rendent le code non-maintenable.


c- Étant développeur professionnel, je ne vois pas où est le mal de payer un bon compilateur au juste prix, réalisé par d'autres développeurs professionnels.
Sur les licences payantes, Delphi Architect est très rapidement rentabilisé. Mais si ton directeur financier ne sait pas investir dans des outils puissants, il existe un starter kit gratuit pour Delphi, il existe aussi une licence libre d'Ada, pour des logiciels non-commerciaux. Il existe aussi un excellent compilateur open source : Free Pascal Compiler (FPC). et la version Pascal dans GCC, etc.

e- N'oublie pas, si tu ne payes pas, c'est que c'est toi le produit...

Bien cordialement,
Thierryc

a- La lisibilité est subjective pour la syntaxe, et affaire d'effort (les procédures de 100 lignes, et à autre V(g) délirant, sont tout autant compliquées à lire quelque que soit le langage)
La modularité, elle arrive. Un peu comme si je critiquais aussi Pascal parce qu'il y a quelques années sa gestion des chaînes étaient limitée...
Fallait-il l'abandonner à l'époque pour ne jamais assister à la naissance de Delphi? Faut-il critiquer la version courante qui repose sur du COW (n'ayant pas été démenti, je suppose que telle est donc la situation) alors que les GC de Java partageront les chaînes de façon encore plus efficaces?

Et effectivement le C++ tend à se rapprocher de l'Ada. Je ne mets pas ça dans les défauts. Mais bon.
La compléxification, c'est quand on veut connaître absolument tout le langage. Aux enseignants de comprendre que ce n'est pas nécessaire: dans le genre, mes premières leçons en Ada il y a plus de 20ans, ce n'était pas de savoir comment on alloue de la mémoire. Aux utilisateurs de se restreindre à un sous ensemble intelligent: je ne faisais pas des casts au niveau bit dans tous les sens en Pascal, je chercherai à éviter l'équivalent du void* (quoique je ne sais pas si c'est faisable, je n'ai pas souvenir que Delphi ait ouvert la porte à la généricité), je ne fais pas d'arithmétique de pointeurs. Pourquoi parce qu'un langage permet de faire des choses (qui en plus nuisent à la robustesse et à la maintenabilité) faut-il nécessairement qu'on les fasse?

b- Je vous arrête tout de suite. La performance que je vise est obtenue avec des bibliothèques mathématiques dédiées qui offrent une lisibilité bien supérieure aux langages dépourvus de surcharge des opérateurs: c'est certes du sucre syntaxique, mais simple à employer, lisible, maintenable, et cela offre des performances du niveau des BLAS SAXPYiennes du Fortran.

La performance est aussi obtenue en travaillant les structures de données et les boucles en amont pour offrir une meilleure utilisation du cache, et des possibilités de vectorisation qui seront exploitées par le compilateur. Je fais aussi en sorte de rendre le code parallélisable intelligemment. Je fais exactement la même chose en Fortran, et si Delphi/Ada sont/étaient capables de faire la même chose, les mêmes besoins de structuration apparaîtraient. La spécificité C ou C++ est strictement nulle ici.

Pour le reste, je laisse faire les diverses évolutions de compilateurs et n'altère pas mon style que je vise haut niveau. Je ne fais plus de bidouilles qui étaient à la mode il y a 30 ans, même en Pascal.

c- Il faut d'abord l'évaluer de manière sérieuse. Ca prend du temps, et quel est l'intérêt au vu de la quantité et de la qualité des autres outsiders comme Julia, Python... Je suis peu être idiot, mais je pars du principe que si on ne trouve pas facilement de bench montrant que Pascal ou Ada sont efficaces pour du HPC, c'est qu'au mieux se seront des langages de glues. Sauf que là, la mode est la migration des scientifiques à Python pour la glue.

Quand je ne vois rien dans la matrice des features de Delphi qui traite de vectorisation, et qu'un post sur G+ indique qu'en 2015 il ne supportait même pas SSE2... Me parler de Delphi comme quoi c'est un truc performant est une gentille blague dans le contexte du HPC. Je ne vais clairement pas faire acheter des licences de la bête pour notre cluster. Ada, au moins grâce à GNU devrait pouvoir faire quelque chose de ce côté.

En fait, c'est le même genre de blague que de proposer du C++ pour écrire des outils de gestions.

d- Entre GAFA et open-source, il y a une sacrée différence. Evitons les amalgames. Pour ce qui est des compilateurs d'Intel, c'est encore un autre modèle où l'on va p.ex. payer leurs cartes accélératrices.

[Pyramidev]

J'ose prétendre que ce dont nous avons besoin, c'est de gens qui ont fait des maths, de la philo, de l'histoire(la vraie, celle ou on réfléchit aux causes, pas celle ou on apprend par cœur), de la littérature, de la physique, de la chimie, bref, toutes les matières nobles et généralistes qui forment l'esprit. J'aurait même envie d'y ajouter le latin, langue de la rigueur par excellence. Un peu de sociologie aussi, parce que l'informatique, c'est toujours fait par des gens pour des gens.

Et le jour ou il arrive en entreprise, le Jeune Diplômé ne sait certes pas ce que c'est qu'un singleton, ou autres designs patterns. Mais il a appris à structurer sa pensée, et à peine mis au jus, il saura parfaitement quand il faut les utiliser...et quand il ne faut pas.

Je suis entièrement en désaccord.

Cette affirmation part de l'hypothèse que la majorité des gens sont doués pour réutiliser dans une discipline un savoir-faire qu'ils ont acquis dans une autre discipline éloignée. Or, dans la pratique, ce n'est pas ce que j'observe.

Prenons l'exemple des mathématiques.

En début de prépas scientifiques, je croyais que, quand on était bon en math, alors on était bon en algorithmie. En effet :

• En mathématiques, il faut penser à tous les cas possible. En algorithmie aussi. Sinon, le programme ne fonctionne normalement que dans les cas les plus courants et est bogué dans les autres.
• Parmi les concepts mathématiques, certains sont très utilisés en algorithmie, par exemple l'algèbre de Boole.

Aujourd'hui, j'ajoute aussi le point commun suivant entre les mathématiques et la programmation :
En mathématiques post-bac, on généralise beaucoup de choses qu'on avait déjà vues avant, grâce à des abstractions. Par exemple, grâce aux structures algébriques (groupes, anneaux, corps, espaces vectoriels, etc.), on peut démontrer des choses très générales au lieu de faire à chaque fois les mêmes démonstrations dans chaque cas particulier.
En programmation, on peut aussi généraliser du code, par exemple en utilisant des callbacks, des fonctions virtuelles (en POO) ou des templates (en programmation générique).

Et pourtant :

• En prépas scientifiques, j'ai vu des élèves qui, alors qu'ils se débrouillaient bien en math, avaient du mal à comprendre des algorithmes triviaux dont la complexité se limitait à une boucle for imbriquée dans une autre boucle for.
• Au quotidien, le code que je lis n'a souvent aucune rigueur sur les préconditions, les postconditions et les invariants. Pourtant, les développeurs qui l'ont écrit, comme tout le monde, ont suivi des cours de mathématiques dans lesquels, quand on manipulait des fonctions, il fallait faire attention aux ensembles de départ et aux ensembles d'arrivée.

A propos de l'enseignement des mathématiques, les croyances comme "ça apprend la rigueur", "ça forme l'esprit" et "ça forme à l'abstraction" ne collent pas à ce que j'observe. Cela fonctionne sur une minorité de personnes, mais pas chez la majorité des gens.
Concernant l'enseignement des disciplines encore plus éloignées de l'informatique comme la philo, l'histoire, la littérature, la physique, la chimie, le latin et la sociologie, je pense que l'impact sur la productivité de la majorité des développeurs sera quasi nulle.

D'ailleurs, admettons que, lors du recrutement des développeurs, on change les règles de sélection en privilégiant des profils très généralistes qui ont fait des maths, de la philo, de l'histoire, de la littérature, de la physique, de la chimie, du latin et de la sociologie, mais pas forcément de la programmation.
La conséquence directe est que les étudiants qui veulent devenir développeurs vont devoir subir tout un tas de matières qu'ils n'aiment pas toujours et, encore pire, seront sélectionnés dessus.
Par exemple, si un étudiant aime la programmation mais déteste la chimie, crois-tu que lui imposer d'approfondir ses capacités en chimie le rendra meilleur en programmation ? Je pense que non.
En plus, avec un tel système, des gens qui seraient très doués en programmation mais moyens dans les autres disciplines seraient rejetés lors de la sélection, ce qui serait absurde.

La pureté technique sera, trop souvent, son seul horizon. Et il fera un programme à la mode, super joli, respectant tous les designs patterns à la mode, mais qui ne sert pas à grand chose. J'en ai trois sur le dos, en ce moment. Un Australien, un Allemand, un Bielorusse, tous formés à l'informatique pure, tous des dieux de la technique. Et qui sont infoutus de corriger des bugs qui m'empêchent de bosser.

Si un code est écrit par des dieux de la technique et si la hiérarchie laisse ces dieux faire correctement leur travail, alors le code est très réutilisable, contient peu de dépendances, expose de manière explicite les dépendances qu'on ne peut éviter, contient peu de bogues, facilite l'ajout de nouvelles fonctionnalités, rend difficile l'apparition de nouveaux bogues, facilite la recherche de la cause des bogues existants et est facile à lire par quelqu'un qui connaît bien les règles et les idiomes les plus courant du langage.

Le programme en question ne répondra peut-être pas au besoin du client, mais il pourra évoluer rapidement et facilement.

Si tes trois développeurs ont écrit un code depuis zéro et qu'ils n'arrivent pas à corriger leurs propres bogues, alors soit ils ne sont pas bons techniquement, soit on les a empêché de faire leur travail.
S'ils ne travaillent pas depuis zéro mais qu'ils subissent un code historique très volumineux, alors ta remarque n'est pas pertinente, car la maintenabilité d'un gros programme dépend beaucoup plus de la qualité du travail fait en amont que des compétences techniques des derniers arrivés sur le projet.

Pour les chaînes, le C++ est revenu en arrière sur le COW car justement ce n'est pas aussi rapide que cela

Pour compléter tes dires, je vais citer un article de Herb Sutter : Optimizations That Aren't (In a Multithreaded World).

[wolinn]

...
c- Il faut d'abord l'évaluer de manière sérieuse. Ca prend du temps, et quel est l'intérêt au vu de la quantité et de la qualité des autres outsiders comme Julia, Python... Je suis peu être idiot, mais je pars du principe que si on ne trouve pas facilement de bench montrant que Pascal ou Ada sont efficaces pour du HPC, c'est qu'au mieux se seront des langages de glues. Sauf que là, la mode est la migration des scientifiques à Python pour la glue.
...

Je réponds juste à c) en tant que chef de projet intéressé par Ada.
Pour développer des logiciels un peu conséquents, construits pour durer 20 ans, 30 ans, et plus, on a besoin de certaines garanties sur la stabilité et la pérennité du langage. En plus d'avoir fait ses preuves sur des projets importants, Ada est soutenu par des grandes organisations, n'est pas lié à un vendeur, c'est un langage mature, normalisé, la moindre évolution est certainement l'aboutissement de longs débats et réflexions.
Qualités qu'on ne retrouve pas dans certains langages, dont les développeurs diffusent des mises à jour tous les ans, parfois incompatibles (ce qui renvoie une image d'immaturité), ou d'autres langages portés par des petites communautés d'enthousiastes qui peuvent s'évaporer en quelques années. Malgré certaines qualités, je n'ai aucune envie d'utiliser ces langages pour des projets importants.
Par contre, je pense que Ada fait partie des valeurs sûres, qui ne risque pas de disparaitre demain, c'est à dire qu'il devrait encore y avoir des nouveaux compilateurs dans 20 ans.
De ce point de vue, ça parait être un langage du même calibre que FORTRAN, C, C++, mais qui souffre peut-être seulement d'être arrivé quelques années trop tard (pour autant que je m'en souvienne, pour la POO, C++ était en avance sur Ada, avant Ada 95).
Donc, en ce qui me concerne, j'ai un intérêt à passer un peu de temps dessus pour évaluer les gains de productivité promis, tout en m'assurant que ce ne soit pas en sacrifiant les performances. Et c'est le point que je vais vérifier en priorité, parce que je suis aussi étonné que Ada n'ait pas eu plus de succès en calcul scientifique.

[Invité]

c- Il faut d'abord l'évaluer de manière sérieuse. Ca prend du temps, et quel est l'intérêt au vu de la quantité et de la qualité des autres outsiders comme Julia, Python... Je suis peu être idiot, mais je pars du principe que si on ne trouve pas facilement de bench montrant que Pascal ou Ada sont efficaces pour du HPC, c'est qu'au mieux se seront des langages de glues. Sauf que là, la mode est la migration des scientifiques à Python pour la glue.

Quand je ne vois rien dans la matrice des features de Delphi qui traite de vectorisation, et qu'un post sur G+ indique qu'en 2015 il ne supportait même pas SSE2... Me parler de Delphi comme quoi c'est un truc performant est une gentille blague dans le contexte du HPC. Je ne vais clairement pas faire acheter des licences de la bête pour notre cluster. Ada, au moins grâce à GNU devrait pouvoir faire quelque chose de ce côté.

Complètement d'accord. Je veux bien croire qu'Ada est adapté à l'aérospatial vu qu'il a été conçu pour ce genre de domaine mais le HPC a des contraintes très différentes et Ada/Pascal y est juste complètement absent. Ca ne vient peut-être pas du langage en lui-même (quoique... http://benchmarksgame.alioth.debian.org/u64q/ada.html) mais actuellement quasiment tous les outils de HPC sont basés sur fortran/c/c++/cuda/python (par exemple, pour le deep learning : https://en.wikipedia.org/wiki/Compar...rning_software) ou sur des langages plus spécifiques comme julia/chapel/scala. Mais bien-sûr notre ami le pape du Ada/Pascal qui fonce en ferrari va nous expliquer que c'est parce que les chercheurs et développeurs de Google/Facebook/Intel/Mathworks/etc et des universités comme Berkeley/NYU/etc sont des imbéciles et des ignorants.

[Luc Hermitte]

Je réponds juste à c) en tant que chef de projet intéressé par Ada.
Pour développer des logiciels un peu conséquents, construits pour durer 20 ans, 30 ans, et plus, on a besoin de certaines garanties sur la stabilité et la pérennité du langage. En plus d'avoir fait ses preuves sur des projets importants, Ada est soutenu par des grandes organisations, n'est pas lié à un vendeur, c'est un langage mature, normalisé, la moindre évolution est certainement l'aboutissement de longs débats et réflexions.
Qualités qu'on ne retrouve pas dans certains langages, dont les développeurs diffusent des mises à jour tous les ans, parfois incompatibles (ce qui renvoie une image d'immaturité), ou d'autres langages portés par des petites communautés d'enthousiastes qui peuvent s'évaporer en quelques années. Malgré certaines qualités, je n'ai aucune envie d'utiliser ces langages pour des projets importants.
Par contre, je pense que Ada fait partie des valeurs sûres, qui ne risque pas de disparaitre demain, c'est à dire qu'il devrait encore y avoir des nouveaux compilateurs dans 20 ans.
De ce point de vue, ça parait être un langage du même calibre que FORTRAN, C, C++, mais qui souffre peut-être seulement d'être arrivé quelques années trop tard (pour autant que je m'en souvienne, pour la POO, C++ était en avance sur Ada, avant Ada 95).
Donc, en ce qui me concerne, j'ai un intérêt à passer un peu de temps dessus pour évaluer les gains de productivité promis, tout en m'assurant que ce ne soit pas en sacrifiant les performances. Et c'est le point que je vais vérifier en priorité, parce que je suis aussi étonné que Ada n'ait pas eu plus de succès en calcul scientifique.

Je suis sur un cluster (orienté calculs) et on migre justement et régulièrement des projets depuis des vieilles machines que plus personne ne veut/peut maintenir vers des choses plus récentes (et bien plus puissantes) sous RH7 (je sais parler de "récent" et de "RH7" dans la même phrase, c'est bizarre). Toujours est-il que l'on a des difficultés sur pas mal de softs que l'on ne peut pas recompiler comme ça et qui introduisent des régressions conséquentes d'une version à l'autre. Du coup il faut introduire des bidouilles pour garder des binaires produit pour des OS plus anciens. Ce n'est pas génial. Et quand il y a des problèmes pour compiler des vieilles sources, la difficultés ne réside pas tant dans le support du langage que des dépendances vers des versions de bibliothèques systèmes devenues obsolètes et dépréciées entre temps.

Pour ce qui est d'Ada et du scientifique, c'est un milieu fortement trusté par Fortran. C et C++ gagnent du terrain depuis quelques années. Mais franchement, le truc le plus efficace, pour des scientifiques non développeurs, est aujourd'hui Python. Ils peuvent prototyper comme ils l'auraient fait avec du matlab ou du scilab, il y a des implémentations libres et même des implémentations optimisées gratuites (cf python-intel). Plus tout un écosystème assez riche avec les briques de calculs intensif écrites en d'autres langages faits pour l'intensif. D'ailleurs quand on parle de deep learning en Python, les couches basses, c'est du C++. (N'allez pas croire que j'aime Python, ce n'est pas le cas)

[Aurelien.Regat-Barrel]

mais qui souffre peut-être seulement d'être arrivé quelques années trop tard (pour autant que je m'en souvienne, pour la POO, C++ était en avance sur Ada, avant Ada 95).

Ada était prophétisé comme le messie qui allait sauver le monde de la "crise du logiciel", et puis il s'est pris les pieds dans le tapis au moment de traverser la mer Rouge Mais sur quoi a-t-il trébuché au juste ? De ce que j'ai lu, entre autre choses, il n'y avait pas de compilateur décent pour la petite plateforme x86 : pas assez de mémoire pour compiler un programme ! A l'inverse, les compilateurs C++ se sont multipliés avec succès sur x86. De même, Stepanov avait initialement placé toute sa lib dans un seul fichier "stl.h", et c'est le comité de normalisation qui a décidé de le découper en plusieurs fichiers séparés par crainte d'empêcher la compilation sur les petites plateformes. Autrement dit : "le diable se cache dans les détails".

De nombreux langages sont là pour témoigner que la qualité intrinsèque (prétendue...) du langage n'est pas un facteur déterminant de son succès. C'est quelque chose de classique dans le succès d'une technologie : le x86, Windows, etc... Et c'est souvent très difficile de comprendre et admettre ce point. Donc qu'on aime ou pas C++, il convient de reconnaître que le pragmatisme et le souci du détail avec lesquels le développement de ce langage a été mené est hautement respectable et ferait bien d'en inspirer quelques uns. Parce que créer un langage c'est une chose, le faire utiliser en est une autre. Surtout quand on est seul. Bjarne Stroustrup mérite à juste titre les honneurs à ce niveau. C'est quelqu'un de très pragmatique et d'une certaine humilité aussi : il est parti du langage C car il a reconnu la force de ce langage et a préféré partir de quelque chose d'éprouvé que de réinventer la roue... en moins bien.

A l'inverse Ada a eu la folie des grandeurs et s'est vautré dans sa prétention et son arrogance : ce qui comptait à l'époque a été négligé. Particulièrement en France on peut constater le traumatisme que ça a créé : 30 ans plus tard certains n'ont toujours pas digéré la pilule. C'est toujours le même discours, quelque part entre "on marche sur la tête" et "pourquoi le monde n'était pas prêt pour un langage comme Ada"... Autrement dit, nous sommes une élite incomprise, et notre fardeau est d'être trop en avance sur notre temps, condamnés à vivre isolés au milieu de béotiens... qui codent avec des void*... ça doit être ça en effet...

Bref, les chiens aboient, mais la caravane passe...

[thierryc]

Bref, les chiens aboient, mais la caravane passe...

Oh non, la caravane ne passe pas. A chaque audit, les équipes prennent des claques, bien méritées.

Tant qu'on ne sera pas débarrassé de C/C++/Java, cela continuera.

Et dès lors qu'on a suffisamment démoli le langage, on retrouve des arguments qui n'ont rien à voir avec le sujet:
- "prenez python, c'est bien mieux que C++" : tout le monde est d'accord,
- "prenez Fortran, c'est mieux que le C++ pour le calcul scientifique" : c'est d'autant plus vrai que ça libère du temps de cerveau de scientifique de ne pas avoir à pensez aux astuces du C++, mais "simplement" de penser à leur problème scientifique à résoudre. En plus, les dernières versions de Fortran sont très intéressantes, avec notamment, l'introduction du concept de matrice dans les primitives du langage. Également, Fortran n'a jamais été aussi facile à interfacer, c'est très économique et puissant de réaliser un cœur de calcul en Fortran et d'y ajouter la décoration (IHM, bases de données, serveur web, etc.) réalisés dans d'autres langages (hors C/C++/Java, s'entend).
- "ce n'est pas qu'une question de langage" : la question du langage est la question de ce fil de discussion. Mais j'adhère. Ceci dit, pourquoi croire d'une équipe qui développe en autre chose que C/C++/Java ne connait pas le SWEBOK, CMMI, UML, la loi de Demeter, les motifs de conception, la prédiction de la performance finale, UML en couleurs, SQALE, les tests unitaires, la rédaction de cahier des charges, la revue disciplinée des sources, le zéro défaut, la haute performance ou la bonne estimation du prix et de la durée d'un projet? Qui ne comprend pas qu'avoir une faiblesse critique (C/C++/Java) dans une chaine de production logicielle ralentit et pollue toute la chaine?
- "C++ a telle chose de fabuleuse (exemple: surcharge des opérateurs)" : oups, encore un qui ne sait pas que cela existe depuis le début en Ada et en Eiffel, et existe aujourd'hui dans le pascal moderne. Ne vous inquiétez pas, tout ce qui est utile et qui fonctionne plus ou moins bien en C++ existe aussi dans Ada, Eiffel et Pascal, en plus sûr, mieux réalisé et plus lisible. Vous ne me croirez pas. Alors essayez...
Même s'il manque quelque chose dans un autre langage (en effet, tout existe en C++, Stroustrup a essayé d'avoir la plus grosse boite à outils du monde (il y a réussi, le bougre, il a la plus grosse!), ne vous inquiétez, ce n'est pas critique pour votre projet: soit vos développeurs ne la connaissent pas, soit ils s'en servent mal, soit ils peuvent s'en passer car en effet, une bonne architecture et une bonne conception ne dépendent pas d'une astuce du langage ou du compilateur,
- "Ada a été développé pour l'aéronautique" : non c'est faux. Ada a été développé à la demande du DoD comme langage généraliste et il était destiné à remplacer tous les langages de ce client majeur, à la fois en embarqué et au sol, pour les applications critiques et pour les applications de gestion (demandez au militaires si le projet Louvois n'est pas critique). Les qualités même qui font que Ada a été retenu pour Rosetta et Ariane 6 en font un outil parfaitement adapté pour aller vite et durer longtemps. Moi, j'aime bien quand les logiciels que j'ai fait développer sont utilisés par le client pendant 10, 15 ou 20 ans ou plus, et qu'ils restent maintenables et portables après tout ce temps.
- "la communauté utilise bcp de produits "merdiques", alors un de plus...": je suis d'accord sur le constat mais pas sur la conclusion. Il y a un réel manque de rationalité dans notre métier. Tentons au moins de nous en débarrasser d'un, on verra après pour les autres. Anecdote : Napoléon a demandé à ce qu'on plante des arbres le long de toutes les routes de France (et des pays libérés, euh conquis... :-)). On lui répond que les arbres mettent longtemps à pousser. Alors il dit : Mais qu'attendez-vous? Dépêchez-vous de les planter ces arbres.

Un peu d'humour et de culture, en conclusion: "Delenda C++ est"

Bien cordialement,
Thierryc

[zecreator]

Nous arrivons à l'apogée de ce topic, avec une battle finale de technicien, sur fond d'histoire du C et du C++. De tout ça, je n'en ressort qu'une chose : les développeurs C/C++ sont aussi barbants que les développeurs Java...

[Invité]

Nous arrivons à l'apogée de ce topic, avec une battle finale de technicien, sur fond d'histoire du C et du C++. De tout ça, je n'en ressort qu'une chose : les développeurs C/C++ sont aussi barbants que les développeurs Java...

Non. Déjà c'est un topic de battle de technicien depuis le début. Et l'apogée ce sera quand quelqu'un va nous sortir que c/c++/java c'est tellement le mal que c'est responsable de l'holocauste.
Oups...

[wolinn]

Ada était prophétisé comme le messie qui allait sauver le monde de la "crise du logiciel", et puis il s'est pris les pieds dans le tapis au moment de traverser la mer Rouge Mais sur quoi a-t-il trébuché au juste ? De ce que j'ai lu, entre autre choses, il n'y avait pas de compilateur décent pour la petite plateforme x86 : pas assez de mémoire pour compiler un programme ! A l'inverse, les compilateurs C++ se sont multipliés avec succès sur x86. De même, Stepanov avait initialement placé toute sa lib dans un seul fichier "stl.h", et c'est le comité de normalisation qui a décidé de le découper en plusieurs fichiers séparés par crainte d'empêcher la compilation sur les petites plateformes. Autrement dit : "le diable se cache dans les détails".
...

C'est peut-être bien une partie de l'explication. Lorsque je me suis intéressé à Ada, en 1993, je n'ai jamais compilé de programme Ada. J'ai acheté un livre, me suis documenté sur le sujet, à une époque où réunir des informations était plus laborieux qu'aujourd'hui, sans Internet. D'un autre côté, il y avait des compilateurs C++ facilement accessibles, ce qui a une importance pour une PME, j'étais dans une PME de 10 personnes à l'époque.
Et puis certaines de ces petites sociétés qui ont eu facilement accès à C++ à ses débuts sont devenues des organisations plus importantes, ce qui a encore contribué à diffuser le langage.

[thierryc]

C'est peut-être bien une partie de l'explication. Lorsque je me suis intéressé à Ada, en 1993, je n'ai jamais compilé de programme Ada. J'ai acheté un livre, me suis documenté sur le sujet, à une époque où réunir des informations était plus laborieux qu'aujourd'hui, sans Internet. D'un autre côté, il y avait des compilateurs C++ facilement accessibles, ce qui a une importance pour une PME, j'étais dans une PME de 10 personnes à l'époque.
Et puis certaines de ces petites sociétés qui ont eu facilement accès à C++ à ses débuts sont devenues des organisations plus importantes, ce qui a encore contribué à diffuser le langage.

Tout ceci était peut-être vrai à l'époque. Bien que déjà à l'époque, je travaillais plus efficacement avec les alternatives, en particulier pour du logiciel applicatif.

En tout cas, cela n'est plus vrai aujourd'hui, et c'est bien une faute professionnelle lourde que de démarrer un nouveau projet en C/C++.
Cordialement,
Thierryc

Delenda C++ est.

[SofEvans]

En tout cas, cela n'est plus vrai aujourd'hui, et c'est bien une faute professionnelle lourde que de démarrer un nouveau projet en C/C++.

Delenda C++ est.

Puisque vous n'arrivez pas à vous faire comprendre en français, vous vous mettez au latin ?
Votre croisade commence à devenir pathétique.

Vous savez, quand j'ai lu ce que vous aviez fait (et que vous vous faite) professionnellement, je me suis dit que j'aimerais bien un jour atteindre le même niveau que vous.
J'avoue que ça me fait un peu rêver, de participer / faire de très très gros logiciel. Avec presque aucun bug, de plus.

Cependant, si le prix à payer pour cela est de devenir aussi arrogant, prétentieux et "m'as-tu-vu" que vous, et bien je préfère rester un petit développeur C hérétique.


Je vous ai poser une question simple, mais jusqu'à maintenant vous ne m'avez pas répondu et avez préféré répondre aux questions qui semble vous arranger.
Je reformule donc ma question :

Vous affirmer que le compilateur Pascal est capable d'optimiser au maximum (vous employez tout de même le mot "optimal") les string en Pascal, et qu'il "n'y a pas photo par rapport à du C de base".
Pourriez-vous approfondir cet aspect afin de me CONVAINCRE (notez l'emploie du mot convaincre en majuscule/gras/souligné, et non du mot "persuader") pourquoi le C est tellement à la ramasse sur ce point ?

[Luc Hermitte]

a- "prenez Fortran, c'est mieux que le C++ pour le calcul scientifique" : c'est d'autant plus vrai que ça libère du temps de cerveau de scientifique de ne pas avoir à pensez aux astuces du C++, mais "simplement" de penser à leur problème scientifique à résoudre. En plus, les dernières versions de Fortran sont très intéressantes, avec notamment, l'introduction du concept de matrice dans les primitives du langage. Également, Fortran n'a jamais été aussi facile à interfacer, c'est très économique et puissant de réaliser un cœur de calcul en Fortran et d'y ajouter la décoration (IHM, bases de données, serveur web, etc.) réalisés dans d'autres langages (hors C/C++/Java, s'entend).

b- "C++ a telle chose de fabuleuse (exemple: surcharge des opérateurs)" : oups, encore un qui ne sait pas que cela existe depuis le début en Ada et en Eiffel, et existe aujourd'hui dans le pascal moderne. Ne vous inquiétez pas, tout ce qui est utile et qui fonctionne plus ou moins bien en C++ existe aussi dans Ada, Eiffel et Pascal, en plus sûr, mieux réalisé et plus lisible. Vous ne me croirez pas. Alors essayez...
Même s'il manque quelque chose dans un autre langage (en effet, tout existe en C++, Stroustrup a essayé d'avoir la plus grosse boite à outils du monde (il y a réussi, le bougre, il a la plus grosse!), ne vous inquiétez, ce n'est pas critique pour votre projet: soit vos développeurs ne la connaissent pas, soit ils s'en servent mal, soit ils peuvent s'en passer car en effet, une bonne architecture et une bonne conception ne dépendent pas d'une astuce du langage ou du compilateur,

a- Si entre les guillemets, il y s'agit d'une citation, je n'ai pas souvenir de l'avoir lue. Et venant de moi, qui parle de Fortran, je ne l'ai pas écrite. Je me suis juste contenté de dire que c'est exactement le même combat de travail à faire sur le code pour optimiser pour du HPC que ce soit en C, C++ ou Fortran... Et que le Fortran est encore très enraciné dans les mentalités, mais en perte de part de marché: C, C++ et Python prennent de plus en plus de place. Pour l'anecdote, le centre météo européen migre non seulement vers le C++, mais aussi vers des licences libres. Météo France forme ses personnels à Python histoire entre autre de pouvoir suivre ce que font les stagiaires.

b-La vraie citation a un contexte: "La performance que je vise est obtenue avec des bibliothèques mathématiques dédiées qui offrent une lisibilité bien supérieure aux langages dépourvus de surcharge des opérateurs". Dit autrement, je reste en haut niveau avec des appels optimisés, vectorisés, parallélisés, etc. Dit autrement, ce qu'il fallait lire entre les lignes est: il n'y a pas de sale bidouille propre au C++ pour optimiser, et en plus c'est lisible et maintenable. Je ne l'écris pas la surcharge, je l'utilise. Si maintenant ces autres langages ont évolué tant mieux. C'est bien et merci de me l'apprendre. Plus qu'à ce qu'ils pluggent ça à des bibliothèques optimisées dans un premier temps (genre LAPACK ou MKL), et qu'ils sachent vectoriser les boucles faites à la main pour les calculs scientifiques qui ne correspondent pas à des algos standards (je vise Delphi).

[jlliagre]

En tout cas, cela n'est plus vrai aujourd'hui, et c'est bien une faute professionnelle lourde que de démarrer un nouveau projet en C/C++.

On sent bien que tu essaie de convaincre le reste du monde du bien fondé de tes opinions mais le meilleur moyen pour aller dans cette direction, ce n'est pas d'être méprisant et provocateur.

Pour l'instant, c'est plutôt l'effet inverse que tu suscites. Pour être franc, je risque plutôt d'éviter d'envisager l'utilisation de développeurs ADA dans mes projets s'ils risquent d'être aussi pontifiants et rigides dans leurs certitudes que toi.

Ton discours fait penser aux théories conspirationnistes: on nous ment, on nous incite à utiliser des langages stupides qui conduisent à notre perte alors que la vérité est connue d'une petite secte d'initiés, les seuls à connaître le zéro-bug et la réussite de projets...

[marc.collin]

Tout ceci était peut-être vrai à l'époque. Bien que déjà à l'époque, je travaillais plus efficacement avec les alternatives, en particulier pour du logiciel applicatif.

En tout cas, cela n'est plus vrai aujourd'hui, et c'est bien une faute professionnelle lourde que de démarrer un nouveau projet en C/C++.
Cordialement,
Thierryc

Delenda C++ est.

as-tu pensé que tu avais peut-être juste un problème de compétence?

au lieu de cracher sur tout ce qui n'entre pas dans tes cordes, essaye de les maitriser

la technique n'est pas un critère crucial de l'échec des projets en informatiques tel que l'on montré différente étude sur le sujet aisément accessible via le web ou dans des livres de gestion de projet