Discussion :

[_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.

[thierryc]

Tellement simple à trouver, si dur à poster !

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

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

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

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

[Madmac]

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

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

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

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


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

[thierryc]

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

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

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

[sergio_is_back]

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

Je vois pas ou tu veux en venir avec tes additions, la plupart savent faire des additions

En C++ ça donne A = 1+1;
En Pascal A:=1+1;
En Basic LET A = 1+1
Etc...

De même tu peux écrire en pascal

if ( 2=(1+1)) then ....

etc...

Après pour des formules complexes certains langages sont plus efficaces car plus "spécialisés" dans ce domaine

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".

C'est exactement pourquoi le C et et C++ perdurent, ils sont bien adaptés à une problématique particulière (support matériel en particulier)
et se "plient" à certaines de ces contraintes. En plus il faut toujours prendre en compte la plateforme sur laquelle on développe. Une carte
embarquée à base de FreeScale c'est pas un PC x86 (ni x64), on obliger de faire parfois avec les outils que l'on a... même on peut penser
que l'implémentation de tel ou tel langage sur telle plateforme serait un avantage... Quand je développe je vais passer 3 ans à réimplémenter tout un
langage parce que C++ ne serait plus à la mode

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...

Pas besoin d'entrées/sortie faire du grafcet... Tu peux remplacer les E/S par des variables mémoire qui seront l'image des tes E/S
ça marche pareil... Une entrée ou une sortie peut être vue comme une variable booléenne (True ou False)

Alors je vous fais grasse de l'algèbre de Boole... (a/.a) ...

Non, non, ne nous fait pas "grasse" de algèbre de Boole.... C'est une façon élégante de résoudre un problème en le décomposant en unités
élémentaires (une action = une équation)... C'est par là que j' débuté la programmation et ça reste une technique valable dans bien des domaines
et on devrait plus l'enseigner aux apprentis développeurs

Exemple :
Action1 = (Condition1 + Condition2) . /Condition3

Ce qui se traduit en :

if ((Condition1 || Condition2 ) && !Condition3) { Action1(); }

Python par contre, il y a quelques point fort.

Un script BASH peu permettre aussi de faire quelques truc.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
int a =0;
a = (a++) + (a++);
/* a = 1 + 2 ou a = 1 + 1 selon quoi ? */

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
int a =0;
a = (++a) + (a++);

Les deux sont pas pareil et pourtant exploiter le subtilité tiens plus du challenge...

Tous les langages ont leurs points forts et leurs subtilités...

Exemple : on peut représenter une "union" en Pascal comme en C++

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
type
  PGPI_TRIGGER = ^TGPI_TRIGGER;

  TGPI_TRIGGER = packed record
    portNumber: TUINT16;
    gpiEvent: Boolean;
    timeoutMilliseconds: TUINT32;
  end;

  TLPGPI_TRIGGER = PGPI_TRIGGER;
  PLPGPI_TRIGGER = ^TLPGPI_TRIGGER;
  { *
    * HANDHELD_TRIGGER contains the Trigger information for Handheld Gun/Button that can Start/Stop an operation, like Inventory, Access, TagLocationing, etc.
    * Handheld Gun/Button based trigger can be specified for Start Trigger as well as Stop Trigger.
  }
  { *<  The HANDHELD_TRIGGER_EVENT_TYPE that causes the operation to start. }
  { *<  Trigger timeout in milliseconds. If set to zero, it indicates there is no timeout.
    Ignored for START_TRIGGER_TYPE_HANDHELD; Valid only for STOP_TRIGGER_TYPE_HANDHELD_WITH_TIMEOUT. }

  PHANDHELD_TRIGGER = ^THANDHELD_TRIGGER;

  THANDHELD_TRIGGER = packed record
    handheldEvent: THANDHELD_TRIGGER_EVENT_TYPE;
    timeoutMilliseconds: TUINT32;
  end;

  TLPHANDHELD_TRIGGER = PHANDHELD_TRIGGER;
  PLPHANDHELD_TRIGGER = ^TLPHANDHELD_TRIGGER;
  { *
    * TRIGGER_WITH_TIMEOUT  contains information for triggers with timeout
  }
  { *<  N attempts or N Tag-Observations. }
  { *<  For specifying a fail-safe timeout when this trigger is used as a
    stop trigger. When the timeout is 0, it indicates that there is no
    timeout. }

  PTRIGGER_WITH_TIMEOUT = ^TTRIGGER_WITH_TIMEOUT;

  TTRIGGER_WITH_TIMEOUT = packed record
    n: TUINT16;
    timeoutMilliseconds: TUINT32;
  end;

  TLPTRIGGER_WITH_TIMEOUT = PTRIGGER_WITH_TIMEOUT;
  PLPTRIGGER_WITH_TIMEOUT = ^TLPTRIGGER_WITH_TIMEOUT;
  { *
    * PERIODIC_TRIGGER specifies when to start the Inventory or AccessSequece operation
    * and the time period to run the operation.
    * It is a member of START_TRIGGER.
  }
  { *<  Non-zero value indicating the time period in milliseconds for which inventory will run. }
  { *< UTC Time to start the operation. }

  PPERIODIC_TRIGGER = ^TPERIODIC_TRIGGER;

  TPERIODIC_TRIGGER = packed record
    periodMilliseconds: TUINT32;
    startTime: PSYSTEMTIME;
  end;

  TLPPERIODIC_TRIGGER = PPERIODIC_TRIGGER;
  PLPPERIODIC_TRIGGER = ^TLPPERIODIC_TRIGGER;
  { *
    * START_TRIGGER specifies the condition for starting  Inventory or AccessSeqeunce operation.
    * It is a member of TRIGGER_INFO.
  }
  { *<  Start trigger of type START_TRIGGER_TYPE. }
  { *< To be specified for START_TRIGGER_TYPE_GPI. }
  { *< To be specified for START_TRIGGER_TYPE_PERIODIC. }
  { *< To be specified for START_TRIGGER_TYPE_HANDHELD. }
  { *<  Value need not be specified for START_TRIGGER_TYPE_IMMEDIATE. }

  PSTART_TRIGGER = ^TSTART_TRIGGER;

  TSTART_TRIGGER = packed record
    TriggerType: TSTART_TRIGGER_TYPE;

    value: packed record
      case longint of
        0:
          (gpi: TGPI_TRIGGER);
        1:
          (periodic: TPERIODIC_TRIGGER);
        2:
          (handheld: THANDHELD_TRIGGER);
    end;
  end;

  TLPSTART_TRIGGER = PSTART_TRIGGER;
  PLPSTART_TRIGGER = ^TLPSTART_TRIGGER;

Code d'origine en C++:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
/** 
* GPI_TRIGGER contains the GPI-Trigger information.
* GPI based trigger can be specified for Start Trigger as well as Stop Trigger.
*/
typedef struct _GPI_TRIGGER
{
	UINT16 portNumber;/**<  GPI Port number on which the trigger is to be enabled.*/
	BOOLEAN gpiEvent;/**<  The Boolean value that causes a GPI event to trigger.*/
	UINT32 timeoutMilliseconds;/**<  Trigger timeout in milliseconds. If set to zero, it indicates there is no timeout.
				   Ignored for START_TRIGGER_TYPE_GPI; Valid only for STOP_TRIGGER_TYPE_GPI_WITH_TIMEOUT.*/
}GPI_TRIGGER, *LPGPI_TRIGGER;

/** 
* HANDHELD_TRIGGER contains the Trigger information for Handheld Gun/Button that can Start/Stop an operation, like Inventory, Access, TagLocationing, etc.
* Handheld Gun/Button based trigger can be specified for Start Trigger as well as Stop Trigger.
*/
typedef struct _HANDHELD_TRIGGER
{
	HANDHELD_TRIGGER_EVENT_TYPE handheldEvent;/**<  The HANDHELD_TRIGGER_EVENT_TYPE that causes the operation to start.*/
	UINT32 timeoutMilliseconds;/**<  Trigger timeout in milliseconds. If set to zero, it indicates there is no timeout.
				   Ignored for START_TRIGGER_TYPE_HANDHELD; Valid only for STOP_TRIGGER_TYPE_HANDHELD_WITH_TIMEOUT.*/
}HANDHELD_TRIGGER, *LPHANDHELD_TRIGGER;

/** 
* TRIGGER_WITH_TIMEOUT  contains information for triggers with timeout
*/
typedef struct _TRIGGER_WITH_TIMEOUT
{
	UINT16 n;/**<  N attempts or N Tag-Observations.*/
	UINT32 timeoutMilliseconds;/**<  For specifying a fail-safe timeout when this trigger is used as a 
						stop trigger. When the timeout is 0, it indicates that there is no 
						timeout.*/
}TRIGGER_WITH_TIMEOUT, *LPTRIGGER_WITH_TIMEOUT;

/**
* PERIODIC_TRIGGER specifies when to start the Inventory or AccessSequece operation 
* and the time period to run the operation. 
* It is a member of START_TRIGGER.
*/
typedef struct _PERIODIC_TRIGGER
{
	UINT32 periodMilliseconds;/**<  Non-zero value indicating the time period in milliseconds for which inventory will run.*/
	SYSTEMTIME* startTime;	/**< UTC Time to start the operation.*/
}PERIODIC_TRIGGER, *LPPERIODIC_TRIGGER;

/** 
* START_TRIGGER specifies the condition for starting  Inventory or AccessSeqeunce operation.
* It is a member of TRIGGER_INFO.
*/
typedef struct _START_TRIGGER
{
	START_TRIGGER_TYPE	type; /**<  Start trigger of type START_TRIGGER_TYPE.*/
	union
	{
		GPI_TRIGGER gpi; /**< To be specified for START_TRIGGER_TYPE_GPI.*/
		PERIODIC_TRIGGER periodic;/**< To be specified for START_TRIGGER_TYPE_PERIODIC.*/
		HANDHELD_TRIGGER handheld; /**< To be specified for START_TRIGGER_TYPE_HANDHELD.*/
	}value; /**<  Value need not be specified for START_TRIGGER_TYPE_IMMEDIATE.*/
}START_TRIGGER, *LPSTART_TRIGGER;

Bien que développant depuis des années en Pascal Objet (Delphi sur PC et CodeTyhon en cross compilation) j'en découvre tous les jours dans ce langage.... Avant de dire qu'un langage
est trop vieux et moins efficace qu'un nouveau encore faudrait-il le pousser dans ses retranchements. Je vois beaucoup de codes dans tous les langages qui se limitent
aux "fonctions minimales" ou basique et ne vont pas chercher dans le coeur de ce dernier pour essayer de résoudre un problème...

[MikeRowSoft]

Je vois pas ou tu veux en venir avec tes additions, la plupart savent faire des additions

Si, encore une fois, oui ! Je ne referais la roue. #include <math.h> c'est pour autre chose vue que les CPU ont des opérateurs non "surchargeable" avec leurs registres.

Exemple :
Action1 = (Condition1 + Condition2) . /Condition3

Ce qui se traduit en :

if ((Condition1 || Condition2 ) && !Condition3) { Action1(); }

Tu me prend par les sentiments.

GRAPHCET j'ai utilisé pour commander un bras robotisé ou un portail, jamais pour faire des calcules comme tu le suggère, simulé l'automate complet, IHM inclus, avant de l'utilisé n'est pas le but d'un tel langage. C'est par étape, interrogation etc... reproduire ce qui se passe dans une base de registre sans être formellement identique est surement possible...

[sergio_is_back]

Si, encore une fois, oui ! Je ne referais la roue. #include <math.h> c'est pour autre chose vue que les CPU ont des opérateurs non "surchargeable" avec leurs registres.

J'ai du mal à comprendre le sens exact de ta prose... Tu peux développer un peu ?

[sergio_is_back]

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

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

C'est vrai que j'apprécie le Pascal pour sa lisibilité, sa rapidité de compilation (en une seule passe), sa structuration en général
Je trouve que le fait de ne pas pouvoir déclarer une variable n'importe en milieu de code est un avantage en terme de "pensée"
on réfléchi à ce qu'on a besoin avant de débuter le corps de la fonction

Après il aussi ses inconvénients comme tous les langages, il est loin d'être parfait

[MikeRowSoft]

Lorsque je me suis renseigné sur les langages fonctionnelles dont mentionnais quelques commentaires précédent, j'ai lu qu'il était difficile lors du calcule de a++ + a++ d'avoir en même temps pour a initialement = 0 en mémoire 1 + 1, soit a à l'instant t et un parallélisation de a++ via l'opérateur + que pour la même valeur a soit en faite incrémenté qu'une seule fois sur la ligne de calcule de l'instant t.

Si je suis le principe que tu m'explique, c'est à l'instant t, a vos quelque chose et à t+1 vos autres choses vu que l'opérateur + n'est pas parallélisable en math. et encore moins à l'instant t avoir a qui vos deux valeurs (adresses mémoires).

Si tu as une valeur en mémoire, peut-tu savoir combien de pointeur il y a sur cette valeur ?

Sortie de l'informatique le problème persiste, c'est comme une femme qui a couché avec des jumeaux "parfait" et qui maintenant demande "qui est le père ?" au test de paternité.
a ou a en logique donne a. a+a en math donne 2.a .

[sergio_is_back]

Lorsque je me suis renseigné sur les langages fonctionnelles dont mentionnais quelques commentaires précédent, j'ai lu qu'il était difficile lors du calcule de a++ + a++ d'avoir en même temps pour a initialement = 0 en mémoire 1 + 1, soit a à l'instant t et un parallélisation de a++ via l'opérateur + que pour la même valeur a soit en faite incrémenté qu'une seule fois sur la ligne de calcule de l'instant t.

Si je suis le principe que tu m'explique, c'est à l'instant t, a vos quelque chose et à t+1 vos autres choses vu que l'opérateur + n'est pas parallélisable en math. et encore moins à l'instant t avoir a qui vos deux valeurs (adresses mémoires).

Si tu as une valeur en mémoire, peut-tu savoir combien de pointeur il y a sur cette valeur ?

Tu te fait bien des noeuds au cerveau....
Mais dans ce cas précis ça dépend évidement de la façon dont le compilateur "comprend" ton code :

Exemple A=1+1;
Avec mon compilateur ça donne ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Unit4.pas.29: A:=1+1;
004AB648 C745F802000000   mov [ebp-$08],$00000002

Note : Le pointeur des variables locales commence toujours à [ebp-8]

Tu remarquera que le compilateur a simplifié l'équation : pour lui A=1+1 est simplifié par A=2 donc pas besoin de 36 pointeurs pour affecter une
variable.

Avec un nombre flottant la représentation binaire est différente mais le résultat équivalent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Unit4.pas.29: A:=1+1;
004AB648 C745F800000040   mov [ebp-$08],$40000000

C'est différent pour faire A=A+1 (là c'est un incrémentation qui est considérée par le compilateur)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Unit4.pas.29: A:=A+1;
004AB648 FF45F8           inc dword ptr [ebp-$08]

