Lionel Draghi a écrit 107 commentaires

http://www.all-day-breakfast.com/rosegarden/(...)
C'est du Qt/KDE.


Ca présente très bien, bravo!

L'historique est passionnant. Vous avez à peut prêt tout essayé sur ce projet, ou je me trompe? :-)

Je vois que tu a trempé dans GTK--. Je comprends pourquoi ta conversation avec un des auteurs de GtkAda a du être interressante.
C'est pas indiscret de te demandé pourquoi tu a abandonné GTK-- et Gnome?

Autre question, as tu essayé Kdevellop?
(ca ne m'interessai pas jusque la, mais le comme le support d'Ada vient d'être ajouté, je vais peut-être me fendre d'un apt-get, pour voir... :-)

Tu ne penses pas que ça peut amener des programmeurs à nommer des variables différemment, et de rendre moins lisible ?

Je ne suis pas sur d'avoir compris ce que tu voulais dire, mais je dirai que un minimum pour la lisibilité, c'est que des variables différentes aient des noms différents, non?

Bon, c'est pas la peine de continuer, on ne vit pas dans le même monde. Au boulot je fais des GUI, à la maison (le projet libre dont je m'occupe), c'est de la GUI aussi, particulièrement complexe. Tu bosses dans un environnement très spécifique, isolé des contraintes auxquelles je suis soumis (et en contrepartie je n'ai pas les tiennes non plus). Dès que tu as affaire à des utilisateurs lambdas, pas des techniciens, tu te retrouves avec une foultitude de problèmes pour lesquels la propreté de ton langage ne t'es d'aucun secours. C'est ce que j'explique dans mon autre post plus haut. OK, pour arréter, mais pas d'accord sur le "aucun secours" dont tu parles plus haut. C'est justement quand tu patch gorrettement le code, que tu prends le moins de temps pour réfléchir et pour tester, que tu aprécie le plus que le compilo et les règles du langage te protège des erreurs bêtes. Dans un environnement au top de la sureté, ou le code est généré depuis les belles boiboites d'un outils UML et prouvé formellement, le langage à beaucoup moins d'importance. [OT] : je vais aller voir ton proj libre, je suis curieux. Comment s'appelle-t-il? C'est du QT?

Regarde les screenshots de l'IDE Ada d'ACT : c'est laid à pleurer. Du GTK+ mal foutu, des fontes moches, des widgets mal taillés. Compare avec ceux d'IntelliJ Idea. Lequel des deux as-tu envie de voir tous les jours ? Et si tu dis "oui mais il suffit de fignoler un peu le GTK+ et ça sera aussi joli". C'est précisément ce fignolage qui prend 80% du temps de dev d'une appli comme celle-là (et ce qui passe le plus souvent à la trappe, surtout dans l'Open Source), et qui fait la différence entre une "preuve de concept" et une appli finie. Je ne te dirai pas ca, car la beauté de l'IDE, je m'en... enfin, tu vois, quoi, et les fonts je les change sans faire appel à la mailing list des dévellopeurs Gtk! Plus sérieusement, il y a de très belle applis full Gtk, alors ca ne me parait pas un problème. Inversement, je trouve moche le look des applis Java, mais ca ne me viendrait pas à l'idée de m'en servir comme argument contre Java. Déjà qu'il n'y ait pas de toolkit graphique native en Ada ou Eiffel est le constat d'échec le plus définitif qui soit. :-) Mon trollomètre a tremblé!

Bof. Il y a aussi d'autres façons de faire se ressembler des noms de variables (une lettre de plus)... Oui, voir le hilarant How To Write Unmaintainable Code (http://mindprod.com/unmain.html). Maintenant, que certaines techniques décrites dans ce howto ne puissent être évitée par le langage n'empèche pas que si ca peut l'être, ca doit l'être. CapiTaliSaTion :If you use intercapitalization for function names (capitalize the first letter of each word), randomly capitalize the first letter of a syllable in the middle of a word. For example: ComputeRasterHistoGram(). J'adore! Utiliser cela, c'est un classique, mais ça s'appelle jouer avec le feux. C'est "error prone". Que penserais tu d'un monde ou 10 rue des Ramiers et 10 rue Des Ramiers ne désigneraient pas la même maison? Faut être informaticien pour accepter une contrainte pareille! :-) Et pense également à l'impact sur la communication orale.

