A0698 Les langages orientés objet ne sont pas assez sémantiques et c'est dramatique

A première vue, c'est sympathique: avec les langages orientés objet on modélise le monde en définissant des classes d'objets, qui déclarent les attributs des objets, formant des triplets ou prédicats de fort bon goût:

Paul.age = 43
Pierre.chef = Paul

Un bon matériau pour installer toutes les capacités de la programmation logique ou des réseaux / graphes sémantiques.

Mais bien sûr il n'en est rien. Demander par exemple la liste de toutes les personnes ayant 43 ans, qui pourrait s'écrire: (détails de syntaxe mis à part)

X Classe Personne
X age 43

est hors de question   (Ça m'intéresserait d'ailleurs bien de savoir comment on fait en pratique ... Ce que j'ai vu d'approchant dans des codes industriels est une pure horreur, mais il y a surement des experts en élégance !)

Un autre  malheur est que, pour animer tout ces objets, il faut d'une part construire des objets et d'autre part leur appliquer des méthodes, ceux deux choses ayant la forme d'une simpliste suite de paramètres:

Objet.Methode (P1, P2, P3, P4)

 ou

Classe (P1,P2,P3)

Cela est d'une pauvreté innommable, - c'est le moins qu'on puisse dire.

La sémantique des différents paramètres n'est donnée que par leur position dans la liste..., donc par une information  connue de la seule tête du programmeur et totalement absente du code du programme. Au moins en COBOL chaque zone de données avait un nom.

Le minimum quand même serait que les appels de méthodes ou de constructeurs soient considérés comme des objets eux-mêmes, dans lesquels on dirait de manière articulée et exploitable que le premier paramètre est la  pression de tel tuyau, le second le prix d'achat d'un kilo de sel, le troisième le nom du cheval, etc ... (auquel cas l'ordre n'aurait évidemment aucune importance, alors qu'il est la clé de tout ici)

Les paramètres ont bien un nom à l'intérieur, mais pas à l'extérieur . Or, comme chacun sait depuis les années 1960, la clé du génie logiciel est la description externe et non interne des entrées et sorties d'un module ou composant.

Comme illustration de ces exigences minimales non satisfaites, voilà ce que disent les premières pages d'un cours Java  à nos chères têtes blondes pour leur faire aimer l'informatique, -pardon le "codage"-:

Attention il vous faudra respecter scrupuleusement l'ordre des paramètres passés lors de l'initialisation de votre objet : sinon, c'est l'erreur de compilation à coup sûr ! Ainsi :

//L'ordre est respecté -> aucun souci


Ville ville1 = new Ville("Marseille", 123456789, "France");


//Erreur dans l'ordre des paramètres -> erreur de compilation au final


Ville ville2 = new Ville(12456, "France", "Lille");

Dans cette lamentable absence  de sémantique dans les langages orientés objet (utilisés dans 95% des applications actuelles) se  trouve la source:

-- de la répulsion croissante des jeunes pour la programmation
-- de l'éternelle "crise du logiciel" (expression créée en  1968 par Edsger Dijkstra) et des catastrophes informatiques et financières qui en découlent
-- de l'extrême difficulté de passer d'une spécification en langage naturel à un codage informatique. (et de l'impossibilité totale d'effectuer le chemin inverse ...)

NB: l'extrait ci-dessus vient d'un endroit où vous trouverez bien d'autres passages désopilants ou repoussants:

https://openclassrooms.com/courses/apprenez-a-programmer-en-java/votre-premiere-classe

(trouvé en tête des résultats Google hors publicité)

Il y a des jours où je me dis  que les langages de programmation usuels sont manipulés par une bande de complotistes  ennemis du progrès technique.
.