Là aussi le compilateur n'a besoin que d'un seul pointeur

Idem avec A:=A+2;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Unit4.pas.29: A:=A+2;
004AB648 8345F802         add dword ptr [ebp-$08],$02

Si je suis le principe que tu m'explique, c'est à l'instant t, a vos quelque chose et à t+1 vos autres choses vu que l'opérateur + n'est pas parallélisable en math. et encore moins à l'instant t avoir a qui vos deux valeurs (adresses mémoires).

Dans ton exemple il ne peut pas y avoir deux adresses mémoire car une seule est suffisante

L'opérateur + n'est pas "parallélisable" dans ce cas précis car le processeur n'en a pas "besoin"

Ton exemple sur de simple additions n'est pas suffisamment représentatif de la parallélisation
Sur une formule mathématique plus complexe on verrait beaucoup plus de différences suivant la façon dont elle est écrite
par le développer et simplifiée par le compilateur et traitée ensuite par le compilateur.

Là on pourrait comparer le code généré par différents compilateur et leur efficacité

Les processeurs et compilateurs modernes essayent de paralléliser les opérations mais certaines ne
le sont pas, d'autres pourraient l'être mais ne sont pas écrites correctement par le développeur
et du coup ne le seront pas malgré tout même sur un langage hautement prévu pour cela...