Je ne le crois pas, toute personne qui a passé du temps sous gdb à cause d'une déclaration identique à une autre à la capitalisation prêt considerera avec raison avoir perdu son temps.

Un langage sain empèche ca.

Un autre grand chagement de DLFP a été la suppression de anonyme, du jour au lendemain les trolls ont disparu. Du coup, on se marre moins en lisant DLFP. Il faut savoir qu'un troll n'est pas un propos vulgaire, raciste, désagreable. Dans certains, cas le troll ou plutôt ses réponses sont trés instructifs. Il a même eu une nouvelles sur comment troller....

Je te trouve complaisant. Ou bien on a pas la même définition du troll.

Un trolleur, c'est quelqu'un qui essaye de te manipuler. Et pas pour te rendre meilleur, juste pour te sortir de tes gonds, ou pour te faire perdre ton temps. Tu es son petit rat de laboratoire, il te fait marcher dans une petite roue aussi loin qu'il le peut.

C'est très rarement drôle, c'est méprisant, et ca génère beaucoup de bruit et pas beaucoup de réponses intéressantes.
Une simple question polie t'amène les mêmes réponses sans le bruit.

Et si tu veux faire une blague, tu mets un smiley, au moins tu n'énervera que les distraits.

Oui, Ada est issu d'un appel offre de l'armée US, donc je pense que pour certains développements, il doit être imposé.

Le "Ada Mandate" obligait chaque contractant du DOD à fournir un sérieux dossier de justification si il voulait utiliser autre chose. Cette contrainte a été levée en 96. Le DOD comptait sur la maturité des processus de développement chez les industriels...
En revanche, Boeing l'impose avec férocité à ses sous-traitants. Il y d'ailleurs une anecdote amusante d'un sous-traitant qui publie une "succes stories" avec Ada, alors qu'il avait commencé en C en esperant forcer la main a Boeing. Bien qu'il ait du mettre à la poubelle ce qu'il avait déja fait, et que les gars ne connaissait pas Ada, il ont finit dans les temps en dépensant moins que prévu.


Sur le mandat du DOD, il y a un article dans CrossTalk de février 2003, intitulé "SEPR and Programming Language Selection" (http://www.stsc.hill.af.mil/crosstalk/2003/02/riehle.html(...)).

Je recommande d'ailleurs la lecture de ce numéro, puisque c'était un spécial "Programming Language", avec des articles très intéressant sur l'évolution des langages de programmation (http://www.stsc.hill.af.mil/crosstalk/2003/02/(...)).

Ca va passionner beaucoup de monde ici :-)

Eh, mais arrète ton obsession !
Tu crois qu'il n'y a qu'en C qu'il y a des bugs ? Tu crois qu'en Java, en Caml, en Ada, en Python ou en VB y'en a pas des bugs ?!

Bien sur que si, mais a niveau de qualité équivalent, tu aura juste passé deux fois moins de temps.

Programmer en C, de manière sure, c'est parfaitement faisable il faut juste avoir un peu de méthode et faire gaffe à ce qu'on fait. Bien sûr quand on code on fait parfois des erreurs, mais c'est pareil dans _tous_ les langages.

Non, ce n'est pas pareil dans tous les langages.
Les langages qui ont étés conçu en n'oubliant pas que la programmation est une activité humaine font en sorte de limiter les failles. Les autres tendent des pièges sans arrêt. Exemple, l'obligation d'utiliser pointeurs et allocation dynamique, le fait d'être case-sensitive, le fait de permettre la confusion entre affectation et comparaison, etc, etc.

De plus, les langages n'ont pas tous le même niveau d'abstraction. Que ce soit pour le codage (typage fort, interfacage avec le hard) ou la conception (gestion de la modularité, tasking, répartition) tous n'offent pas la même puissance. Ca n'est pas sans conséquence sur la productivité, et sur la qualité du résultat.

