Lionel Draghi a écrit 119 commentaires

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",

MDR.

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).

Ah bon, parce que si on ne réagit pas dans la journée, il faut la fermer?

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...

| 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...

Salut Alexis,

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

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.

Lionel Draghi

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.

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.