Quand on veut écrire un rapide et "parallélisable" il faut d'abord ce poser la question de l'écriture
et donc du respect des règles du langage et ce quel que soit le langage employé

[MikeRowSoft]

Si 2 Core on accès en écriture en parallèle à des broches rassemblé sous a alors broches a = a++(via core A) + a*3 (via core B). a sur 8 bit si tu veux.
Je sais, je me prend le citron pour rien. mais cela fait parti de choses qui peuvent être demandé. C'est simplement qu'a l'instant t si a vaut une valeur, on n'en a pas besoin pour l'instant t+n.

Excuse moi de t'ennuyer. J'ai très bien compris ce que tu avance, je l'utilise de façon naturel aussi.
Merci de tes explications.

[sergio_is_back]

Je sais, je me prend le citron pour rien. mais cela fait parti de choses qui peuvent être demandé.

En bientôt 30 ans de développement en informatique on ne m'a jamais demandé de combien de pointeurs
j'avais besoin pour additionner deux nombres dans un langage X sur un processeur Y... avec un code
écrit par Z...

Si quelqu'un me pose un jour la question (à par si c'est pour développer un solution visant à résoudre le nombre 42), je lui répondrai, à l'instar d'un célèbre auvergnat, qu'il
en faut un certain nombre...voir un nombre certain...