C'est pas le langage qui fait un bon ou un mauvais programme, mais l'architecture globale du soft (le design) et les programmeurs (leur compétence, leur maîtrise du langage et le soin qu'ils ont mis à coder ce programme là).
Non. Le langage a aussi une part importante. Quand on a découvert dans les années 70 que l'architecture était prépondérante, on a commencé a sortir ce lieu commun "peu importe le langage, pour peu qu'on ait le bon design".
Ca s'appelle jetter le bébé avec l'eau du bain. On a fait la même chose ensuite avec le support de l'objet versus le support de la modularité.
Un nouveau truc important n'efface pas les précédents, il s'ajoute. Je ne serai d'ailleurs pas surpris qu'on se remette à tout oublier avec l'arrivée de la vague AOP.

Et pour ça, le C n'est pas du tout un mauvais langage, parce qu'il peut assez facilement être _complêtement_ maîtrisé.

Oui, contrairement a C++. Mais ca ne compense pas ses faiblesses.

Bon, on ben est pas sortit de l'auberge!

1 - Ta recherche sur internet est ridicule, car tu instrui à charge, et tu trouvera toujours quelque chose à redire. En vrac :
- pour SQL,cherche GNADE,
- pour HTTP/HTTPS/SOAP/etc/etc, cherche AWS
- GtkAda, c'est un très bon binding portable. Quel est ton problème? Pour les libs on en a trop, mais pour les GUI ont en a pas assez?
- les screenshots qui font pitiés, c'est tout ce que tu a a dire? C'est du Gtk, si ca ne te plait pas, change de thème. Comme pour le nombre d'éditeurs, c'est tes arguments qui font pitiès.
- et si tu veux du pas libre, qui fait du COM/DCOM et autre, il y en a, cherche mieux.

2 - je ne suis pas un "fan". Il il y a un liste lingue comme le bras de défauts dans Ada dont je me passerai bien. Si je dois faire du logiciel dans un autre domaine que le mien, je choisirai les outils qui vont bien, et le jour ou Ada sera suplanté dans mon domaine, je lui dirai au revoir et merci.
Mais actuellement, c'est juste le meilleur pour ce que tu appelle sa niche, les logiciels temps-réels, et surtout tous les gros softs développés par pleins de gars, comme, je le répète, le kernel Linux, Apache, etc.
Donc, non, je ne crois pas qu'il restera dans sa niche :-), je crois qu'il connaitra une seconde jeunesse dans le monde libre, car il est parfaitement adapté.

3 - en fait, ton assertion de base avec la quelle je ne suis pas d'accord, c'est que le principal est dans la lib. C'est faux.
Primo, une grande partie des logiciels n'utilisent pas ou peu de lib. Je n'ai pas travaillé sur un logiciel ayant une interface graphique depuis 1991. La famille de produit sur la quelle je travaille compte un demi million de ligne de code, et n'utilise aucun de tes buzz words. Nous utilisons seulement une interface socket et quelques autres fonctions d'Unix ou de NT.
Secondo, il y a 50 langages qui offrent tous tes buzz words en bibliothèque. Que ce soit standard est clairement mieux, je suis pour a fond, mais que veux tu que les quelques jours qu'il nous a fallu pour choisir la bibliothèque de structure de donnée représentent dans le cout de notre soft, ou même d'un plus petit.
Tertio, Ada est le champion du monde de l'interfacage. L'interface avec C (et quelques autres) est définie dans la norme, et il est très simple de faire une interface portable vers n'importe quelle lib C, ce qui nous ouvre un max de portes, tu en conviendra. Il en ira de même pour C++, maintenant qu'il est normalisé, et probalement de java dans la prochaine révision de la norme.
Quarto, rien ne t'empèche d'utiliser les API Java et la JVM depuis Ada, et idem pour C# et la CLR.


En conclusion, la vérité, c'est que les défauts du langages, tu te les traine comme des boulets, tout le temps, que tu utilise des libs ou pas, et quelque soit le type de ton appli.
Les libs, elles sont plus ou moins bonne, plus ou moins standard, etc. Je suis d'accord avec tous les inconvénients que tu as cités. Mais ce n'est généralement pas déterminant. Fais un sondage ici même, et essaye de trouver un cas ou la conclusion, c'est qu'il FAUT utiliser C#.
Et dans pas mal de cas, les libs, on s'en fout même carrément.

Une anecdote, pour terminer : des étudiants de l'ENST ont réalisé un client Jabber avec GtkAda en quelques centaines d'heures, alors qu'il ne connaissaient pas Ada, pas le protocole Jabber, et probablement pas non plus XML et SAX.
Ils ont fait ca sans QT et sans C#.
Etonnant, non?
Il ne devaient pas savoir qu'ils violaient la frontière de "la niche".

Par exemple, IBM propose une implémentation open source d'un JSR (future extension officielle de Java) qui propose des flotants décimaux, c'est-à-dire des calculs exacts en flottant, avec lesquels on simule très facilement les réels à virgule fixe (dont l'intérêt m'échappe, excepté sur du hardware spécifique). Cf http://www2.hursley.ibm.com/decimalj/(...)

Je suis d'accord, en effet les processeurs moderne sont plus rapides avec les flottants qu'avec les points fixes pour pas mal d'opérations. J'ai pris cet exemple comme j'aurai pu prendre un float pour montrer la liste des attributs prédéfinis d'Ada.
Pour te rendre les choses moins simple, j'aurai aussi pu prendre la listes des attributs prédéfinis sur les énumérés, mais je manque de vice :-)

Le mapping mémoire n'existe pas au sens strict en Java puisque le système de type est très réduit, contrairement à Ada, je le reconnais sans problème. Cela ne veut pas dire que tu ne peux pas faire ce dont tu parles, mais ça risque d'être effectivement chiant et surtout inutile (en Java).

Le fait que ce soit utile ou pas dépend de l'application, par du langage. Si tu dois lire des infos dans la zone mémoire d'un device dont on te done l'adresse, comment fais tu en Java?


Concernant l'introspection etc., l'aspect fair est ridicule. Les langages existent tels qu'ils sont, point final. On reproche toujours à Java d'être basé sur une JVM, on ne peut pas de l'autre côté vouloir en plus supprimer les avantages de cette approche !

C'est exactement ce que je voulais dire. La JVM ne peut pas avoir que des inconvénients :-)

Et oui, je vais lire ton article sur MISC!
Il est encore en librairie, ou il est en ligne?

Tout ce que tu décris existe déjà dans Java, ou bien déjà intégré, ou bien sous forme de bibliothèques open source.

Oui, mais tous est possible avec tous les langages, la question est combien ca coute.

Il y a des fonctions qui sont pénibles a émuler dans des libs, parce qu'elle font naturellement partie du langage. Essaie d'émuler en Java les énumérés d'Ada ou les tableaux indicés arbitrairement, par exemple. Ce sera lourd.

De même, les défauts de conception du langage se rattrape rarrement, car il faut préserver la compatibilité ascendante. Par exemple, un langage qui est "case-sensitive" au départ se trainera ce boulet à vie.

Hum, je vois que tu connais Java aussi bien que je connais Ada...

Peut-être moins bien, même :-) c'est pourquoi j'aime bien ce genre de discussion qui remet les opinions à jour.

