Il a déjà 8 ans ton article sur l'avenir...Citation:
Envoyé par Madmac
Version imprimable
Il a déjà 8 ans ton article sur l'avenir...Citation:
Envoyé par Madmac
Je pense que d'ici là, les technos web (HTML5 et javascript) et les navigateurs auront pris une maturité qui permettra de faire tourner des jeux vidéos 3D directement en ligne. Avec l'arrivée de la fibre partout, on peut s'attendre à voir des choses très intéressantes.Citation:
Envoyé par e101mk2
Un exemple de jeux multi-joueurs en ligne :
https://volkania.com/tag/jeu-en-ligne/
Un autre en 3D :
https://tanx.io/?u=KrMzjxk9Io0GM1uD
C'est un début prometteur. Perso, ça me gave d'avoir à passer 4 de téléchargement et 1 heure d'installation + les downloads de mises à jour régulières du jeu.
Il est temps que ça change.
soit c'est du troll soit c'est du fanatisme.Citation:
Envoyé par Madmac
Je n'ai jamais codé en Scheme ou en Prolog, mais je suis en train d'apprendre le Haskell qui est un langage purement fonctionnel, dans lequel il n'existe aucune variable mutable.Citation:
Envoyé par RyzenOC
Je ne considère pas avoir beaucoup de mal à m'adapter. Mais c'est vrai que, en partant du C++, l'apprentissage du Haskell ne se limite pas à apprendre la syntaxe du langage, à lire la documentation de la bibliothèque standard et à chercher comment pallier l'absence de certaines fonctionnalités supportées par le C++.
En Haskell, on écrit du code que l'on n'écrirait pas en C++, parce que la syntaxe serait beaucoup trop lourde en C++ si on codait de la même manière qu'en Haskell. Du coup, c'est intéressant. Je découvre une nouvelle manière de programmer.
En arithmétique une expression mathématique résolu est :
1 + 1 = 2
En Scheme :
(+ 1 1)
En Prolog :
?- X is 1+1. <-question
X = 2 <-réponse
Ou
?- 2 is 1+1. <-question
yes <-réponse
En Haskell :
1 + 1
ou une fonction add qui prend deux paramètres
let add x y = x + y
add 1 1 ou 1 `add` 1
Après un bref parcours, je trouve que ce sont des langages spécialisés comme l'est SQL vis-à-vis de ce qu'il faut "commander".
En Graphcet, je pense bien que je ne pourrais pas faire plus simplement, il faudrait beaucoup du matériel spécialisé/spécifique en input/output...
Alors je vous fais grasse de l'algèbre de Boole... (a/.a) :ptdr:...
Python par contre, il y a quelques point fort.
Un script BASH peu permettre aussi de faire quelques truc.
ouCode:
2
3
Les deux sont pas pareil et pourtant exploiter le subtilité tiens plus du challenge...Code:
2
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!
Bien imagine, la qualité des librairie depuis. React est passablement intéressant, mais il y a toute une floppée de UI qui sont en gestation. Éventuellement la nécessité de GUI traditionnelle va devenir de moins en moins nécessaire.Citation:
Envoyé par SimonDecoline
Enfin un programmeur qui admet que le langage est un challenge pour les programmeurs. Je commençais à me sentir seul, ;)Citation:
Envoyé par thierryc
C et C++ sont comme le sexe: Tous le monde croient qu'ils sont bons, mais personnes en est sûr !
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).Citation:
Envoyé par thierryc
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.
Bonjour,
Petite réponse à ce message:
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.Citation:
Envoyé par thierryc
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).
+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.
@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
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.Citation:
Envoyé par thierryc
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 ?Citation:
Envoyé par thierryc
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.
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é
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.Citation:
Envoyé par Pol63
Par exemple, un japonais va probablement dire que le katakana est plus facile à lire que les caractères romains que nous utilisons...
Ca ne sert pas à faire des jeux, du web, des applis de smartphone, etc. ...Citation:
Envoyé par Pol63
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.
1°) Niklaus Wirth a critiqué C dès sa création, et C++ par la suite.Citation:
Envoyé par Betameche
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
Bonjour Pol63,Citation:
Envoyé par 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
Bonjour gangsoleil,Citation:
Envoyé par 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,
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.Citation:
Envoyé par thierryc
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.
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).Citation:
Envoyé par thierryc
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.
Exemple: le viseur de casque.Citation:
Envoyé par thierryc
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.
Tellement simple à trouver, si dur à poster !Citation:
Envoyé par thierryc
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).Citation:
Envoyé par thierryc
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)