[MikeRowSoft]

C'est comme moi, savoir que le compilateur ne va pas toujours transformer a = a++ + a++ en a = a + 1 + a + 1 puis a = 2a + 2 et enfin a = 2 si a vos initialement a = 0.

J'y pensais vraiment pas quand j'ai vue l'article wikipédia...

[wolinn]

C'est comme moi, savoir que le compilateur ne va pas toujours transformer a = a++ + a++ en a = a + 1 + a + 1 puis a = 2a + 2 et enfin a = 2 si a vos initialement a = 0.

J'y pensais vraiment pas quand j'ai vue l'article wikipédia...

Un programmeur qui m'écrirait ce genre de chose a intérêt à bien compter ses abattis et affuter ses arguments pour en justifier la nécessité s'il ne veut pas se faire voler dans les plumes.

[_Bérenger_]

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

Ce n'était pas mon argument. Ma question est la suivante: comment se fait-il que je ne trouve aucun article qui me démontre par expérience, qualités techniques ou pragmatiques la supériorité de Pascal/Eiffel/Ada ? Comment dois-je faire, en l'absence de ces ressources, pour me convaincre, et en convaincre d'autres, que ce sont les technos à adopter ?

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.

Pourtant il l'a fait ! Et avant de l'implémenter en C++ ! Pourquoi cela n'a-t'il pas pris ? Pourquoi Stepanov aurait décidé de se tourner vers un langage inférieur si tout était parfait en Ada (et ça n'est pas sous le coup d'un effet de mode, ceux qui connaissent un peu Stepanov ne devraient pas avoir de doute là-dessus)

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.