Dans 99% des cas, ce ne sont pas les connaissances sur Java ou C++ qui manquent, comme on le voit ici, mais sur Ada. Regarde par exemple pourquoi je suis intervenu dans ce thread : quelqu'un c'est moqué de ce que l'on pouvait qualifier Ada de moderne...
Il y a des idéees fausses qui circulent sur tout, mais sur Ada ca dépasse l'entendement. Pourtant Ada est libre, gratuit, puissant, facile à a mettre en oeuvre, a une excellente courbe d'apprentissage, est portable, clair, etc. etc.
Ce n'est pas seulement un langage de choix pour les applis temps-réels enfouies, mais également pour les gros softs en général. C'est normal, contrairement à Java ou C++, il a été conçu pour ca.
L'élément nouveau, c'est que ces préoccupations qui ne concernait dans les années 70/80 que les logiciels militaires ou nucléaires sont maintenant le quotidien de plein de logiciel libre, comme Apache ou le kernel Linux, par exemple.

Je ne conseille évidemment pas de refaire un truc qui marche, même en basic, juste pour le plaisir de changer de langage. Mais si certains se pose la question du langage au départ d'un projet, ce serait dommage d'éliminer celui qui est peut-être le plus adapté simplement à cause d'une mauvaise image.

Concernant enfin l'aspect réparti, je suis impressionné. As-tu de la doc ou des références à me conseiller sur le sujet ?

