Ada et popularité

[Mad666]

Envoyé par Zerte

Problablement que cette personne voulait dire la chose suivante: avec la syntaxe d'Ada, de grandes portions de ton code devraient être compréhensibles sans devoir ajouter de commentaires.

C'est probable, en effet.

Envoyé par Zerte

La personne a été en effet imprécise et aurait dû dire: "Les compilateurs Ada sont très verbeux et les messages d'erreur et exceptions sont très clairs, à l'exception d'un compilateur, s'agissant des messages exceptions par défaut".

Merci pour cette précision.

Je garde ton exemple de code pour rendre lisible les exceptions non gérées avec Gnat. Effectivement, il y avait deux options à passer à la chaîne de compilation. Merci.

[Zerte]

Envoyé par Mad666

Merci pour cette précision.

De rien. On pourrait évidemment se demander pourquoi Adacore ne met pas par défaut dans le run-time de GNAT ces quelques lignes. Cette astuce fonctionne pourtant depuis la version 3.13 de GNAT (sortie vers 2000)...

[Mad666]

Envoyé par Zerte

De rien. On pourrait évidemment se demander pourquoi Adacore ne met pas par défaut dans le run-time de GNAT ces quelques lignes. Cette astuce fonctionne pourtant depuis la version 3.13 de GNAT (sortie vers 2000)...

Pour le code, je ne sais pas. Par contre, pour les options de compilation, certainement pour des soucis de performance.
Du coup, comme l'un ne va pas sans l'autre...

[Blackknight]

1/ Ada est un langage auto-documenté.
Mon avis : faux, puisque, pour générer de la documentation, il faut écrire des commentaires dans le code source, finalement comme en Java.

Auto-documenté ne veut pas dire que l'on peut générer la documentation directement à partir du code mais uniquement que certaines choses n'ont même pas besoin d'être commentées pour être explicites.
Le premier exemple qui me vient à l'esprit est celui des contraintes de valeur d'un type. C, C++, Java ou C# laissent l'entière responsabilité de la validité des plages de valeur au développeur. Cela a pour conséquence de voir, dans certains sources, une quantité non négligeable de commentaires et de tests traitant de ce point... Quand c'est fait

2/ Les compilateurs Ada sont très verbeux et les messages d'erreur et exceptions sont très clairs.
Mon avis : après avoir codé quelques exemples dans ma formation de la semaine dernière, je me suis, bien entendu, pris des "Constraint Error" et "Program Error" en bonne et due forme et ... rien d'autre. En fait, il faut activer les informations de debug et je ne sais plus quoi d'autre pour avoir la pile d'appel en hexadécimal, puis passer par un programme extérieur pour les rendre intelligibles (i.e. obtenir le numéro de ligne du code dans lequel est survenue l'exception) ou alors se coder un logger, lequel sera appelé dans tous les "traite-exception" et, en particulier dans les "when others". Très développeur friendly et efficace ...

Pour les exceptions, cela n'a rien à voir avec le compilateur mais avec l'exécution du programme et avec un défaut dans sa conception.
On est ici dans le cas d'un langage compilé et natif comme le C/C++, pas d'un langage tournant dans une machine virtuelle. En C/C++, il se passe la même chose avec, habituellement, un magnifique segmentation fault suivi d'un core dump. Dans ce cas, il faut aussi activer les informations de debug et lancer un outil dédié style gdb ou ddd. D'ailleurs, la situation est identique quelque soit l'OS.

