Guillaume Laurent a écrit 1148 commentaires

euh ObjC est utilisé pour faire un desktop et il y a de TRES nombreuses applications utilisé par BEAUCOUP de monde

C'est pour ça que plus bas j'en re-parle à propos de Mac OS/X. Ceci dit, hors de MacOS/X, Objective C existe encore moins qu'Ada ou Eiffel.

Au passage, le dernier article (beale) date de 1997, ainsi que le précédent. Pas de date sur celui d'HP, mais il remonte au moins à plus d'un an (avant le merge Compaq), et le 2eme aurait paru dans Eiffel World vol 4. Or si je regarde :

http://archive.eiffel.com/doc/eiffelworld/backissues/05_2001.html(...)

je constate que l'edition de Mai 2001 est le volume 13. D'après les autres archives il y a un volume par trimestre, donc 9 trimestres entre les deux, soit à peu près 2 ans, ça fait remonter ton article à 98.

T'as pas plus récent comme références ? :-)

Ne te méprends pas : je ne veux pas faire de prosélytisme pour Eiffel. Cependant, dire que c'est un oublié de l'industrie est faux : la vérité serait plutôt que c'est marginal.

C'est ce que je voulais dire par "oublié". Le simple fait qu'on puisse faire une telle liste de projets utilisant un langage prouve qu'il est totalement annecdotique. Ruby a la même, par exemple. Est-ce que tu imagines une telle page pour C++ ou Java ? A leur tout début, peut-être. Maintenant non, ça serait ridicule.

Ca peut évoluer. Une amère victoire d'Eiffel serait qu'il s'impose avec .NET.

Des collègues qui ont vu la présentation de Eiffel# de Meyer avaient plus ou moins cette impression là : il espère sauver Eiffel à travers .NET. Sans aucune chance d'y arriver, bien sur.

Une des grandes forces d'Ada est que l'on peut développer des logiciels critiques avec. Ce n'est pour l'instant pas le cas de Java.

Ah bon ? Java est utilisé dans des environnements critiques il me semble. Je n'ai pas d'exemples de cas où "critique => si ça plante y a des morts", mais "critique => si ça plante y a des millions de $ qui s'envolent" oui.

Ben là comme ton argument avait une certaine logique ("ça se vend bien la preuve c'est que y en a plus"), y avait quand même un énorme doute. :-)

J'utilise actuellement Ada 95 dans les communications tactiques militaires chez Thales.

Ça c'est le domaine de prédilection d'Ada depuis toujours. Et tu y utilises fréquemment tous les buzzwords (xml, http, etc...) dont on parle ?

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

Tu es surement sérieux et expérimenté, mais tu confirmes toutes mes certitudes. A chaque discussions sur C/C++/Java/C#, il y a quelqu'un qui se pointe avec son langage chéri sous le bras en disant qu'il est 100 fois mieux. En général c'est Lisp, Ada, Eiffel, ou Objective C (les grands oubliés de l'industrie en gros). La personne connait à fond le langage, l'utilise souvent professionnellement, et ne se rend jamais compte qu'elle est dans une niche complètement à part du reste de l'industrie (sauf ObjC qui va peut-être redevenir un peu plus mainstream avec MacOS/X). Et bien sur, il y a toujours le cortège de stats comme quoi le langage en question fait n% moins de bug que C, tourne n% plus vite que Java, et a tout plein de libs absolument pas standard, et que c'est vraiment dommage qu'on l'utilise pas plus.

Tu es exactement comme le fan linuxien de base, qui bosse dans une SSII proposant des produits libres, et qui ne comprend pas qu'on puisse utiliser Windows alors que c'est si facile d'apprendre Linux et que toutes les applis sont là, ou presque parce que "ok pour ça c'est pas encore tout à fait au point mais bientôt ça sera super-génial".

Le langage ne sert à rien parce que j'ai l'embarras du choix dans les libs?