Il y a des références sur le site de Sam Tardieu : http://www.rfc1149.net/biblio(...)

(DSA est l'acronyme de Dystributed System Annex)

Par exemple "Objets répartis avec Ada 95" est en français, et fait un // avec CORBA, ce qui facilite la compréhension, ou bien "Building Robust Distributed Sytem".

Sinon, le plus simple est de parcourir les exemples distribués avec.

Ada contient plus que deux choses intéressantes, heureusement :-)
Pour les génériques versus les templates de Java 1.5, no comment, je ne connait pas Java 1.5.

Pour le typage, il ne se réduit pas à la la simple contrainte de range. La richesse du typage Ada est inégalée. Il y a quelques exemples dans l'article Introducing Ada sur CodeMage : http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/Introducing(...)
et des comparaisons plus directe avec Java dans Multilanguage Programming on the JVM: The Ada 95 Benefits http://libre.act-europe.fr/Why_Ada/ada-on-jvm.pdf(...)

Imiter par une classe n'est pas forcément simple. Prend la basique déclaration d'un type float à point fixe définissant un pourcentage avec une précision mini de 1/1000 : tu écris
type Percent is delta 0.001 range 0.0 .. 100.0;
En dehors des opérateurs habituels, tu devra écrire le code des attributs standard Small, Delta, Fore, Aft, Digits, Scale et Round. Ta classe ne va pas être triviale.

Ca se complique encore si on parle mapping mémoire. Si je décrit par exemple un registre avec un booleen en bit 1, un integer en bit 2 a 5 et un énuméré sur les bits 6 à 16, ce que je fais par une simple déclaration en Ada, ta classe devra en revanche contenir du code pour décaler les bits et récupérer les champs.

Je ne sais pas ce qu'est l'architecture de sécurité. Pour l'introspection et le chargement dynamique de classe, il est vrai que c'est utile. Mais Ada est un langage compilé, et dans ce domaine, la bataille n'est pas "fair" :-)

Je ne peux pas te montrer ici que les points fort d'Ada ne se limitent pas à deux choses, alors je vais choisir un exemple pour moi spectaculaire : l'annexe distribuée. Elle permet de distribuer une application normale sans en changer une ligne de source.
C'est à dire qu'a partir des même sources, je peux compiler une appli monolitique tournant sur une machine, ou répartie sur plusieurs machines avec différents OS et différents Byte ordering.
Sans changer les sources, et sans le moindre appel explicite à RPC ou autre middleware.

Je le rappelle, je parle d'un logiciel libre, dispo sur de nombreuses plateforme et que tu peux essayer tout de suite en faisant (par exemple) apt-get install gnat-glade :-)

Juste quelques questions et remarques, vu que ça fait bien longtemps que je n'ai pas programmé en Ada et donc que je ne connais pas bien la version 95. Pour la productivité, les programmes non buggués, etc. il y a aussi de nombreuses études qui montrent que Java explose C++ et C, et je t'avoue que je ne suis pas super convaincu. J'ai vu chez Thomson (oups Thales) de bons ingénieurs bosser en Ada et en C++, et franchement, ce qui faisait la différence avec les nazes, c'était plus les méthodes travails que le langage.

Que Java soit plus productif que C++, c'est normal, le langage est mieux conçu.
Qu'il vaille mieux avoir un bon avec visual C++ qu'un naz avec GNAT, je suis d'accord, c'est également mon expérience.
Mais pour comparer les langages, gardons tout égal par ailleur, sinon on va pas s'en sortir :-)