Certes en Java, cela aurait provoqué une exception de type ArrayOutOfBounds, NullPointerException, OutOfMemory ou autre et le programme aurait continué à faire semblant de fonctionner... Est-ce vraiment ce que l'on veut ? A fortiori, dans un équipement embarqué ?
Qui plus est, la stacktrace de 25000 lignes (si si, j'en ai vu grâce à Spring et autres joyeusetés) n'est pas toujours non plus des plus évidentes à utiliser et nécessite l'inclusion dans le code généré de tous les symboles de debogage, ce que fait Java par défaut contrairement au C/C++ et Ada. C'est utile mais cela a un coup non négligeable en termes de performance.
Mais bon, c'est quand même bien parce que ça permet le désassemblage (avec JD gui (http://java.decompiler.free.fr/?q=jdgui) sans douleur dans une grande majorité des cas

Pour revenir au compilateur et à sa verbosité, il n'y a que très peu de temps que les compilateurs C/C++ sont capables de fournir des messages d'un niveau équivalent à celui d'Ada. Exemple :

Code :

1
2
3
4
5
6
7
8
9
10
with Ada.Text_Io; use Ada.Text_Io;

procedure Test is

   type My_Int is range 12..42;

   Ma_Var : My_Itn := 11;
begin
   Put_Line("Ma var =" & My_Int'Image(Ma_Var));
end Test;

qui après tentative de compilation donne

Code :

1
2
3
4
5
fred@freddy:~/perso/Ada $ gnatmake test.adb
gcc-4.6 -c test.adb
test.adb:7:13: "My_Itn" is undefined
test.adb:7:13: possible misspelling of "My_Int"
gnatmake: "test.adb" compilation error

Après correction de My_Itn en My_Int, le compilateur donnera

Code :

1
2
3
4
5
6
fred@freddy:/perso/Ada $ gnatmake test.adb
gcc-4.6 -c test.adb
test.adb:7:23: warning: value not in range of type "My_Int" defined at line 5
test.adb:7:23: warning: "Constraint_Error" will be raised at run time
gnatbind -x test.ali
gnatlink test.ali

Si ça, c'est pas du luxe !!! Le compilateur accepte le programme mais prévient bel et bien qu'il y aura un envoi d'exception à l'exécution.
Je parle bien ici du compilateur, pas d'un IDE comme Eclipse qui est censé empêcher ces problèmes-là en amont.

Allez on continue. En Ada, il existe un package standard permettant d'obtenir plus d'informations sur l'exception, Ada.Exceptions. Si on modifie le programme précédent commme suit :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
with Ada.Text_Io; use Ada.Text_Io;
with Ada.Exceptions; use Ada.Exceptions;

procedure Test is

   type My_Int is range 12..42;

   Ma_Var : My_Int := 11;
begin
   Put_Line("Ma var =" & My_Int'Image(Ma_Var));
   
exception
   when Error : others =>
      Put_Line (Exception_Information(Error));
end Test;

La compilation fournit les mêmes messages que précédemment mais l'exécution renvoie ceci :

Code :

1
2
3
fred@freddy:/perso/Ada $ ./test

raised CONSTRAINT_ERROR : test.adb:8 range check failed

Et ça tombe plutôt bien vu que la ligne 8 est effectivement celle qui pose problème.
Alors oui, la solution fournie par Zerte correspond bien au comportement Java qui est de lancer une pile mais Ada.exceptions est un mécanisme standard que les compilateurs adhérents à la norme doivent implémenter. Pour être totalement honnête, il y a quand même un bémol. La norme ne précise pas que la ligne de code fautive doit être fournie.

Note : je ne vise pas les personnes qui ont affirmé ces deux points. Pour moi, il s'agit d'un manque du langage, point, sans viser qui que ce soit.

Certes mais il faut aussi avoir bien pratiquer le langage et bien le connaître avant de pouvoir dire : "Ca, on ne peut pas le faire".
D'ailleurs, si les bibliothèques liées au Web ne sont pas dans la norme, il y a toujours moyen de se débrouiller. Il suffit d'aller regarder le site V2P dont le code source est disponible sur Google code .

Alors oui, c'est vrai, Ada n'est pas populaire, on ne trouve pas autant de développeurs que pour Java (ou Javascript, mon Dieu !!) mais ceux que l'on trouve sont extrèmement compétents, il suffit d'aller faire un tour sur le newsgroup comp.lang.ada pour s'en rendre compte.
A chacun de voir s'il veut résister aux sirènes de la mode et faire un programme qui fonctionne ou s'il préfère s'attirer la sympathie du public avec une technologie hype.
Dans le dernier cas, je recommande chaudement Ruby on Rails et la lecture de l'excellente suite d'articles sur la création de pages statiques sur Linuxfr

[Mad666]

Bonjour Blackknight et merci beaucoup pour cette réponse argumentée !

Je me permettrai seulement de préciser le point suivant :

Envoyé par Blackknight

(...)
Certes mais il faut aussi avoir bien pratiquer le langage et bien le connaître avant de pouvoir dire : "Ca, on ne peut pas le faire".
D'ailleurs, si les bibliothèques liées au Web ne sont pas dans la norme, il y a toujours moyen de se débrouiller. Il suffit d'aller regarder le site V2P dont le code source est disponible sur Google code .
(...)

Concernant l'affirmation, j'ai demandé à quelques personnes développant en Ada depuis quelques (dizaines) d'années avant de l'écrire. Bien entendu, une exception non souhaitée vient d'un logiciel avec un problème latent mais ça n'empêche qu'il me semble important de pouvoir corriger un logiciel qui ne plante ne serait-ce qu'une fois par an dans les mains de ses utilisateurs.
Ceci est donc plus aisé quand on connaît le lieu de genèse du problème.

Enfin, et encore une fois, merci pour le nouvel exemple de logiciel Ada "grand public".

[Zerte]

Encore un point à préciser: l'aspect auto-documentation ne concerne pas seulement le "code" (moins besoin de commenter, pas besoin de décrire les algos avec du pseudo-code), mais aussi la spécification. J'ai eu un cas concret il y a qqes jours, lors d'une séance de travail: qqn a dit "Il faudrait encore que Zerte couche sur papier une spécification", et Zerte a envoyé illico la spécification (package ZZZ is ...) par mail: voilà, vous l'avez les amis .

[Mad666]

Bonjour !

C'est que les spécifications Ada, comme les ".h" du C sont très intéressant de
ce point de vue.

[Zerte]

Envoyé par Mad666

C'est que les spécifications Ada, comme les ".h" du C sont très intéressant de
ce point de vue.

Evidemment on peut avoir de tout dans une spécification, et tout n'est pas forcément bon à être envoyé comme document de spécification. Avec un ".h" il peut y avoir quelques difficultés de lecture supplémentaires de la part de personnes non-spécialistes s'il y a trop de contenu style "macro-assembleur" (des #ifdef etc.).

[Mad666]

C'est juste.
En fait, je verrais bien la chose dans l'autre sens, ce qui aurait beaucoup plus d'intérêt selon moi : document écrit pratiquement en anglais naturel, avec quelques mots clés bien placés, devrait pouvoir permettre de générer une spécification Ada d'une manière ridiculement aisée.