Bien sur que oui voyons. D'abord pour un soft commercial tu cherches toujours à réduire au maximum tes dépendances vers des produits externes. Entre les problèmes d'install, de packaging, de license, de compatibilité, etc... c'est toujours une source de problèmes. C'est pour ça qu'en C++ une lib comme Qt cherche à fournir un maximum de fonctionalités, pour que tu n'as pas à aller chercher ailleurs, et que les libs de Java ou C# sont aussi complètes.

Ensuite, avoir l'embarras du choix est précisément ça : un embarras. Il faut se farcir l'évaluation de toutes ces libs pour être sur de prendre la bonne, ce qui prend toujours un temps non négligeable.

Et puisque tu dis que le comité de standardisation d'Ada planche sur une lib standard, que vont devenir les libs actuelles ? C'est exactement l'un des gros problèmes de C++, plein de libs ont du inventer leur conteneurs, interoperabilité zero, et quand la STL est arrivée c'était trop tard, il faudra encore des années pour qu'elle s'impose définitivement. Pour des trucs plus avancés comme une toolkit graphique, etc... c'est même plus la peine.

Donc actuellement, si j'ai le choix entre un langage avec une lib standard bien fournie et un autre pour lequel j'ai "l'embarras du choix", j'irais toujours vers la lib standard, spécifiée et documentée.

Tout cela existe en Ada, en lib ou dans le langage. Oui, tout.

Un google de "ada graphic toolkit" ne me sort que GtkAda. Tu veux plaisanter j'espère ??

Pour "ada sql driver", j'ai GNUAda, sous GPL. Dommage.

"ada ide" donne le truc d'ACT, qui utilise GTK+. Il y en a d'autres ? Les screenshots font pitié à coté d'un truc comme IntelliJ.

"ada xml parser" me renvoie encore vers ACT. Le marché Ada est en pleine expansion on dirait :-). Si le comité de standardisation d'Ada reprenait tout ce que fait ACT, ça pourrait peut-être passer.

Ceci dit, il y a encore du boulot :

http://libre.act-europe.fr/xmlada/xml_toc.html(...)

La doc est extrèmement limitée, DOM n'a pas l'air d'être complètement implémenté, et au passage on apprend qu'Unicode n'est pas en standard dans Ada. Ça c'est du langage qu'il est moderne.

"ada http implementation" : rien.

Je suis tombé aussi sur http://www.adapower.com/,(...) qui montre bien l'état des lieux. Sur la page "Compiler and Tool Vendors" :
http://www.adapower.com/411/vendors.html(...)
on trouve le nombre ahurissant de 14 entreprises.

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

Tu devrais connaitre ou au moins en avoir entendu parler. Le but n'est pas de te citer des refs que tu ne connais pas, mais au contraire d'en citer qui soient représentatives de ce qui se fait en Java ou C# actuellement :

http://www.theserverside.com(...)
http://intellij.com/idea/(...)

Bref, Ada a trouvé sa niche, tant mieux pour lui, car il va y rester.

En principe, quand un livre est épuisé, c'est qu'il a du succès, non ?

Pas vraiment. Si il a du succès, on refait un tirage.

Toutes les applis java que j'ai testé dans ma vie ont toujours ramé

Tu as essayé sous Windows ? C'est triste à dire, mais Java y tourne beaucoup plus vite que sous Linux, la version Windows du JDK de Sun est bien plus performante que la version Linux. Je développe en Java au boulot, je suis sous Linux à coté de 3 collègues sous Windows, la différence de perfs à machines égales est effarante.

Et bien simplement quand tu déclares un objet qui doit être compatible C, tu le déclares final ou un mot clé avoisinant.

Comment ? Dans un source C++, j'inclus time.h, que je ne peux évidemment pas modifier, je veux récuperer struct tm et la dériver ou la passer à des fonctions C++, comment je dis que ça doit rester un objet C ?

Je ne suis vraiment pas sur que ta méthode soit plus simple.

prends un compilateur C de Intel et fait une librairie qui utilise gnome, ensuite prends un compilateur C de borland et fait une AUTRE librairie qui utilise Gnome. Finalement fait une application en C (compilee avec GCC) qui utilise la premiere et la seconde bibliotheque... Et bien, ca marche...

En pratique ça n'arrive jamais, tu compiles toujours tout avec le même compilo.