Je suis d'accord (à 98% :-) avec tout ce que tu dis, mais je te trouve un peu pessimiste sur la question de la dispersion.
La communauté du libre est tellement immense que peu importe si les initiatives sans lendemain foisonnent. Ce qui reste est énorme.
Par exemple, je ne suis pas sur que nos bureaux sous Linus seraient meilleurs si Kde, Gnome et GNUStep ne faisaient qu'un.

Tant mieux.
Juste pour être clair, je ne voulais pas troller Eiffel qui est pour moi un des bons élèves de la classe.

Juste pour info : dans quels domaines utilises-tu Ada (toi, personnellement - pas "en général") ? Est-ce que tu bosses dans une boite où on code en Ada, on fait plein d'applis avec qu'on vend à des client ?

:-)
J'utilise actuellement Ada 95 dans les communications tactiques militaires chez Thales. Je t'épargne le reste de mon CV, qui commence dans l'industrie, avec Ada, en 91.
T'es tellement ancré dans tes certitudes que tu ne crois pas un seul instant que je puisse être un gars sérieux et expérimenté qui parle en connaissance de cause. Il doit forcémment y avoir une faille...

Donc le langage ne sert à rien, dans l'état actuel des choses. Java ou C# feront bien mieux le boulot.

Le langage ne sert à rien parce que j'ai l'embarras du choix dans les libs?
Soyons sérieux!


Descend de ton petit nuage rose. Une lib standard maintenant, c'est au minimum un parseur xml (DOM et SAX) et html, http, ftp, une toolkit graphique, un framework pour faire de l'appel de méthode à distance (genre RMI/CORBA/SOAP etc...), la sérialisation de n'importe quel objet, la gestion de date/heure, etc... et ça pas en GPL parce que tout le monde ne fait pas du libre, merci.

...
Sans compter l'existence d'outils genre IDE, framework de test unitaire et de profiling...

Tout cela existe en Ada, en lib ou dans le langage.
Oui, tout.
Je ne me lance pas dans l'énumération : comme tu aurais pu en avoir confirmation en 5 minutes avec google, je suppose que tu n'as que faire des réponses.

Java et C# on a ça en standard. Pour C++, y a Qt qui fait à peu près le boulot. Autrement : ton langage ne sert à rien à part pour certaines applis spécialisées.

Ben oui, mais Ada et quelques centaines d'autres langages ont ca aussi. Mais tu va bien réussir à éliminer deux ou trois obscurs dialectes avec ce genre de critère...


Bref, reviens nous voir quand il existera theadaserverside.com, et une version d'Intellij Idea pour Ada.

Je ne connais pas, mais c'est peux comme si je te disais reviens me voir quand tu auras des User defined assignement et des clauses de représentations : la moitié des lecteurs ne connaissent que de nom, alors ca fait sacrément avancer le débat!

C'est l'erreur d'appréciation habituelle de ceux qui ne connaissent pas Ada. Pour prendre le dernier chiffre que j'ai vu passé, toute chose étant égales par ailleurs, un soft en Ada a en moyenne 4 fois moins de bug trouvé après livraison qu'un soft en C. Je passe sur les autres chiffres (dispo pour celui qui cherche un minimum), qui montre les gains spectaculaires en cout de developpement, de test et même de temps de localisation des bugs. Cela ne s'explique pas par les simples défauts syntaxiques, et il ne s'agit pas d'une querelle des "{}" contre les "begin end". Ne te contente pas de survoler un pdf, essaye avec objectivité avant de juger. Personnellement, je ne trouves pas "assez mineur" de devoir passer 4 fois plus de temps en tête à tête avec gdb. L'argument de la lib standard est caduque, puisque le groupe Ada de l'ISO qui procède en ce moment à la seconde révision du langage, planche sur le sujet. Il est vrai que la lib existante ne contient pas, par exemple, de structure de données. Il faut piocher dans les lib dispo en GPL, et il y l'embarras du choix, ce qui n'est pas un avantage. Mais note également que je peux te retourner l'argument, puisque Ada propose en standard des choses pour lesquelles il te faudra en Java piocher dans une lib extérieure. Soyons positif : pour faciliter ton passage à Ada, et si c'est pour toi le plus important, c'est la... lib :-), il existe un strict équivalent de la STL en Ada et en GPL. Tu vois, tu n'as plus de raison d'hésiter, tu naviguera en terrain connu!