Mon champ de compétences est nettement plus limité: calcul scientifique et simulation numérique. Dans ce domaine, je suis absolument persuadé qu'Ada ne peut pas répondre aux problématiques de performance (SIMD, fork-join, distribué) du domaine. Peut-être est-ce possible dans l'absolu, mais pas en pratique parce il n'existe pas l'infrastructure compilateur intel/ openMP / MPI pour Ada. Du point de vue purement technique, je ne suis pas du tout convaincu que passer en Ada simplifierait le problème. À titre d'exemple, je ne connais pas de bibliothèque d'algèbre linéaire qui marche dans tous les cas qui m'intéressent (matrices de taille fixe, dense, creuse) sans perte de performance. À ma connaissance, pour de telles bibliothèques, soit l'API date de Fortran77 (BLAS), soit on a besoin du C++ avec expression template pour évalutation paresseuse. Peut-on faire des expression template en Ada ? Ou peut-on s'en passer tout en conservant une API qui ressemble à une expression mathématique ? Je ne pense pas (je ne dis pas que ça n'existe pas, mais ça m'étonne de n'en avoir jamais entendu parlé).

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.

C'est vrai que vu l'état du développement logiciel, votre équipe semble faire figure d'exception. Ça fait toujours plaisir d'entendre parler de projet où ça se passe bien, où tout n'est pas systématiquement bogué et ou le code est compréhensible. Cependant, je n'ai pas l'impression que cela vienne en premier lieu du langage de programmation. D'ailleurs vous le dites vous-même: ça marche également mieux que les autres équipes quel que soit le langage. Vous riiez du fait que l'on semble incapable de former les développeurs sur le F-35. Et vous avez raison, mais c'est pourtant la norme : on veut développer des projets en supposant que la majorité des gens est déjà formée... alors que bien sûr ils ne le sont pas, ni en Ada, ni en C/C++, ni en rien. Ne serait-ce pas plutôt là votre avantage compétitif ?

- sur C++, le maître lui-même, notre vénéré Stroustrup:
" C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, it blows away your whole leg".
Sérieusement, si l'inventeur du langage dit des choses comme cela, comment peut-on s'en servir pour des développements industriels avec des contraintes de délais, de charge, de budget, avec les développeurs que l'on a et pas ceux qu'on aimerait avoir?

Oui enfin contrairement à Stroustrup qui reconnait les lacunes de son langage et a passé 30 de sa vie à l'améliorer, je ne suis pas bien sûr que recoder du Pascal en Modula, Modula-2, Oberon, Oberon-2, puis Oberon-07 soit bien plus productif.

[Luc Hermitte]

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.

Ces deux langages se rejoignent sur les UB, et c'est généralement ce que l'on reproche: de ne pas spécifier le comportement dans certains cas aux limites tout ça pour permettre plus de performances. D'autres langages/projets vont faire le choix de programmation excessivement défensive, d'autres s'outilleront en mélange de programmation par contrat et de preuve formelle. Le C++ essaie d'aller dans cette direction, mais c'est lent. Les outils ont fait des progrès grâce à l'écosystème llvm/clang (ou plus exactement, on commence à voir des outils simples en prendre en main, et gratuits ou libres, en C et/ou C++), mais il reste beaucoup de chemin à parcourir.

Cependant, C et C++ s'éloignent drastiquement quant aux bonnes pratiques à mettre en oeuvre. En C, il faut pratiquement un test toutes les deux lignes pour propager des erreurs et s'assurer de bien nettoyer les ressources. En C++, il y a les exceptions, et les bonnes pratiques du C ne sont plus utilisables. Cf le RAII & cie.

C'est en cela que je réfute qu'il s'agit du même langage: ils doivent être manipulés de façons différentes. Seulement, j'admets volontiers que cette distinction passe à la trappe chez beaucoup et que de fait, on se retrouve avec cet abominable mélange qu'est le C/C++ et des dettes techniques qui s'empilent.