Le C++ c'est pas encore stable et standardise.

Si, même l'ABI (enfin). Tous les compilos ne l'implémentent hélas pas. C'est un problème, mais rarement bloquant.

Gnome 2.2 est totalement compatible avec 2.0.

Tu te rends bien compte que ça n'a absolument rien à voir avec ce que tu décris plus haut ?

Et ca, c'est plus facile a faire qu'en C++, ou la tentation est trop simple de rajouter des membres dans des classes pour fixer des bugs, ou bien ajouter des fonctions virtuelles...

Parce que le fait de faire de l'OO en C t'empèche d'ajouter des membres ou des méthodes virtuelles ? Enfin si, strictement parlant ça t'empèche un peu parce que c'est beaucoup plus chiant à faire qu'en C++. Mais les contraintes pour rester compatibles sont exactement les mêmes. Ce que tu dis n'a aucun sens.

Moi je trouve ca genial de pouvoir modifier dynamiquement le message dispatch... Et c'est facile a faire en OO C... C++ n'apporte rien!

C'est vrai, c'est tellement bien de faire soi-même le boulot du compilateur. D'ailleurs on devrait virer for() et while(), ça n'apporte rien par rapport à if() et goto.

Il aurait fallu faire exactement le contraire, à savoir par défaut virtuelle, et optionnellement non virtuelle [...]

Je vois mal comment garder de manière confortable la compatibilité avec C dans ces conditions. Et ce que tu appelles un "cas marginal" est en fait l'une des raisons du succès de C++.

Et, encore une fois, inclure une notion aussi complexe que l'analyse du code dans un compilo n'est pas gratuit, surtout à l'époque ou C++ a commencé. J'ai fait du C++ pour la première fois en 92, c'était tout à fait utilisable sur les Sun Sparc de l'époque. A la même époque, ces mêmes machines mettaient littéralement des heures à compiler un "hello world" Eiffel.

C'est toujours facile de dire "ça c'est une connerie" quand on arrive 15 ans après la bataille. Je serais plutôt du coté de Stroustrup, quand il dit que le gros loupé de C++ c'est de ne pas avoir rapidement fourni une lib standard complète. Le mot clé "virtual", c'est relativement anecdotique.

Je croyais que tu avais des points particulier à reprocher au C++ managé, par rapport aux autres langages .NET...

Je n'ai rien à lui reprocher, je constate juste que, comme les autres langages de .NET hormis C#, son but est de faciliter la récupération du code existant, pas de servir d'alternative à C#. Ce qui est à mon avis une excellente chose, d'ailleurs.

Mais Java a ses gros défauts. C'est un glouton de mémoire, c'est parfois
très lent et surtout... ce n'est pas utilisé dans la "vraie vie"

Si "la vraie vie" pour toi c'est Source Forge, je te conseille de sortir un peu :-).

Qualifier C# de plus agréable est grotesque.

Euh, jusqu'a présent à part quelques accros du Java, tous les programmeurs C++ ou Java que je connais (à commencer par moi-même) à qui on a montré C# trouvent qu'il est bien mieux que Java (je bosse dans une boite où on ne fait plus que de Java après avoir fait beaucoup de C++). Les différences ne sont pas du tout minimes, au contraire ils ont tiré les leçons de Java de même que Java avait tiré les leçons de C++.

Sur les méthodes virtuelles, une grosse bouse du C++

C'était nécéssaire pour garder la compatibilité avec C. Et si les premiers compilos C++ avaient du implémenter une analyse globale du code pour optimiser ça, on s'en serait jamais sorti.

Par ailleurs, en C# les méthodes ne sont pas virtuelles par défaut. Je ne me souviens plus exactement pourquoi... une limitation de leur runtime, quelque chose dans ce genre.

C'est l'erreur d'appréciation habituelle de ceux qui ne connaissent pas Ada.

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 ?

un soft en Ada a en moyenne 4 fois moins de bug trouvé après livraison qu'un soft en C.

Oh ben ça alors, quelle surprise. Et par rapport à Java ?

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 sera caduc quand ils auront fini et que tous les compilos Ada l'implémenteront.