On ne peut pas comparer Ada et Perl ou Python, ce n'est pas la même vocation. Ada n'est pas un langage de script, Ada est fait pour le génie logiciel. Son crénau, c'est pil poil des gros projet comme Apache ou le kernel Linux, écrit par des centaines de personnes, dont le code est relu des milliers de fois et pour lesquels il faut intégrer chaque jour des dizaines de patchs en limitant les effets de bord. Ada permet de faire tout ce que tu fais en C/C++/Java, goretteries comprises. Il est donc au moins aussi souple. Comme il permet également de faire des choses que les autres ne font pas, il est donc plus souples. Tu peux pas faire plus caré, comme raisonnement! Plus sérieusement, Ada te propose une sémantique de haut niveau que tu n'a pas en C++ ou en Java. Cela te permet de décrire dans le code des choses que les autres mettent dans les commentaires ou dans des doc, avec toutes les incohérences que cela entraine. En Ada, le source en dit tellement que beaucoup de commentaires sont évités. Et bien sur, le compilateur qui est ton meilleur ami vérifie pour toi. Moi, je ne trouve pas qu'un outils puissant soit chiant. Ce que je trouve chiant c'est de galérer deux heures pour trouver un bug qui aurait été tout simplement impossible avec Ada.

Je rève! Ton argument, c'est que Java c'est moins bien que C ou C++ parce que plein de gros projets l'utilisent? C'est un argument de mouton de Panurge 5ième Dan, ca!! Tu te rends compte que tu parles d'un sur-assembleur des année soixante et d'un langage expérimental démoulé trop chaud et devenu universel à la surprise général? Je manque d'imagination, mais j'en ai assez pour envisager que leur utilisation dans tout un tas de projet est du à beaucoup d'autres facteurs que les qualité techniques. Bon, j'arrète de faire l'avocat de Java (j'ai une réputation de sérieux à défendre :-) mais ton argument vaut zéro. Exemple : je ne connais pas UN SEUL programme "sérieux" fait avec Eiffel, et pourtant, c'est un langage moderne, c'est à dire conçu avec une vrai préocupation de génie logiciel. C, C++ et Java font pâle figure à coté. PS : en revanche, merci pour ce grand moment d'humour : la critique de Java sur la portabilité entre compilo et entre plateforme, suivit de l'apologie de C/C++, ca vaut 10/10!

Et puis si tu veux profiter des API Java, de la JVM et même de .NET, tu n'est pas obligé de te contenter d'un langage de second choix. Il y a des compilateur Ada pour la cible JVM, des bindings aux API et même A#, voir http://www.ada-france.org/article27.html. Ne pas confondre langage et API/Framework/JVM/etc./etc.

J'espère que tu n'es pas assez naif pour croire que ce qui est plus récent est meilleur? Plus probablement tu parles sans savoir, et tu propages une des idées recue les plus commune mais également une des plus fausses. Contrairement à ce que tu crois, à côté d'Ada, Java est un langage d'une pauvreté à faire pleurer. Va lire http://libre.act-europe.fr/Software_Matters/03-C_pitfalls.pdf. Lors de la prochaine allusion à Ada, t'aura l'air de connaitre ton sujet, au lieu d'avoir l'air d'un mouton de panurge.

| Le kernel de mandrake inclut le patch grsecurity, et la sécurisation se fait via
| msec, qui, par exemple, restorent les permissions, vérifient les logs etc.

Le patch grsecurity est d'ailleurs un vrai régal à appliquer et régler sur Debian.
Le site de grsecurity a des présentations très intéressantes sr le deal perfo/sécurité.

Quand aux autres outils, ils sont présent en abondance dans la Debian normal.
Pour s'en persuader, et puisque personne n'en à parlé, je donne l'URL indispensable pour accompagner cet article : http://www.debian.org/doc/manuals/securing-debian-howto/.(...)
Ne me remerciez pas, tout le plaisir a été pour moi :-)