Ca, c'est une définition trop forte. Pour moi, le code mort, c'est un code dont le programmeur à la conviction qu'il ne sera jamais exécuté, mais qu'il met quand même, pour éviter les mauvaises surprises.
La DO178 (qui est utilisée pour l'avionique critique), fait une distinction entre deactivated code et deadcode. Ce dont tu parles entre dans la catégorie deactivated.
Par exemple un traitement d'exception que l'on mets au cas ou, ou un if dépendant d'un booléen de configuration dont une des branches ne sera jamais exécuté dans cette configuration là. Le deactivated code n'est volontairement pas exécuté.
Le dead code n'est pas non plus exécuté, mais c'est par erreur, souvent détectable par les outils d'analyse statique, du genre :
if i > 10 then
if i < 3 then
-- dead code
end if;
end if;
Je sais, c'est énorme ce que je vais dire, mais je trouve qu'une news sur les langages qui ne s'enflamme pas à plus de 300 mails, c'est un peu faiblard : -)
"pure objet" n'était pas une qualité, c'est juste une caractéristique.
La grande erreur des années 80, ca a été justement de croire que tout était classe et objet. Je le reconnai : ramener tout à une poignée de concepts simples et universels, c'est tentant. Quelle "conceptual integrity"!
D'un point de vue marketing aussi, c'était intéressant : tout truc qui n'est pas "full quelque chose" semble louche d'emblée, avant même que l'on sache de quoi il retourne.
J'invite les passionnés à lire le papier http://acmqueue.com/modules.php?name=Content&pa=showpage&pi(...)
Il explique comment les langages C++ et Java se sont tirés une balle dans le pied en confiant les prérogatives des modules et des classes aux seules classes. [1]
Smalltalk, Ada, Modula ou OCaml n'ont pas eu à souffrir de la limitation "tout est objet" (que les spécialistes respectifs confirment), et ne s'en portent pas plus mal. [2]
Ce phénomène n'a pas tappé qu'au niveau langage, UML (à travers OMT) en a fait les frais également. Quelle absudité par exemple que ces classes ayant le stéréotype "utility", dont la principale caractéristique est de ne pas être des classes.
Tout ca pour dire qu'il n'y a pas de quoi conclure sur la supériorité d'un langage "pure objet". Trop souvent, il serait mieux caractérisé par "seulement objet".
PS pour David : un bon mail se fait en deux temps :
[1] tu énerves ceux qui sont déja là, et
[2] tu fais venir les autres! :-)
Ca fait longtemps que je me demande pourquoi la JVM n'est pas un simple backend de gcc, au meme titre qu'un autre processeur?
C'est stupide comme objectif, ou ca pose des pbs techniques insolubles?
Je ne crois pas que l'argument de l'OS ou de l'outillage soit sincère. Il s'agit juste d'une excuse pour se débarasser d'Ada. Personne ne t'oblige a créer ou maintenir ton propre éxecutif. Ca n'a rien à voir avec Ada.
Et il y a des environnement Ada de grande qualité pour le développement temps réel (certains sont même multi langage) comme ceux de Green Hills, DDCI, et même celui d'ACT sous GPL.
Voyons les choses avec sincérité : le plus souvent, Ada est abandonné parce que personne ne se pose de question de coût global, qu'on a déja plein de problèmes a régler, et donc on va vers la facilité. Tout cela sur fond d'inconscience de la part énorme du cout logiciel, en particulier dans le spacial ou il n'y a pas de série. J'ai entendu ces témoignages à de multiple reprise.
Jusqu'à l'absurde dans le cas de Dassault Aviation : ils maintenaient leurs propres outils Ada, compilateur inclus. Evidemment le coût était énorme. Pour le Rafale, au lieu d'abandonner la maintenance de leurs outils, ils ont abandonné Ada. Et pour être bien sur que ce soit une catastrophe économique, ils ont remplacé Ada par C++.
Et si je parle d'absurdité, c'est parce que parallèlement, ils n'ont pas eu peur du coût énorme de développement d'un calculateur avec un hard propriétaire.
Les choses peuvent être très simple : Ada est le seul langage qui vienne avec un éxecutif temps-réel. Dans le spacial ou l'avionique, c'est tout bénef, car je n'ai LE PLUS SOUVENT pas besoin d'OS. Je n'ai pas a payer de license Lynx/VxWorks ou tout ce que tu veux.
Je ne vais pas parler des solutions sur étagères de Aonix/ACT/DDCI/GreenHills/etc. Prenons tout de suite le cas le pire : mon hard est maison, et je n'ai pas de compilo Ada :
1 - j'ai vécu ça chez Matra Défense. L'adaptation de l'executif du compilo à notre hard tenait en deux dizaines de lignes d'assembleurs (adaptation de la gestion des IT et du timer). Le cout de ce source est négligeable en regard du projet. Après, on avait tout Ada de dispo sur notre cible, en particulier tout le tasking.
2 - si tu choisi C, tu aura de toute façon le cout d'adaptation de VxWorks ou autre. Et ce sera pire.
Petite note : le langage (ou le typage) n'est pas ultra-rigide, il est ultra-puissant. Rien ne t'empèche en Ada de mettre des Integer partout si tu ne veux pas profiter de cette puissance. Mais bien sur ce serait stupide.
La facilité d'apprentissage est bien ce que je voulais mettre en avant. Commencer en Ada, c'est écrire une procédure avec une syntaxe Pascalienne :
with Ada.Text_IO;
procedure Hello_Word is
begin
Ada.Text_IO.Put_Line ("Hello Word!");
end Hello_Word;
Pas de quoi surchauffer.
Je donne deux illustration :
- sur mon projet (une ligne de produit d'un demi-million de ligne de code chez Thales Communications), nous intégrons des gars qui ne connaissent pas Ada avec un cout d'apprentissage du langage réel, mais anecdotique à coté de celui du domaine (qu'il a de toute façon). En fait, nous avons été les premiers surpris de celà. Le langage est lisible et sécurisant, donc les gars rentrent dedans progressivement, sans rendre le produit instable.
- autre exemple dans l'éducation (que je cite de mémoire). Il me semble que c'est Michael Feldmann de la Georges Washington University qui concluait ses cours d'informatique par la réalisation d'un projet (un système de gestion de trains et d'aiguillage). Il laissait le choix du langage aux groupes d'élèves. Ceux qui choisissait Ada finissait plus souvent leur projet que les autres. Et en particulier, aucun groupe ayant choisit C n'a jamais atteind les objectifs.
Le témoignage est quelque part sur le web.
Attention à la confusion habituelle entre sémantique de haut niveau, et programmation de bas niveau.
Il n'y a pas de contradiction, ce n'est tout simplement pas la même chose.
Illustration du niveau sémantique du langage. Je veux décaler des éléments d'un tableau a :
en Ada :
a (5..7) := a (10..12);
Je fait une affectation avec une syntaxe de haut niveau. Mon intention est clairement exprimée par le code, le compilateur vérifie à la compilation que j'affecte bien une tranche de tableau dans une autre de même taille, et que tout tombe bien dans le tableau, sans débordement.
en C :
memcpy(a+5, a+10, 3*sizeof(*a))
Je ne manipule plus un tableau, mais de la mémoire : le niveau sémantique est plus bas. Accessoirement, cela réduit les possibilités d'optimisation du compilateur. Mais surtout, c'est illisible, et pour les contrôles, tiens, fumes!
Si je dois écrire la gestion de la mémoire d'un OS, on voit tout de suite avec lequel des deux langages le code sera le plus limpide.
Ceci montre qu'une sémantique de haut niveau est parfaitement indiquée pour faire de la programmation de bas niveau.
Maintenant, parlons de la programmation de bas niveau. Ada est un langage de haut niveaux, et pourtant c'est aussi l'outils idéal pour faire un OS portable :
- maitrise totale et portable de la représentation des données en mémoire, contrôle au bit prêt du mapping, contrôle de l'alignement, contrôle de l'adresse, contrôle de la volatilité, contrôle de l'atomicité de l'accès, etc.
- contrôle de l'allocation mémoire. Possibilité, par exemple, d'avoir des allocateurs dans différents pool mémoire avec des algos différents.
- contrôle des accès concurrents par les puissants "objets protégés" (pas besoin de manipuler des sémaphore au risque d'oublier d'en libérer un)
- utilisation des interruptions intégrée dans le langage
- tasking d'une puissance inégalée ailleurs. Ada est le seul langage à ma connaissance qui te permet d'écrire complètement un ordonnanceur sans appel à une API extérieure type POSIX, même avec des algos complexe genre EDF/LLF, etc.
- possibilité de faire vérifier par le compilateur des dizaines de restrictions possible (pour des besoins de certification), comme par exemple l'interdiction des allocations dynamiques.
- possibilité d'insérer de l'assembleur
etc. etc.
Et pour finir, un OS est un gros logiciel : c'est exactement ce pourquoi Ada a été conçu. Tu profites donc de tous les "ité" : lisibil, maintenabil, portabil, modular, fiabil, etc :-)
Par exemple, pour reprendre un point de Manuel, je n'ai jamais vu un projet Ada banir les templates. Ils sont utilisables en toute tranquilité.
Et pour reprendre un de tes points, la gestion des pointeurs en Ada est un modèle, ils sont utilisable avec une sécurité rare. Pour créer une "dangling référence" en Ada, il faut vraiment le faire exprès.
Tout ca pour dire qu'il y a au moins un langage de haut niveau doué pour la programmation de bas niveau.
Manque de bol (?), dans mon boulot aussi j'ai eu a tater de l'Ada ... les pbs (notamment d'interfacage) etaient nombreux, et les portage hasardeux
C'est off-topic, mais je suis prêt à discuter ce point, car portabilité et interfacage sont deux points fort d'Ada.
Pour ce qui est des algos / organisation .. etc .. c'est plus du a ce moment la a un manque de planification/reflection qu'au langage en lui-meme
C'était pour illustrer que le compilo fait bien un boulot qui m'aurai pris du temps et que j'aurai fait moins bien en utilisant un autre langage.
Toutes choses étant équivalentes par ailleurs (ce qui est loin d'être toujours le cas, on est d'accord), tu seras toujours beaucoup plus efficace en Ada qu'en C[++]. Tu peux essayer avec n'importe quelle planification/reflection/organisation.
Une façon drastique de changer la donne, c'est retirer l'élément humain du processus de codage. Ce n'est pas impossible, avec des méthodes de modélisation et génération complète du code, mais c'est loin de concerner une grande population dans le logiciel.
Deja a l'ecole Ada ne me plaisait pas .. Le concept oui, le resultat non ...
On a tous des affinités et des préférences, mais Il faut garder une certaine objectivité dans les jugements.
Pour reprendre ton exemple, j'ai entendu deux témoignages de logiciel en Ada réécrits complètement en C[++]. Je n'ai pas entendu un seul argument valable pour une telle manip. A chaque fois ca a couté catastrophiquement plus que prévu, et le résultat est moins bon que l'original.
Si on considère que cela repose juste sur des peurs (peur de voir le langage disparaitre, peur de ne pas trouver de programmeurs, peur de ne plus trouver d'outils, etc.), c'est dommage pour celui qui paye.
By the way, pour ceux qui ont une image poussiéreuse d'Ada sous emacs (dont je ne dis pas de mal, c'est très efficace), je recommande un petit apt-get install gnat-gps.
Pour ne pas perdre de temps a lire des études détaillées, tu peux lire "Programming Languages and Software Construction" de Franco Gasperoni, http://libre.act-europe.fr/Software_Matters/02-languages.pdf(...) . C'est orienté Ada, mais ca fait un tour de la question en moins de 40 slides.
L'étude Ziegler, par exemple, montre que le simple choix du langage permet de diminuer le nombre de bugs livré par 9 par rapport au C, sur un logiciel simultanément 60% moins cher à produire.
Projettons cela sur Linux, Apache, etc. : ca laisse rêveur, on en serai déja à Linux 4.x si ce n'était pas écrit en C :-)
Ce raisonnement (le programmeur est un dieu, il saura se démerder) était valable à l'époque ou le C++ a été designé.
A vrai dire, ce n'était déja plus le cas depuis au moins 10 ans : voir par exemple le rapport Steelman, en quelque sorte cahier des charges du langage Ada. Ca date du début des années 70, et ce principe de base y est déja : la programmation est une activité humaine, il faut que le langage soit un allié puissant, pas seulement un moyen d'expression.
Ca me fait penser au "peer programming" de XP : celui qui a le clavier s'occupe de tactique, il code les algos. Celui qui est derrière peut avoir une autre vision, plus stratégique. Il pense testabilité, adéquation au besoin, etc. L'esprit human ne sait pas faire bien tout en même temps.
Dans mon cas, mon compilateur Ada est aussi un pair programmeur : il s'occupe de tout un tas de vérification de cohérence, et pendant ce temps, je me concentre la conception. Je ne me pose presque jamais de question d'allocation mémoire, de cohérence des types, de déréférencement de pointeur, etc.
Si mon esprit reste concentré sur les pièges que le langage me tends, je suis moins disponible pour concevoir : mes algos sont moins bons, mon soft est mal organisé, et en plus je laisse quand même passer des erreurs à la con, car je ne suis pas dieu.
Ce ne sont pas des guerres de religions.
Les chiffres sont tétus (et inatendus dans leur ampleur), il faut se référer aux études sérieuses sur la chose.
Le choix du langage peux diviser le cout de developpement par 2, le cout de maintenance par 4, le nombre de défauts "livrés" par 8, le temps pour identifier et corriger un défaut par 2, etc. etc.
Même pour des gents qui ont de l'expérience et qui connaissent les différents langages concernés, c'est dur de se rendre compte de l'importance du choix du langage.
En fait, et contrairement à ce que l'on entend tout le temps, le langage est un des choix les plus important d'un développement (sauf si ca fait seulement 100 lignes de code, bien sur).
C'est grace a la suppresion de la manipulation des pointeurs, que les langages modernes peuvent etre sur et economique en terme de dev.
Faut nuancer, la suppression n'est pas la seule solution.
Un langage peut aussi rendre les pointeurs plus sur, en les typant, en adoptant des règles qui empèchent la plus grande partie des "dangling references", en rendant les objets non pointable sauf déclaration explicite dans le code, en définissant des pointeurs "read-only", etc.
Merci le language C pour Linux/Apache/Gnome/PostgreSQL/etc... qui sont rapides, *FIABLE* et ne nécessite pas 1 Go de mémoire pour fonctionner.
Il aurait juste falu 10 fois moins d'effort pour arriver au même niveau de qualité avec certains autres langages sur de gros projets comme ceux que tu cites.
.
Je suis globalement d'accord avec toi sur ton PS3, j'ai juste des remarques :
Quand je vois le nombre d'abruti qui crache sur la programmation objet (peuh ... c'est nul un objet, en C tu fait un struct et c'est la même chose, et puis moi je prog orienté objet en C!),
Ca n'empèche pas qu'on peut avoir de bons arguments, ou d'autres façons de développer très efficace.
"Objet" est un de ces mots clés qui paralysent les facultés d'analyse de la communauté informatique depuis les années 80, il faut conserver un esprit critique là dessus aussi. Voici quelques exemples de banalités générées par un excès inverses :
- "le switch est inutile puisque tu as l'héritage",
- "les générique sont une forme pauvre/primitive d'héritage" (ou autre truc complètement réducteur comme ce que dis Anders Hejlsberg dans l'interview http://www.artima.com/intv/generics.html(...) citée par quelqu'un dans un autre message)
- "la notion de classe a succédé à celle de module"
etc.
(si vous êtes d'accord avec une de ces affirmations, inquiétez-vous :-)
Il y en a aussi qui hurle si on leur demande un GC (mais de dieu! c'est pourtant simple quand tu fout ton objet sur la pile y'a pas de problème, et puis c'est marqué dans la doc qu'il faut supprimer l'objet si on est dans tel cas ...)
Il y en a aussi qui n'en ont vraiment pas besoin parce qu'ils utilisent un langage sain de ce coté là (voir mon mail plus haut).
(peuh ... y pas de "{" en Eiffel?
Un truc marant (enfin, j'me comprends), c'est que maintenant avoir une syntaxe à la C sert d'argument pour dire qu'un langage est lisible (j'ai vu ça dans la justification de conception du langage Samourai de Sun lab).
En gros, "C'est lisible, car tous les programmeurs C/C++ vont s'y mettre sans problème",
Les programmeurs habitués à des systèmes de types évolués (comme celui d'OCaml) savent bien qu'un programme refusé à cause d'une erreur de type est généralement (ce n'est pas une loi mathématique mais une constatation) incorrect sur le plan conceptuel. Autrement dit, une erreur dans un programme Erlang, comme dans tout langage, serait une erreur de type pour un système évolué.
Absolument, et n'oublions pas non plus l'autre avantage d'un typage puissant : la sémantique en plus est dans le code (ce qui permet au compilateur de détecter les erreurs), et donc elle n'a pas besoin d'être dans les commentaires ou dans la doc.
Ca fait du boulot et des incohérences en moins pour ceux qui font des docs... et des infos en plus de partagées dans le cas général :-)
Je suis bien d'accord sur le fait d'automatiser tout ce qui peut l'être.
Comme à chaque fois que l'on discute de GC, il y a unanimité pour dire que c'est un attribut indispensable d'un langage moderne, et hop, on se focalise sur les détails du GC.
Je rappelle quand même que le problème de base, ce sont les fuites mémoire, et que le GC n'est qu'une des réponses à ce problème.
Mais comme il vaut mieux prévenir que guérir, la meilleure réponse c'est quand même que la sémantique du langage empèche les fuites de mémoire.
Alors savoir si l'algo est plus ou moins optimisé, si il consomme le temps CPU de façon déterministe, distribuée, intelligente, etc., et bien il faut le savoir : on peut aussi dormir sur ses deux oreilles sans jamais se poser ce genre de problèmes.
(pour l'anectote, c'est signé d'un utilisateur heureux d'Ada).
| Peut-etre mais les langages dont tu veux parler sont eux-meme écrit en C...
Pour être précis, "langage écrit en C" ne veut pas dire gand chose.
Si tu veux dire que le compilateur génère du C qui est ensuite compilé par gcc, je pense que c'est faux.
Si tu veux dire que le compilateur est en partie écrit en C, alors je dirai que c'est vrai au moins pour le backend de gcc, que tous partagent.
Mais notes que ce n'est pas forcément le cas de tout le compilateur : par exemple les frontend Ada ou VHDL sont écrit en Ada.
Le développeur Ada n'a pas seulement le mérite d'avoir choisit librement un langage d'excellence là ou d'autres ont suivi la mode sans se poser de question, il a également le mérite d'encaisser une remarque de ce type à chaque discussion ou apparait Ada.
Curieusement, ca vient généralement de quelqu'un qui n'y connait rien et ne dira d'ailleur rien de plus productif dans la discussion.
Dis moi que pour une fois je me trompe, et que tu connais Ada...
Le mode Ada d'emacs est déja très complet, mais si tu y ajoutes les quelques bout de code qui vont bien, comme LSE (http://www.zipworld.com.au/~peterm/(...)) ou le GNAT-fix-error (http://www.toadmail.com/~ada_wizard/(...)) qui introduit directement dans le source la correction suggérée par GNAT, alors emacs reprend une longueur d'avance sur GPS.
Evidemment, vu le dynamisme de l'équipe d'ACT, je ne doute pas que GPS aura bientôt toutes ces fonctions...
Ce que j'ai trouvé dans GPS et pas dans GNAT, c'est surtout les graphes, d'appels ou d'héritages, etc.
Ne penses tu pas que justemment la désinformation qui reigne autour de cette directive risque de discrediter, et minimiser l'ensemble des voix émises par les acteurs du logiciel libre ?
Mais pourquoi répète tu celà? Les organisations qui militent pour le libre font un boulot d'un très grand sérieux, la désinformation dans ce dossier est d'un seul coté, et pas des deux comme tu le prétend.
Excuse moi de te dire ça, mais ta première lettre contient toute les opinions naives de ceux qui n'ont qu'un verni d'information.
Je te conseille de lire un peu sur le sujet, par exemple la présentation de Francois Pellegrini href=http://www.autourdulibre.org/article61.html,(...) ou http://www.abul.org/brevets/,(...) ou http://www.april.org/,(...) etc.
Accessoirement, tu y vera des exemples de brevet qui sont vraiment "n'importe quoi".
Tu ne peux pas en étant informé renvoyer tout le monde dos à dos. Il y a clairement dans ce dossier ceux qui agissent pour assoir leur pouvoir économique, et ceux qui agissent dans l'intéret commun.
Juste une remarque : certains compilateurs évolués, comme jikes pour java, sont capables de détecter des trucs du genre toTo utilisé à la place de toto, au sens où, en l'absence de symboles toTo, le compilateur va te dire qu'il ne trouve pas toTo, mais par contre qu'il trouve toto...
Oui, GNAT aussi te sort aussi un truc du genre "Varriable_A_La_Con is possible mispelling de Variable_A_La_Con".
C'est d'autant plus sympa que GPS (l'IDE qui fait mal aux yeux délicats de Guillaume :-) permet de réinjecter la correction dans le code (et ca peut également s'ajouter au mode Ada d'emacs).
Sinon, à titre personnel, je ne pense pas que la syntaxe soit tellement importante que ça dans le design d'un langage
Je suis d'accord, la sémantique est bien plus importante, mais :
1 - on a parlé que de la sensibilité à la casse, ce qui parait anecdotique pris isolément. Si tu ajoutes tous les autres pièges comme le = qu'on peut utiliser aux mêmes endroits que le ==, les nombres qui deviennent octal par la magie d'un zéro devant, les opérateurs cabalistiques (et il y en a jusque dans Eiffel ;-), la gestion piégeuse de la précéence des opérateurs, etc. etc., et bien c'est tout de suite moins anecdotique.
2 - on a aucune raison d'être indulgent avec ces erreurs de conceptions des langages. Elles sont connues depuis bien longtemps, tu as une litérature abondante (dont mon chouchou, le guide du code inmaintenable), et surtout, surtout, ca ne coute rien de les éliminer.
Des milliards de neurones sont morts partout à travers le monde dans d'atroces soufrances en planchant sur "faut-il l'héritage multiple?". Une petite poignée d'entre eux, même choisit parmi les moins doués, aurait suffit à éliminer ces faiblesse syntaxique. Donc, pas de pitié!
PS : pour être juste, tout ca aurait pu couter à C++ la compatibilité avec C, c'est à dire la vie :-), mais si on prend le cas de Java, cet argument ne s'applique pas.
[^] # Re: 13 % de « code mort »
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche 985 bugs dans le noyau Linux. Évalué à 4.
La DO178 (qui est utilisée pour l'avionique critique), fait une distinction entre deactivated code et deadcode. Ce dont tu parles entre dans la catégorie deactivated.
Par exemple un traitement d'exception que l'on mets au cas ou, ou un if dépendant d'un booléen de configuration dont une des branches ne sera jamais exécuté dans cette configuration là. Le deactivated code n'est volontairement pas exécuté.
Le dead code n'est pas non plus exécuté, mais c'est par erreur, souvent détectable par les outils d'analyse statique, du genre :
# A propos du concept "tout est objet"
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
"pure objet" n'était pas une qualité, c'est juste une caractéristique.
La grande erreur des années 80, ca a été justement de croire que tout était classe et objet. Je le reconnai : ramener tout à une poignée de concepts simples et universels, c'est tentant. Quelle "conceptual integrity"!
D'un point de vue marketing aussi, c'était intéressant : tout truc qui n'est pas "full quelque chose" semble louche d'emblée, avant même que l'on sache de quoi il retourne.
J'invite les passionnés à lire le papier http://acmqueue.com/modules.php?name=Content&pa=showpage&pi(...)
Il explique comment les langages C++ et Java se sont tirés une balle dans le pied en confiant les prérogatives des modules et des classes aux seules classes. [1]
Smalltalk, Ada, Modula ou OCaml n'ont pas eu à souffrir de la limitation "tout est objet" (que les spécialistes respectifs confirment), et ne s'en portent pas plus mal. [2]
Ce phénomène n'a pas tappé qu'au niveau langage, UML (à travers OMT) en a fait les frais également. Quelle absudité par exemple que ces classes ayant le stéréotype "utility", dont la principale caractéristique est de ne pas être des classes.
Tout ca pour dire qu'il n'y a pas de quoi conclure sur la supériorité d'un langage "pure objet". Trop souvent, il serait mieux caractérisé par "seulement objet".
PS pour David : un bon mail se fait en deux temps :
[1] tu énerves ceux qui sont déja là, et
[2] tu fais venir les autres! :-)
[^] # Question naive
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
C'est stupide comme objectif, ou ca pose des pbs techniques insolubles?
[^] # Quand on veut tuer son chien, on dit qu'il a la rage!
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Être orateurs aux RMLL à 13 ans? Avec Ada, même ça c'est possible!. Évalué à 3.
Et il y a des environnement Ada de grande qualité pour le développement temps réel (certains sont même multi langage) comme ceux de Green Hills, DDCI, et même celui d'ACT sous GPL.
Voyons les choses avec sincérité : le plus souvent, Ada est abandonné parce que personne ne se pose de question de coût global, qu'on a déja plein de problèmes a régler, et donc on va vers la facilité. Tout cela sur fond d'inconscience de la part énorme du cout logiciel, en particulier dans le spacial ou il n'y a pas de série. J'ai entendu ces témoignages à de multiple reprise.
Jusqu'à l'absurde dans le cas de Dassault Aviation : ils maintenaient leurs propres outils Ada, compilateur inclus. Evidemment le coût était énorme. Pour le Rafale, au lieu d'abandonner la maintenance de leurs outils, ils ont abandonné Ada. Et pour être bien sur que ce soit une catastrophe économique, ils ont remplacé Ada par C++.
Et si je parle d'absurdité, c'est parce que parallèlement, ils n'ont pas eu peur du coût énorme de développement d'un calculateur avec un hard propriétaire.
Les choses peuvent être très simple : Ada est le seul langage qui vienne avec un éxecutif temps-réel. Dans le spacial ou l'avionique, c'est tout bénef, car je n'ai LE PLUS SOUVENT pas besoin d'OS. Je n'ai pas a payer de license Lynx/VxWorks ou tout ce que tu veux.
Je ne vais pas parler des solutions sur étagères de Aonix/ACT/DDCI/GreenHills/etc. Prenons tout de suite le cas le pire : mon hard est maison, et je n'ai pas de compilo Ada :
1 - j'ai vécu ça chez Matra Défense. L'adaptation de l'executif du compilo à notre hard tenait en deux dizaines de lignes d'assembleurs (adaptation de la gestion des IT et du timer). Le cout de ce source est négligeable en regard du projet. Après, on avait tout Ada de dispo sur notre cible, en particulier tout le tasking.
2 - si tu choisi C, tu aura de toute façon le cout d'adaptation de VxWorks ou autre. Et ce sera pire.
Elle est ou la réalité économique, dans tout ça?
[^] # Re: A noter que :
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Être orateurs aux RMLL à 13 ans? Avec Ada, même ça c'est possible!. Évalué à 1.
présentation faite par Pascal Leroy (IBM/ex Rational) qui dirige le travail.
(Avis perso : des avancées très sympa ont également lieu dans le tasking).
[^] # Re: a contre courant
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Site de HurdFR de nouveau disponible. Évalué à 1.
En effet, mais ça ne demande qu'a changer, et on fait quelques actions pour ça : voir par exemple http://linuxfr.org/2004/07/03/16710.html(...)
[^] # Re: Humour ou facilité d'apprentissage ?
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Être orateurs aux RMLL à 13 ans? Avec Ada, même ça c'est possible!. Évalué à 6.
La facilité d'apprentissage est bien ce que je voulais mettre en avant. Commencer en Ada, c'est écrire une procédure avec une syntaxe Pascalienne :
Pas de quoi surchauffer.
Je donne deux illustration :
- sur mon projet (une ligne de produit d'un demi-million de ligne de code chez Thales Communications), nous intégrons des gars qui ne connaissent pas Ada avec un cout d'apprentissage du langage réel, mais anecdotique à coté de celui du domaine (qu'il a de toute façon). En fait, nous avons été les premiers surpris de celà. Le langage est lisible et sécurisant, donc les gars rentrent dedans progressivement, sans rendre le produit instable.
- autre exemple dans l'éducation (que je cite de mémoire). Il me semble que c'est Michael Feldmann de la Georges Washington University qui concluait ses cours d'informatique par la réalisation d'un projet (un système de gestion de trains et d'aiguillage). Il laissait le choix du langage aux groupes d'élèves. Ceux qui choisissait Ada finissait plus souvent leur projet que les autres. Et en particulier, aucun groupe ayant choisit C n'a jamais atteind les objectifs.
Le témoignage est quelque part sur le web.
[^] # Re: a contre courant
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Site de HurdFR de nouveau disponible. Évalué à 5.
Attention à la confusion habituelle entre sémantique de haut niveau, et programmation de bas niveau.
Il n'y a pas de contradiction, ce n'est tout simplement pas la même chose.
Illustration du niveau sémantique du langage. Je veux décaler des éléments d'un tableau a :
en Ada :
Je fait une affectation avec une syntaxe de haut niveau. Mon intention est clairement exprimée par le code, le compilateur vérifie à la compilation que j'affecte bien une tranche de tableau dans une autre de même taille, et que tout tombe bien dans le tableau, sans débordement.
en C :
Je ne manipule plus un tableau, mais de la mémoire : le niveau sémantique est plus bas. Accessoirement, cela réduit les possibilités d'optimisation du compilateur. Mais surtout, c'est illisible, et pour les contrôles, tiens, fumes!
Si je dois écrire la gestion de la mémoire d'un OS, on voit tout de suite avec lequel des deux langages le code sera le plus limpide.
Ceci montre qu'une sémantique de haut niveau est parfaitement indiquée pour faire de la programmation de bas niveau.
Maintenant, parlons de la programmation de bas niveau. Ada est un langage de haut niveaux, et pourtant c'est aussi l'outils idéal pour faire un OS portable :
- maitrise totale et portable de la représentation des données en mémoire, contrôle au bit prêt du mapping, contrôle de l'alignement, contrôle de l'adresse, contrôle de la volatilité, contrôle de l'atomicité de l'accès, etc.
- contrôle de l'allocation mémoire. Possibilité, par exemple, d'avoir des allocateurs dans différents pool mémoire avec des algos différents.
- contrôle des accès concurrents par les puissants "objets protégés" (pas besoin de manipuler des sémaphore au risque d'oublier d'en libérer un)
- utilisation des interruptions intégrée dans le langage
- tasking d'une puissance inégalée ailleurs. Ada est le seul langage à ma connaissance qui te permet d'écrire complètement un ordonnanceur sans appel à une API extérieure type POSIX, même avec des algos complexe genre EDF/LLF, etc.
- possibilité de faire vérifier par le compilateur des dizaines de restrictions possible (pour des besoins de certification), comme par exemple l'interdiction des allocations dynamiques.
- possibilité d'insérer de l'assembleur
etc. etc.
Et pour finir, un OS est un gros logiciel : c'est exactement ce pourquoi Ada a été conçu. Tu profites donc de tous les "ité" : lisibil, maintenabil, portabil, modular, fiabil, etc :-)
Par exemple, pour reprendre un point de Manuel, je n'ai jamais vu un projet Ada banir les templates. Ils sont utilisables en toute tranquilité.
Et pour reprendre un de tes points, la gestion des pointeurs en Ada est un modèle, ils sont utilisable avec une sécurité rare. Pour créer une "dangling référence" en Ada, il faut vraiment le faire exprès.
Tout ca pour dire qu'il y a au moins un langage de haut niveau doué pour la programmation de bas niveau.
# planning général?
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Cinquièmes Rencontres Mondiales du Logiciel Libre. Évalué à 3.
(et accessoirement pour savoir avec quoi on est en concurrence, pour ceux qui sont coté micro :-)
[^] # Re: Les spécifications du langage D sont arrivées
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Les spécifications du langage D sont arrivées. Évalué à 1.
C'est off-topic, mais je suis prêt à discuter ce point, car portabilité et interfacage sont deux points fort d'Ada.
C'était pour illustrer que le compilo fait bien un boulot qui m'aurai pris du temps et que j'aurai fait moins bien en utilisant un autre langage.
Toutes choses étant équivalentes par ailleurs (ce qui est loin d'être toujours le cas, on est d'accord), tu seras toujours beaucoup plus efficace en Ada qu'en C[++]. Tu peux essayer avec n'importe quelle planification/reflection/organisation.
Une façon drastique de changer la donne, c'est retirer l'élément humain du processus de codage. Ce n'est pas impossible, avec des méthodes de modélisation et génération complète du code, mais c'est loin de concerner une grande population dans le logiciel.
[^] # Re: Les spécifications du langage D sont arrivées
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Les spécifications du langage D sont arrivées. Évalué à 1.
On a tous des affinités et des préférences, mais Il faut garder une certaine objectivité dans les jugements.
Pour reprendre ton exemple, j'ai entendu deux témoignages de logiciel en Ada réécrits complètement en C[++]. Je n'ai pas entendu un seul argument valable pour une telle manip. A chaque fois ca a couté catastrophiquement plus que prévu, et le résultat est moins bon que l'original.
Si on considère que cela repose juste sur des peurs (peur de voir le langage disparaitre, peur de ne pas trouver de programmeurs, peur de ne plus trouver d'outils, etc.), c'est dommage pour celui qui paye.
By the way, pour ceux qui ont une image poussiéreuse d'Ada sous emacs (dont je ne dis pas de mal, c'est très efficace), je recommande un petit apt-get install gnat-gps.
[^] # Re: Les spécifications du langage D sont arrivées
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Les spécifications du langage D sont arrivées. Évalué à 1.
L'étude Ziegler, par exemple, montre que le simple choix du langage permet de diminuer le nombre de bugs livré par 9 par rapport au C, sur un logiciel simultanément 60% moins cher à produire.
Projettons cela sur Linux, Apache, etc. : ca laisse rêveur, on en serai déja à Linux 4.x si ce n'était pas écrit en C :-)
[^] # Re: Les spécifications du langage D sont arrivées
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Les spécifications du langage D sont arrivées. Évalué à 2.
A vrai dire, ce n'était déja plus le cas depuis au moins 10 ans : voir par exemple le rapport Steelman, en quelque sorte cahier des charges du langage Ada. Ca date du début des années 70, et ce principe de base y est déja : la programmation est une activité humaine, il faut que le langage soit un allié puissant, pas seulement un moyen d'expression.
Ca me fait penser au "peer programming" de XP : celui qui a le clavier s'occupe de tactique, il code les algos. Celui qui est derrière peut avoir une autre vision, plus stratégique. Il pense testabilité, adéquation au besoin, etc. L'esprit human ne sait pas faire bien tout en même temps.
Dans mon cas, mon compilateur Ada est aussi un pair programmeur : il s'occupe de tout un tas de vérification de cohérence, et pendant ce temps, je me concentre la conception. Je ne me pose presque jamais de question d'allocation mémoire, de cohérence des types, de déréférencement de pointeur, etc.
Si mon esprit reste concentré sur les pièges que le langage me tends, je suis moins disponible pour concevoir : mes algos sont moins bons, mon soft est mal organisé, et en plus je laisse quand même passer des erreurs à la con, car je ne suis pas dieu.
Donc oui, le langage est important.
[^] # Re: Les spécifications du langage D sont arrivées
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Les spécifications du langage D sont arrivées. Évalué à 1.
Les chiffres sont tétus (et inatendus dans leur ampleur), il faut se référer aux études sérieuses sur la chose.
Le choix du langage peux diviser le cout de developpement par 2, le cout de maintenance par 4, le nombre de défauts "livrés" par 8, le temps pour identifier et corriger un défaut par 2, etc. etc.
Même pour des gents qui ont de l'expérience et qui connaissent les différents langages concernés, c'est dur de se rendre compte de l'importance du choix du langage.
En fait, et contrairement à ce que l'on entend tout le temps, le langage est un des choix les plus important d'un développement (sauf si ca fait seulement 100 lignes de code, bien sur).
[^] # Re: Les langages et la jvm
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 1.
Faut nuancer, la suppression n'est pas la seule solution.
Un langage peut aussi rendre les pointeurs plus sur, en les typant, en adoptant des règles qui empèchent la plus grande partie des "dangling references", en rendant les objets non pointable sauf déclaration explicite dans le code, en définissant des pointeurs "read-only", etc.
[^] # Re: Havoc Pennington se pose des questions sur les langages du libre
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 1.
Il aurait juste falu 10 fois moins d'effort pour arriver au même niveau de qualité avec certains autres langages sur de gros projets comme ceux que tu cites.
.
[^] # Re: Havoc Pennington se pose des questions sur les langages du libre
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 1.
Ca n'empèche pas qu'on peut avoir de bons arguments, ou d'autres façons de développer très efficace.
"Objet" est un de ces mots clés qui paralysent les facultés d'analyse de la communauté informatique depuis les années 80, il faut conserver un esprit critique là dessus aussi. Voici quelques exemples de banalités générées par un excès inverses :
- "le switch est inutile puisque tu as l'héritage",
- "les générique sont une forme pauvre/primitive d'héritage" (ou autre truc complètement réducteur comme ce que dis Anders Hejlsberg dans l'interview http://www.artima.com/intv/generics.html(...) citée par quelqu'un dans un autre message)
- "la notion de classe a succédé à celle de module"
etc.
(si vous êtes d'accord avec une de ces affirmations, inquiétez-vous :-)
Il y en a aussi qui n'en ont vraiment pas besoin parce qu'ils utilisent un langage sain de ce coté là (voir mon mail plus haut).
Un truc marant (enfin, j'me comprends), c'est que maintenant avoir une syntaxe à la C sert d'argument pour dire qu'un langage est lisible (j'ai vu ça dans la justification de conception du langage Samourai de Sun lab).
En gros, "C'est lisible, car tous les programmeurs C/C++ vont s'y mettre sans problème",
MDR.
[^] # Re: Erlang a également été oublié
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 2.
Absolument, et n'oublions pas non plus l'autre avantage d'un typage puissant : la sémantique en plus est dans le code (ce qui permet au compilateur de détecter les erreurs), et donc elle n'a pas besoin d'être dans les commentaires ou dans la doc.
Ca fait du boulot et des incohérences en moins pour ceux qui font des docs... et des infos en plus de partagées dans le cas général :-)
[^] # Il y a un monde meilleur sans GC!
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 1.
Comme à chaque fois que l'on discute de GC, il y a unanimité pour dire que c'est un attribut indispensable d'un langage moderne, et hop, on se focalise sur les détails du GC.
Je rappelle quand même que le problème de base, ce sont les fuites mémoire, et que le GC n'est qu'une des réponses à ce problème.
Mais comme il vaut mieux prévenir que guérir, la meilleure réponse c'est quand même que la sémantique du langage empèche les fuites de mémoire.
Alors savoir si l'algo est plus ou moins optimisé, si il consomme le temps CPU de façon déterministe, distribuée, intelligente, etc., et bien il faut le savoir : on peut aussi dormir sur ses deux oreilles sans jamais se poser ce genre de problèmes.
(pour l'anectote, c'est signé d'un utilisateur heureux d'Ada).
[^] # Re: GPS 1.2.2 : GNAT Programming System is out
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche GPS 1.2.2 : GNAT Programming System est dispo. Évalué à 1.
Tiens, prend donc cette réponse à j + 3 mois!
:-)
Lionel
PS : et vu ta réponse, c'est pas bien grave que j'ai posté à j+2, parce que effectivement, sur le fond t'avais pas grand chose d'intéressant à dire...
[^] # Re: Le futur de GCC se dévoile !
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Le futur de GCC se dévoile !. Évalué à 1.
Pour être précis, "langage écrit en C" ne veut pas dire gand chose.
Si tu veux dire que le compilateur génère du C qui est ensuite compilé par gcc, je pense que c'est faux.
Si tu veux dire que le compilateur est en partie écrit en C, alors je dirai que c'est vrai au moins pour le backend de gcc, que tous partagent.
Mais notes que ce n'est pas forcément le cas de tout le compilateur : par exemple les frontend Ada ou VHDL sont écrit en Ada.
[^] # Re: GPS 1.2.2 : GNAT Programming System is out
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche GPS 1.2.2 : GNAT Programming System est dispo. Évalué à 2.
Curieusement, ca vient généralement de quelqu'un qui n'y connait rien et ne dira d'ailleur rien de plus productif dans la discussion.
Dis moi que pour une fois je me trompe, et que tu connais Ada...
[^] # Re: GPS premier essai
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche GPS 1.2.2 : GNAT Programming System est dispo. Évalué à 1.
Le mode Ada d'emacs est déja très complet, mais si tu y ajoutes les quelques bout de code qui vont bien, comme LSE (http://www.zipworld.com.au/~peterm/(...)) ou le GNAT-fix-error (http://www.toadmail.com/~ada_wizard/(...)) qui introduit directement dans le source la correction suggérée par GNAT, alors emacs reprend une longueur d'avance sur GPS.
Evidemment, vu le dynamisme de l'équipe d'ACT, je ne doute pas que GPS aura bientôt toutes ces fonctions...
Ce que j'ai trouvé dans GPS et pas dans GNAT, c'est surtout les graphes, d'appels ou d'héritages, etc.
Lionel
[^] # Re: Brevet logiciels : le vote reporté à septembre.
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Brevets logiciels : le vote reporté à septembre.. Évalué à 3.
Mais pourquoi répète tu celà? Les organisations qui militent pour le libre font un boulot d'un très grand sérieux, la désinformation dans ce dossier est d'un seul coté, et pas des deux comme tu le prétend.
Excuse moi de te dire ça, mais ta première lettre contient toute les opinions naives de ceux qui n'ont qu'un verni d'information.
Je te conseille de lire un peu sur le sujet, par exemple la présentation de Francois Pellegrini href=http://www.autourdulibre.org/article61.html,(...) ou http://www.abul.org/brevets/,(...) ou http://www.april.org/,(...) etc.
Accessoirement, tu y vera des exemples de brevet qui sont vraiment "n'importe quoi".
Tu ne peux pas en étant informé renvoyer tout le monde dos à dos. Il y a clairement dans ce dossier ceux qui agissent pour assoir leur pouvoir économique, et ceux qui agissent dans l'intéret commun.
Lionel Draghi
[^] # Re: promouvoir Java plutot que C#
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Mono 0.24. Évalué à 1.
Oui, GNAT aussi te sort aussi un truc du genre "Varriable_A_La_Con is possible mispelling de Variable_A_La_Con".
C'est d'autant plus sympa que GPS (l'IDE qui fait mal aux yeux délicats de Guillaume :-) permet de réinjecter la correction dans le code (et ca peut également s'ajouter au mode Ada d'emacs).
Sinon, à titre personnel, je ne pense pas que la syntaxe soit tellement importante que ça dans le design d'un langage
Je suis d'accord, la sémantique est bien plus importante, mais :
1 - on a parlé que de la sensibilité à la casse, ce qui parait anecdotique pris isolément. Si tu ajoutes tous les autres pièges comme le = qu'on peut utiliser aux mêmes endroits que le ==, les nombres qui deviennent octal par la magie d'un zéro devant, les opérateurs cabalistiques (et il y en a jusque dans Eiffel ;-), la gestion piégeuse de la précéence des opérateurs, etc. etc., et bien c'est tout de suite moins anecdotique.
2 - on a aucune raison d'être indulgent avec ces erreurs de conceptions des langages. Elles sont connues depuis bien longtemps, tu as une litérature abondante (dont mon chouchou, le guide du code inmaintenable), et surtout, surtout, ca ne coute rien de les éliminer.
Des milliards de neurones sont morts partout à travers le monde dans d'atroces soufrances en planchant sur "faut-il l'héritage multiple?". Une petite poignée d'entre eux, même choisit parmi les moins doués, aurait suffit à éliminer ces faiblesse syntaxique. Donc, pas de pitié!
PS : pour être juste, tout ca aurait pu couter à C++ la compatibilité avec C, c'est à dire la vie :-), mais si on prend le cas de Java, cet argument ne s'applique pas.