Il est vrai que la lib existante ne contient pas, par exemple, de structure de données.

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

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.

Comme quoi ? Est-ce que ce sont des choses utiles ?

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.

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

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.

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

Ah non, après recherche y a bien toujours les templates, mais pas avec des classes managées : http://www.gotw.ca/publications/standard_c++_meets_managed_c++.htm Par contre la liste des keywords ajoutés est quand même impressionnante : http://www.ondotnet.com/pub/a/dotnet/2003/01/13/intromcpp.html d'où le fait que ce langage n'est pas concu pour être utilisé pour développer des applis entières, mais plutôt pour récuperer facilement du code C++ existant, ou éventuellement écrire des parties "sensibles" point de vue perfs.

Va lire http://libre.act-europe.fr/Software_Matters/03- Je suis en train de le parcourir, et franchement, c'est l'habituelle litanie des pro-Eiffel/Ada qui pinaillent sur des défauts assez mineurs de C/C++/Java (en gros : "la syntaxe elle est pas bien, ouuuuhhh"). Que je sache, Ada n'a pas une lib standard comparable à celle de Java. Un langage ne peut pas prétendre concurrencer Java ou C# si il n'a pas au moins une lib standard aussi fournie. C'est ce qui compte le plus actuellement.

Ah ? Ca sort d'où ? De n'importe quel programmeur qui connait et utilise les 2 langages.

D'être encore plus complexe que C++ (la nécéssité de déclarer les classes "managed" ou pas) tout en retirant des features (les templates, si je me souviens bien).

Non il existe le C#, le J# (marrant non ?) le VB.net et ainis de suite.

Je ne dis pas le contraire, relis ce que j'écris. Le fait est qu'en pratique, la plupart de ces langages existent en .NET sous des formes limitées, ou pas simples du tout à utiliser (l'exemple le plus frappant est Managed C++), et leur but n'est pas d'être utilisés pour développer des applis entières mais juste servir de "glue" pour passer sous .NET des applis existantes.

En gros, la même chose que JAVA, avec la possibilité de choisir le langage dans lequel tu programmes.

Pas vraiment. En .NET tu développes en C#, rien d'autre. Le multi-langage n'est là que pour récupérer relativement facilement du code existant (par exemple pour .net-ifier une vieille appli sans avoir à tout ré-écrire), mais les versions .NET des langages comme C++ sont bien trop complexes et limitées pour être raisonnablement utilisées pour écrire une appli partant de zéro.

Par contre, par rapport à Java, .NET offre de bien meilleures performances à l'exécution.

On ne parle pas de la même chose. Il y a pleins d'autres implémentations de Java en plus de celle de Sun, les specs sont disponibles, et Sun encourage ces implémentations. Que Sun controle l'API de Java est un autre problème.

Légalement ca m'etonnerait qu'ils acceptent,

Pourquoi pas ? Il n'est pas dans l'interêt de MS d'être les seuls fournisseurs de cette API.

techniquement certaines fonctions n'ont pas d'équivelant

Ça n'est pas forcément insurmontable, Java a déjà été confronté au problème avec les différentes versions du JDK (embarqué, pas embarqué, Standard Edition, Enterprise Edition, etc...).

Je crois que le principal obstacle est surtout que la lib standard .NET est énorme. Il faudrait une très grosse équipe à temps plein pour arriver à la refaire.

Dans la bd, Wolverine et son entourage sont très conscients que les griffes de celui-ci sont des armes faites pour tuer, et wolverine ne les utilise presque jamais contre des êtres vivants, surtout pas contre des humains.

Tu dois confondre avec Winnie l'Ourson.

Dans la BD les accès de rages de Wolverine sont bien pires que ce qu'on voit dans le film, et sont le plus souvent contre des êtres bien vivants (même si ils ne le restent pas longtemps), y compris des êtres humains. Wolverine est un tueur, c'est tout ce qui fait l'attrait du personnage.

Oui mais lui a justement écrit une introduction qui est "contre" le reste du livre, donc moins outrageant pour la faune de linuxfr.