Toujours est-il que sur un des mes derniers projets en C++, démarré pratiquement de 0 (hormis des dépendances à des bibliothèques tierces C++ imposées), nous n'avons pas eu de problématique typique due à une mauvaise gestion des ressources, ou autre UB. Dès le début nous sommes partis en 100% RAII et autres "techniques" modernes, et nos bugs étaient des bugs métiers, pas des bugs dus à une mauvaise utilisation du langage. Le projet a juste été bien cadré dès le début. Maintenant, c'est sûr que l'on ne va pas intégrer un nouveau développeur sans le former au C++ -- chose qui ne devrait choquer personne et qui pourtant colle rarement à la réalité des projets.

[Invité]

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

Et alors ? Ça ne prouve absolument pas que le C++ est la raison de l'échec du F35. Le F35 a accumulé les problèmes tant matériels que logiciels donc c'est normal qu'il y en ait aussi dans le code C++. C'est comme dire que puisque les documents sont rédigés en anglais alors l'anglais est source d'erreurs : écrivez en catalan !

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

Pourquoi tu ne cites pas celle-ci plutôt : "There are only two kinds of languages: the ones people complain about and the ones nobody uses" (il y a seulement deux types de langages: ceux dont tout le monde se plaint et ceux que personne n'utilise) https://www.quotes.net/quote/53251 ?

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

Tu mélanges les concepts avec les outils pour les mettre en oeuvre. Andrew Tanenbaum a également beaucoup critiqué l'aspect monolithique des Unix mais il a quand même codé Minix en C.

Bref, tu as peut-être raison sur certains points mais à mes yeux ton discours n'a aucune valeur car c'est soit ton témoignage sur ton travail génial pendant que les autres font de la merde soit quelques "preuves" qui n'en sont en fait pas du tout.

[thierryc]

re-bonjour Bérenger,
Tout d'abord, permettez-moi de vous féliciter pour votre travail et votre domaine de recherches qui doit être passionnant. Egalement, je suis très heureux de discuter avec vous, cet échange me paraissant cordial et fructueux. Peut-être en est-il de même pour vous?

Je vais essayer de réponde à la question "pourquoi pas Ada?", qui n'est pas vraiment la question de fil de discussion, mais qui en dérive quand même

Ce n'était pas mon argument. Ma question est la suivante: comment se fait-il que je ne trouve aucun article qui me démontre par expérience, qualités techniques ou pragmatiques la supériorité de Pascal/Eiffel/Ada ? Comment dois-je faire, en l'absence de ces ressources, pour me convaincre, et en convaincre d'autres, que ce sont les technos à adopter ?

Tout d'abord, les sources sur Ada:
- Adalog : http://www.adalog.fr/fr/adalog.html, C'est le site de notre ami Jean-Pierre Rosen, spécialiste Européen de l'Ada, et membre du comité pour la spécification Ada 2020. Rien ne se fait en Ada sans lui. Tu y trouveras de nombreuses références.
- GetAdaNow: http://getadanow.com/ C'est un site qui explique pourquoi et comment transitionner à Ada, et tous les avantages y afférent.

Sur Pascal, c'est le site de Delphi qu'il faut aller voir:
- https://www.barnsten.com/fr/developm...ols/rad-studio : c'est l'ultime en matière de développement rapide, le langage le plus orienté-composant qui soit.
ou bien le site du "Free Pascal Compiler" et de "Lazarus" pour qui préfère du libre
- https://www.lazarus-ide.org/
les deux environnement sont plus ou moins compatibles, il faut mettre en place des règles strictes pour assurer la portabilité si c'est un besoin. FPC et Lazarus compilent sur une quantité incroyable de plateformes et systèmes d'exploitation.

Sur Eiffel :
- https://www.eiffel.com/, tout simplement.

Quelques références de projets récents en Ada moderne:
- Rosetta : 100% du source en Ada,
- A400M : une prédominance d'Ada,
- Ariane 6 : la décision a été prise de réaliser son logiciel 100% en Ada 2012 (publié au congrès Ada Europe de Madrid, je crois),

Sur Pascal et Eiffel, tu trouveras des références équivalentes. En cherchant.

Pourtant il l'a fait

Es-tu sûr de ton URL? En as-tu une autre à me proposer? Moi, je n'ai pas réussi à trouver la référence.

Mon champ de compétences est nettement plus limité: calcul scientifique et simulation numérique. Dans ce domaine, je suis absolument persuadé qu'Ada ne peut pas répondre aux problématiques de performance (SIMD, fork-join, distribué) du domaine. Peut-être est-ce possible dans l'absolu, mais pas en pratique parce il n'existe pas l'infrastructure compilateur intel/ openMP / MPI pour Ada. Du point de vue purement technique, je ne suis pas du tout convaincu que passer en Ada simplifierait le problème. À titre d'exemple, je ne connais pas de bibliothèque d'algèbre linéaire qui marche dans tous les cas qui m'intéressent (matrices de taille fixe, dense, creuse) sans perte de performance. À ma connaissance, pour de telles bibliothèques, soit l'API date de Fortran77 (BLAS), soit on a besoin du C++ avec expression template pour évalutation paresseuse. Peut-on faire des expression template en Ada ? Ou peut-on s'en passer tout en conservant une API qui ressemble à une expression mathématique ? Je ne pense pas (je ne dis pas que ça n'existe pas, mais ça m'étonne de n'en avoir jamais entendu parlé).

