Par exemple, ses paradigmes objets ne sont pas classiques par rapports aux autres langages.
Tout à fait d'accord, c'est le point le plus inhabituel du langage.
Mais d'un autre coté, il offre tellement de caractéristiques uniques.
Au hasard, quel plaisir d'avoir un tasking complètement intégré dans le langage : pouvoir définir des types taches pas plus dificilement qu'une classe, déclarer un tableaux de 500 taches, etc.
Tout ça de façon portable, sans faire appel à la moindre API externe.
J'insiste sur le fait que cela a un cout à l'execution
Tout à fait, mais justement le bench montre que ce coût peut-être faible.
Par ailleurs, dans le cas de Ada, de nombreux checks sont fait à la compilation, car le source est sémantiquement riche. Ceci est sans conséquence au niveau du code généré.
Quand aux vérifications à l'exécution, tu as la possibilité de les enlever là ou tu le souhaite, soit par les options de compilation, soit directement par des pragmas dans le source. Ceci est utile par exemple lorsque qu'un outils externe te fournit une preuve formelle de ce que ces vérifiations sont inutiles.
Mais en fait, c'est rarement utile, car le compilateur fait un très bon boulôt d'optimisation.
Tu as donc le beurre et l'argent du beurre :
- vérif en abondance à la compil,
- vérif à l'execution pour le reste,
- performance quand il le faut.
Pour finir, il y a un compilateur Ada qui fait très fort car il ajoute de nombreux warnings et optimisations par dessus ce qui est imposé par le langage (et même des suggestions de corrections pour les erreurs bateau et les typos).
Et pour la chance du monde du libre, il se trouve que c'est justement GNAT, le compilo Ada de gcc.
Le fait de lancer trois fois le test fait que la JVM est encore dans la mémoire (si la machine n'est pas intensivement utilisée en parallèle du bench). La première fois tu vas la chercher sur le disque.
Alors je serai surpris que ca ne fasse pas une belle différence, même si ce ne sont pas encore les conditions idéales.
Je comprends bien ce que tu dis sur l'aprentissage.
Mais concernant le développement, il ne s'agit de rien d'autre que de ton temps : tu le gaspilles ou tu l'utilises.
Débuggez ou développez, that is the question.
La plupart des dev Ada utilisent leur debugger tous les trois mois. Ca parait incroyable, mais c'est la stricte vérité.
Et pour ta dernière phrase, je me félicite que les dev de LL ne fassent pas le même choix que les entreprises, car curieusement les entreprises ne sont que rarement rationnelles, et elles vivent dans la psychose de prendre du retard et ne pas être dans le "mainstream".
Tu as raison, j'en ai trop fait sur le bench, et les précautions pour éviter les trolls sont parfaitement inutiles sur ce genre de sujets. J'ai en fait commencé une réponse dans la discussion Java et OOo, mais ca m'embettait de participer à ce troll.
Alors, j'ai fais un article.
Toutefois, ce que tu dis est exactement la première moitié de la news. Ta conclusion sur la l'inutilité de C dans la plupart des développement moderne est exactement l'essence de l'article.
L'autre message que je voulais faire passer, c'est que les solutions "mainstream" ne sont pas forcément les meilleures, mais, bon, c'est si rassurant d'être dans la masse. Utiliser une solution originale demande d'être cultivé déjà rien que pour en avoir eu connaissance, encore plus pour bâtir un argumentaire comparatif (alors que si tu fais du C personne ne te demande rien).
Faut être un peu couillus ou associable, je trouve :-).
Tiens, sans le faire exprès je t'ai donné une réponse à ta question sur pourquoi C domine toujours outrageusement :-)
Tu as parfaitement raison, et c'est pourquoi le test est lancé trois fois de suite, et que seul le meilleur temps est retenu (tandis que pour la conso mémoire c'est la plus grande qui est conservé).
Ceci répond également partiellement a l'objection faite plus haut sur le désavantage des interpréteurs par rapport au test compilés : le désavantage est réel, mais pas si important que celà.
un code OCaml est beaucoup plus compact qu'un code C, ce qui ajoute encore à sa lisibilité et à sa facilité de compréhension
Attention à ne pas en faire une généralité : il n'y a aucune corrélation entre longueur et facilité de compréhension.
Fait lire un test même OCaml par un non informaticien, et le même test Ada dont le source est peut-être quatre fois plus long, vois ce qu'il comprend et tu en aura la preuve.
Personellement, je trouve ce critère tellement non significatif que je me demande ce qu'il fait sur ce comparatif.
Je VEUX faire un buffer overflow à cet endroit, et je ne comprend pas pourquoi je n'y arrive pas dans en Ada).
C'est une caractéristique essentiel d'Ada : tout est possible, y compris un buffer overflow.
Mais pour faire une goretterie pareille il faut faire un effort une fois. (Je me demande bien pourquoi, au passage).
Dans d'autre langage c'est pour éviter le buffer overflow qu'il faut faire des efforts... tout le temps.
L'esprit n'est pas le même, et ca fait une grosse différence.
Curieux je n'ai pas ce problème. Tu as fais un petit upgrade avant d'installer bootsplash? Il a pu y avoir des modifs.
Merci pour ton mail, ca m'a donné à réfléchir : c'est probablement du a ce que j'ai restauré la base de mon système avec une Knoppix.
Il y a quelques paquetages qui gardent l'empreinte Knoppix, entre autre sysvinit : je force la mise à jour vers une version Debian et je vais bien voir le résultat.
Si je ne poste plus rien dans les jours à venir, c'est que c'était une mauvaise idée :-)
Du moment qu'il trouve des bugs que le développeur peut confirmer ensuite, ce n'est pas inutile.
En général oui, mais pas toujours : pour une commande de vol électrique d'avion de ligne, il faut prouver que le logiciel est complètement correct.
Mais bon, comme passer d'un bon auxiliaire dans la chasse au bug à la preuve formelle du programme implique des changements considérables dans le processus et les outils de développement, ce n'est franchement pas applicable sur le kernel (et au logiciel libre en général, d'ailleurs).
En gros, je ne comprend pas trop [...] pourquoi c'est pas intégré dans le compilateur directement.
Le compilateur ne peut pas faire de miracle : en amont, il y a la définition du langage utilisé. Si la définiton est imprécise, et la sémantique de bas niveau, la tâche devient virtuellement impossible pour les outils d'analyse statique.
Alors à fortiori pour le compilateur dont ce n'est pas la vocation.
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.
[^] # Re: Ada answers
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 2.
Tout à fait d'accord, c'est le point le plus inhabituel du langage.
Mais d'un autre coté, il offre tellement de caractéristiques uniques.
Au hasard, quel plaisir d'avoir un tasking complètement intégré dans le langage : pouvoir définir des types taches pas plus dificilement qu'une classe, déclarer un tableaux de 500 taches, etc.
Tout ça de façon portable, sans faire appel à la moindre API externe.
[^] # Re: Dommage ...
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 2.
Tout à fait, mais justement le bench montre que ce coût peut-être faible.
Par ailleurs, dans le cas de Ada, de nombreux checks sont fait à la compilation, car le source est sémantiquement riche. Ceci est sans conséquence au niveau du code généré.
Quand aux vérifications à l'exécution, tu as la possibilité de les enlever là ou tu le souhaite, soit par les options de compilation, soit directement par des pragmas dans le source. Ceci est utile par exemple lorsque qu'un outils externe te fournit une preuve formelle de ce que ces vérifiations sont inutiles.
Mais en fait, c'est rarement utile, car le compilateur fait un très bon boulôt d'optimisation.
Tu as donc le beurre et l'argent du beurre :
- vérif en abondance à la compil,
- vérif à l'execution pour le reste,
- performance quand il le faut.
Pour finir, il y a un compilateur Ada qui fait très fort car il ajoute de nombreux warnings et optimisations par dessus ce qui est imposé par le langage (et même des suggestions de corrections pour les erreurs bateau et les typos).
Et pour la chance du monde du libre, il se trouve que c'est justement GNAT, le compilo Ada de gcc.
[^] # Re: Et vb.net ?
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 1.
Regarde http://shootout.alioth.debian.org/faq.php?sort=fullcpu#acceptable(...)
Tu vas comprendre pourquoi :-)
[^] # Re: bidon
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 0.
Alors je serai surpris que ca ne fasse pas une belle différence, même si ce ne sont pas encore les conditions idéales.
[^] # Re: Dommage ...
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 3.
Mais concernant le développement, il ne s'agit de rien d'autre que de ton temps : tu le gaspilles ou tu l'utilises.
Débuggez ou développez, that is the question.
La plupart des dev Ada utilisent leur debugger tous les trois mois. Ca parait incroyable, mais c'est la stricte vérité.
Et pour ta dernière phrase, je me félicite que les dev de LL ne fassent pas le même choix que les entreprises, car curieusement les entreprises ne sont que rarement rationnelles, et elles vivent dans la psychose de prendre du retard et ne pas être dans le "mainstream".
[^] # Re: Dommage ...
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 5.
Tu as raison, j'en ai trop fait sur le bench, et les précautions pour éviter les trolls sont parfaitement inutiles sur ce genre de sujets. J'ai en fait commencé une réponse dans la discussion Java et OOo, mais ca m'embettait de participer à ce troll.
Alors, j'ai fais un article.
Toutefois, ce que tu dis est exactement la première moitié de la news. Ta conclusion sur la l'inutilité de C dans la plupart des développement moderne est exactement l'essence de l'article.
L'autre message que je voulais faire passer, c'est que les solutions "mainstream" ne sont pas forcément les meilleures, mais, bon, c'est si rassurant d'être dans la masse. Utiliser une solution originale demande d'être cultivé déjà rien que pour en avoir eu connaissance, encore plus pour bâtir un argumentaire comparatif (alors que si tu fais du C personne ne te demande rien).
Faut être un peu couillus ou associable, je trouve :-).
Tiens, sans le faire exprès je t'ai donné une réponse à ta question sur pourquoi C domine toujours outrageusement :-)
[^] # Re: bidon
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 2.
Ceci répond également partiellement a l'objection faite plus haut sur le désavantage des interpréteurs par rapport au test compilés : le désavantage est réel, mais pas si important que celà.
[^] # Re: Un petit test custom
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 7.
Attention à ne pas en faire une généralité : il n'y a aucune corrélation entre longueur et facilité de compréhension.
Fait lire un test même OCaml par un non informaticien, et le même test Ada dont le source est peut-être quatre fois plus long, vois ce qu'il comprend et tu en aura la preuve.
Personellement, je trouve ce critère tellement non significatif que je me demande ce qu'il fait sur ce comparatif.
[^] # Re: Dommage ...
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 7.
C'est une caractéristique essentiel d'Ada : tout est possible, y compris un buffer overflow.
Mais pour faire une goretterie pareille il faut faire un effort une fois. (Je me demande bien pourquoi, au passage).
Dans d'autre langage c'est pour éviter le buffer overflow qu'il faut faire des efforts... tout le temps.
L'esprit n'est pas le même, et ca fait une grosse différence.
[^] # Re: Sysv-rc ?
Posté par Lionel Draghi (site web personnel) . En réponse au journal Bootsplash et alternative /bin/sh dans Debian. Évalué à 1.
Merci pour ton mail, ca m'a donné à réfléchir : c'est probablement du a ce que j'ai restauré la base de mon système avec une Knoppix.
Il y a quelques paquetages qui gardent l'empreinte Knoppix, entre autre sysvinit : je force la mise à jour vers une version Debian et je vais bien voir le résultat.
Si je ne poste plus rien dans les jours à venir, c'est que c'était une mauvaise idée :-)
[^] # Re: SWAT exempté?
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche 985 bugs dans le noyau Linux. Évalué à 0.
En général oui, mais pas toujours : pour une commande de vol électrique d'avion de ligne, il faut prouver que le logiciel est complètement correct.
Mais bon, comme passer d'un bon auxiliaire dans la chasse au bug à la preuve formelle du programme implique des changements considérables dans le processus et les outils de développement, ce n'est franchement pas applicable sur le kernel (et au logiciel libre en général, d'ailleurs).
[^] # Re: je comprend pas trop...
Posté par Lionel Draghi (site web personnel) . En réponse à la dépêche 985 bugs dans le noyau Linux. Évalué à 3.
Si tu veux un panel complet en quelques pages des techniques de vérification, tu peux lire le chapitre "Verification Techniques" du Guide d'utilisation d'Ada dans les systèmes de haute intégrité http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/c029575_I(...)).zip
Le compilateur ne peut pas faire de miracle : en amont, il y a la définition du langage utilisé. Si la définiton est imprécise, et la sémantique de bas niveau, la tâche devient virtuellement impossible pour les outils d'analyse statique.
Alors à fortiori pour le compilateur dont ce n'est pas la vocation.
[^] # 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.