- Toutes les bibliothèques C/C++ sont accessibles en Ada sans pertes de performances. Pour faciliter la vie, GNAT (le compilateur ADA, basé sur GCC) génère maintenant des spécifications Ada à partir des entêtes .h des bibliothèques. Cela facilite l'intégration. Idem pour le Pascal. Pour l'avoir fait moi-même, j'ai travaillé sur du Pascal distribué. Pas de difficultés particulières.
- il existe des bibliothèques Ada de calcul scientifique. Sont-elles adaptées à tes besoins. A toi de regarder...
- "tu es persuadé..." : là, je ne peux rien pour toi, c'est à toi d'avoir une réflexion approfondie sur tes besoins et éventuellement remettre en cause tes "mauvaises" pratiques ;-)
- les génériques Ada sont bien meilleures que celles du C++, tu n'auras aucun mal à avoir du source qui ressemble à une expression mathématique. Ou en Pascal. Ou en Eiffel.
- dans tous les cas, la performance vient bien de la conception de l'algorithme, pas des astuces du langage.
- si quelque chose te manque toujours après tout cela, tu peux en parler à Jean-Pierre Rosen : les discussions pour la spécification d'Ada 2020 viennent de commencer et il me dit que le calcul scientifique est au menu.

Cependant, je n'ai pas l'impression que cela vienne en premier lieu du langage de programmation. D'ailleurs vous le dites vous-même: ça marche également mieux que les autres équipes quel que soit le langage. Vous riiez du fait que l'on semble incapable de former les développeurs sur le F-35. Et vous avez raison, mais c'est pourtant la norme : on veut développer des projets en supposant que la majorité des gens est déjà formée... alors que bien sûr ils ne le sont pas, ni en Ada, ni en C/C++, ni en rien. Ne serait-ce pas plutôt là votre avantage compétitif ?

Je vous remercie pour votre compliment. C'est indubitablement un avantage que d'être un directeur de projet capable de former ses propres troupes. Ceci dit, comme tout chef, je tente de m'assurer de tous les avantages avant de partir au combat. S'il m'est toujours possible de former une équipe, il m'est beaucoup plus facile de former une équipe qui programmera en Ada ou en Eiffel ou en Pascal qu'en C++/Java. Tout simplement, le nombre de jours de formation est moins long, et la courbe de montée en capacité bien meilleure. Bien sûr, le programme de formation et très complet et la partie strictement langage ne nécessite que 3 jours. L'approche composant nécessite elle aussi 3 jours. UML en nécessite 5. L'intégration UML et la génération de source, entre 3 et 5 suivant la proportion de source généré par rapport au source écrit à la main. La gestion de configuration, 1 à 2 jours. Les tests unitaires, 1 à 2 jours, la revue de code, 1 à 2 jours, l'écriture de cahier des charges, 3 jours, etc. Qui ne voudrait profiter de ces avantages? Si je perds des développeurs (c'est arrivé, les jeunes gens bien formés ont envie d'aller voir ailleurs ou de construire leur propre "jeune pousse"), il m'est plus facile d'en intégrer d'autres. Par ailleurs, avec ces langages et ce niveau de formation, mes équipes n'ont pas besoin de 100% d'ingénieurs, mais je peux faire un panachage entre des universitaires, des ingénieurs et des techniciens. L'ensemble est en fait plus efficace qui si tous les profils se ressemblent. La diversité est plus productive. (et les discussions autour de la machine à café :-)).

Ce qui est terrible avec le F-35, alors que nos amis étasuniens ont toujours des ressources financières extraordinaires, c'est qu'ils ont choisi le langage en fonction du "pool" de développeurs au lieu de choisir le langage (et la méthode, etc) en fonction de leur besoins et d'ensuite former les équipes proprement. Des fois, je rêve de ce que j'aurais pu faire avec mon équipe d'alors avec de tels moyens...

Oui enfin contrairement à Stroustrup qui reconnait les lacunes de son langage et a passé 30 de sa vie à l'améliorer, je ne suis pas bien sûr que recoder du Pascal en Modula, Modula-2, Oberon, Oberon-2, puis Oberon-07 soit bien plus productif.

Niklaus Wirth est un chercheur. Nous ne l'avons pas suivi partout, mais il faut lui être reconnaissant de nous avoir montré nos limites et de voir plus loin. "Voir sur les épaules des Géants", disait Darwin. Pour moi, Active Oberon reste un exemple inégalé de programmation économe, efficace, modulaire et réutilisable. Son livre est une merveille à lire, et on remet en cause toutes ses pratiques à sa lecture (https://www.amazon.com/Project-Obero.../dp/0201544288).

Antoine de Saint Exupéry écrivait "Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher" http://dicocitations.lemonde.fr/cita...tion-28697.php. Peut-être Niklaus a-t-il lu Antoine, en tout cas, il a bien suivi la démarche.
C'est d'ailleurs une excellent maxime à suivre sur ses propres projets. Ne pas hésiter à couper dans la conception, dans les sources inutiles, dans les exigences de pur confort, etc.

Si tu choisis Ada, Pascal ou Eiffel, tiens-toi y, ces langages évoluent et intègrent les évolutions modernes de l'informatique tout en respectant leur intégrité fondamentale.
Si tu choisis Oberon, ce sera une belle aventure, et je suis convaincu que tu y réussirais avec panache, après les difficultés initiales de la transition.

Stroustrup n'a jamais réussi à améliorer son langage. C'est là la grande différence avec Niklaus Wirth. Tout ce qu'il à réussi à faire, c'est à le complexifier (voir plus haut, A. de Saint Exupéry)

Amicalement,
Thierryc

[thierryc]

Bonjour Simon,
Merci pour ta contribution.

Et alors ? Ça ne prouve absolument pas que le C++ est la raison de l'échec du F35.

As-tu lu la phrase sur la raison du choix du C++? Pourquoi voudrais-tu que le directeur du programme F-35 qui est dans la mouise la plus totale admettrait-il plus qu'à demi-mot que ses équipes se sont gourées sur tout...

Pourquoi tu ne cites pas celle-ci plutôt : "There are only two kinds of languages: the ones people complain about and the ones nobody uses" (il y a seulement deux types de langages: ceux dont tout le monde se plaint et ceux que personne n'utilise) https://www.quotes.net/quote/53251 ?

Parce que Stroustrup s'aventure là où il ne connait pas. Sa spécialité, c'est le C++. Dans un post, je référence des projets industriels, de très grande envergure, réalisés en Ada, et très récents. Cette citation est donc erronée. Ceci dit, c'est loin d'être la seule erreur de Stroustrup, ni sa plus grave...

[...] (en parlant d'Active Oberon)
Tu mélanges les concepts avec les outils pour les mettre en oeuvre. Andrew Tanenbaum a également beaucoup critiqué l'aspect monolithique des Unix mais il a quand même codé Minix en C.

Fais tes recherches, compare la taille et les fonctionnalités d'Active Oberon avec la taille et les fonctionnalités de Minix...
Ce que Niklaus a démontré au travers de l'exemple d'Obéron, c'était qu'il n'était nul besoin d'un langage de bas niveau pour programmer un système d'exploitation.
Il n'y a aucun mélange, mais une démonstration scientifique.

Bref, tu as peut-être raison sur certains points mais à mes yeux ton discours n'a aucune valeur car c'est soit ton témoignage sur ton travail génial pendant que les autres font de la merde soit quelques "preuves" qui n'en sont en fait pas du tout.

Cf. un autre de mes posts plus haut. Je n'ai pas travaillé sur Rosetta, ni sur A400M, ni sur Active Oberon, ni sur plein d'autres références citées. Ce sont bien des preuves car ce sont autant de projets brillamment réussis, et pas seulement mon propre témoignage.
Mon témoignage vaut ce qu'il vaut, tu es entièrement libre d'y croire ou pas.
En revanche, je n'ai pas écrit que le C/C++/Java était de la "merde" (ça c'est toi qui l'écris). J'ai écrit que C/C++/Java avaient des défauts majeurs. J'en ai décrit au moins 2, et la raison pour laquelle c'étaient de graves défauts. J'ai également bien écrit que choisir C/C++/Java sur des nouveaux projets en 2018 devrait relever de la faute professionnelle lourde, au vu des alternatives disponibles, seules ou en combinaison.
Pour moi, les développeurs C/C++/Java sont des victimes, à plaindre et non pas à blâmer. Le plus terrible, ce que beaucoup d'entre eux (elles?) sont ignorantes de ce que l'on leur fait subir. Et qu'il y a de nombreuses écoles de "développeurs/hackers" qui promeuvent et transmettent à la jeune génération de détestables habitudes.