Mono 0.24

Posté par Sidoine de Wispelaere le 08 mai 2003 à 00:23. Modéré par Nÿco.

Étiquettes :

• code

0

8

mai

2003

La version 0.24 de Mono, l'implémentation libre de .NET, initiative de Ximian, est sortie. Elle utilise notamment un nouveau générateur de code nettement plus performant.

Par ailleurs le compilateur C# se paie le luxe de proposer les itérateurs, encore absents du C# de Microsoft.

Notez également l'apparition du site communautaire http://www.gotmono.com/ visiblement inspiré (au moins par son nom) de http://www.gotdotnet.com/. Ce site n'est pour l'instant pas très avancé.

Aller plus loin

• Mono (3 clics)
• GotMono (3 clics)
• GotDotNet (1 clic)

• [^] # Re: promouvoir Java plutot que C#

  Posté par Jar Jar Binks (site web personnel) le 08 mai 2003 à 17:16. Évalué à -4.

  

  Au lieu de t'extasier sur ce ssssssssplendide logiciel propriétaire jusqu'aux orteils qu'est Java, tu pourrais comparer tout ça à des langages un peu plus souples, plus modernes, et surtout libres : python, Ocaml, Ada, smalltalk, ruby...
  
  Tiens, il se trouve qu'il y a des bouts de Gnome dans ces langages, et que ça va croissant. Bref, heureusement que les développeurs Gnome ont un peu plus de jugeotte que les fanatiques du java à tout prix comme toi (on dirait les maqueux, prêts à tout défendre dans ce que fait cette bande de salopards d'Apple) et qu'ils se mettent petit à petit à ces langages, suivant les avantages du langage pour le composant et les compétences des développeurs.
  D'un côté le choix, le logiciel libre, l'interopérabilité, la diversité, la performance (oui je sais vous allez dire que Gnome n'est pas performant, mais faut voir à quoi on compare). De l'autre, une usine à gaz propriétaire qui impose l'utilisation d'un langage unique.

  • [^] # Re: promouvoir Java plutot que C#

    Posté par tanguy_k (site web personnel) le 08 mai 2003 à 17:57. Évalué à 6.

    

    > heureusement que les développeurs Gnome ont un peu plus de jugeotte
    
    Si les developpeurs Gnome avaient eu un peu de jugeotte ils se seraient pas fait chier a re-inventer la roue avec du C bas niveau et auraient utilise un autre langage plus adapte aux developpement d'applications graphiques pour le desktop AMHA
    
    > les fanatiques du java à tout prix comme toi
    Merci, je developpes actuellement a 70% en C++.
    
    > cette bande de salopards d'Apple
    Pour meriter cette appelation ils ont fait quoi ? tuer des gens, piller ta maison ? ou alors c'est parcequ'ils gagnent de l'argent avec des logiciels proprietaires ? Je rappelle qu'ils ont contribue a khtml, XFree et utilise des logiciels libres, c'est des demi-salopards alors...
    
    > ils se mettent petit à petit à ces langages, suivant les avantages du langage pour le composant et les compétences des développeurs
    C'est pourquoi je parle de binding. Mais je pense qu'un binding Java a plus d'avantages pour le developpement d'applis desktop que les autres langages, et plus que C# aussi.
    
    > une usine à gaz propriétaire qui impose l'utilisation d'un langage unique
    Rien ne t'empeche d'utiliser une implementation libre de Java.
    Rien ne t'empeche d'utiliser un autre langage en meme temps que Java, c'est meme fait pour !
    Tu peux utiliser d'autre langage que Java sur la JVM
    Le commite qui discute de l'evolution de Java est "ouvert" (cf les templates qui sont ajoutes dans le jdk 1.5 alors que Sun n'en voulait pas)
    Tu peux meme te passer de la JVM si tu trouves ca trop lourd.
    
    Enfin bon de toute facon tes trolls...

    • [^] # Re: promouvoir Java plutot que C#

      Posté par boubou (site web personnel) le 08 mai 2003 à 18:06. Évalué à 3.

      

      Pour meriter cette appelation ils ont fait quoi ?
      
      Laisse tomber, c'est Jar Jar. En général, les discussions avec lui finissent par "coin coin".

    • [^] # Re: promouvoir Java plutot que C#

      Posté par Guillaume Proux le 09 mai 2003 à 15:56. Évalué à 3.

      

      >Si les developpeurs Gnome avaient eu un peu de jugeotte ils se seraient pas fait chier a re-inventer la roue avec du C bas niveau et auraient utilise un autre langage plus adapte aux developpement d'applications graphiques pour le desktop AMHA
      
      Mouais, sauf que les gars qu'ont fait Gnome, c'est pas des hackers de sandwich au Jambon style Kevin tu vois. Si tu lis le bouquin tres sympa ecrit par Havoc, tu verras que ils avaient un goal tres precis pour leur API: la compatibilite binaire. Ca veut dire quoi? En gros, 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...
      
      Essaie de faire pareil avec un framework C++... Et bien oui, rammasse tes yeux pour pleurer. Le C++ c'est pas encore stable et standardise. Gnome commence vraiment a utiliser cette puissance de la compatibilite binaire (souvent ecrit BC en anglais). Gnome 2.2 est totalement compatible avec 2.0. 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...
      
      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!

      • [^] # Re: promouvoir Java plutot que C#

        Posté par Guillaume Laurent (site web personnel) le 09 mai 2003 à 18:33. Évalué à 4.

        

        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.

        • [^] # Re: promouvoir Java plutot que C#

          Posté par Guillaume Proux le 10 mai 2003 à 01:55. Évalué à 2.

          

          Et ben non, en pratique (dans la vie d'un ingenieur pas opensource), t'utilises pleins de librairies dont tu n'as jamais eu le code source? (ou alors, je serais assez content que tu me files le src de kernel32.dll)...
          
          L'ABI est standardise oui, mais pas encore stable (tu peux verifier toi meme sur codesourcery, ya souvent des CR qui trainent).
          
          Evidemment, ca concerne surtout les boites qui developpe des logiciels impurs et infideles mais ne pensez vous pas que c'est pour ca que Sun, IBM et toute la clique ne veulent pas entendre parler de KDE?
          
          A la Balmer: "Developers, Developers, Developers!"

          • [^] # Re: promouvoir Java plutot que C#

            Posté par Guillaume Laurent (site web personnel) le 10 mai 2003 à 23:52. Évalué à 5.

            

            Et ben non, en pratique (dans la vie d'un ingenieur pas opensource), t'utilises pleins de librairies dont tu n'as jamais eu le code source?
            
            Oui, et qui ont été compilées avec le même compilo que celui que j'utilise. Je ne dis pas que l'ABI non standardisée de C++ ne soit pas un problème (ma boite vend entre autres des bibliothèques C++, à cause de ça sur chaque plateforme on doit fournir un binaire pour les principaux compilos disponibles dessus), mais en pratique il n'est pas aussi crucial que ce que Gnome pense. En comparaison, l'idée de refaire de l'OO en C et de se dire "c'est du C donc y a qu'a faire des bindings" leur a couté beaucoup, beaucoup plus cher.
            
            Evidemment, ca concerne surtout les boites qui developpe des logiciels impurs et infideles mais ne pensez vous pas que c'est pour ca que Sun, IBM et toute la clique ne veulent pas entendre parler de KDE?
            
            IBM n'a jamais pris position sur Gnome ou KDE. Il n'y a que Sun et HP a l'avoir fait, dans le but de remplacer CDE pour pas cher et de faire parler d'eux à l'époque où Linux était le gros buzzword du jour. Dans le cas de Sun le choix vient aussi (d'après ce que j'ai lu dans les interviews) qu'ils n'ont pas la culture de C++. Ils ont également évalués les deux au moment ou KDE était en pleine refonte pour KDE 2. De mon point de vue ils ont commis une bourde monumentale, mais ils semblent coutumiers du fait depuis quelques années (des potes bossant chez Sun m'ont dit que les mecs que Sun avait mis sur Gnome n'étaient pas exactement du haut du panier).
            
            De toute façon, pour aucune de ces boites le desktop Linux n'a d'importance, c'est sur le marché des serveurs qu'ils se positionnent. Pour espérer concurrencer Windows il faudrait qu'ils mettent énormément de ressources dans KDE pour écrire des applis, fignoler celles qui existent, rédiger de la doc, peaufiner les traductions, etc... avec pleins d'emmerdes à la clé parce que mélanger de l'industriel avec de l'open source c'est jamais évident (tu as toujours des intégristes qui hurlent au scandale), et un résultat final pas du tout garanti (en terme d'applications, Windows à tout de même une sacrée avance, et actuellement Win XP est assez stable pour qu'il soit vu comme équivalent à Linux sur ce plan là).

  • [^] # Re: promouvoir Java plutot que C#

    Posté par boubou (site web personnel) le 08 mai 2003 à 18:00. Évalué à 5.

    

    ssssssssplendide logiciel propriétaire jusqu'aux orteils qu'est Java
    
    Java n'est pas propriétaire, il est développé par un comité tout aussi ouvert que le consortium X l'était par exemple. La fondation apache participe régulièrement aux définitions (les JSR) qui font avancer la plate-forme. Certains éléments de celle-ci sont implémentés en open source, comme par exemple le moteur de référence (dixit Sun) JSP/Servlet (à savoir Tomcat). De même, la partie J2EE existe sous forme de deux implémentations open source (JOnAS et JBoss). Sun a pris position de façon officielle sur le support des développeurs open source en Java et sur la possibilité d'implémenter les specs en open source. De plus, classpath (projet GNU officiel), gcj, etc. implémentent (de façon incomplète, certe) en open source une grande partie de l'api Java, le seul élément qui manque encore pour que Java soit complètement open source. Parce comme tu racontes n'importe quoi, tu ne sais sûrement pas que le meilleur compilateur Java (à saoivr jikes) est open source et qu'il existe de nombreuses machines virtuelles open source qui fonctionnent plutôt bien (kaffe, Japhar, etc.).
    
    Avant de dire des conneries, renseigne toi. Si le reste de ton propos comprend autant de bêtises que le début de ta première phrase, on n'est pas arrivé...

  • [^] # Re: promouvoir Java plutot que C#

    Posté par ndv le 08 mai 2003 à 18:15. Évalué à 3.

    

    tu pourrais comparer tout ça à des langages un peu plus souples, plus modernes, et surtout libres : python, Ocaml, Ada, smalltalk, ruby...
    
    C'est incroyablement souple et moderne, Ada :p

    • [^] # Re: promouvoir Java plutot que C#

      Posté par Moby-Dik le 08 mai 2003 à 21:47. Évalué à -2.

      

      Bah, autant que Java.

    • [^] # Re: promouvoir Java plutot que C#

      Posté par Lionel Draghi (site web personnel) le 08 mai 2003 à 22:46. Évalué à 3.

      

      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.

      • [^] # Re: promouvoir Ada plutôt que Java ou C# :-)

        Posté par Lionel Draghi (site web personnel) le 08 mai 2003 à 22:54. Évalué à 1.

        

        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.

      • [^] # Re: promouvoir Java plutot que C#

        Posté par Larry Cow le 09 mai 2003 à 01:11. Évalué à 2.

        

        Il n'empèche qu'Ada est tout sauf un langage souple, son cahier des charges l'a même emmené dans la direction opposée. C'est un langage strict et "chiant" envers le programmeur, pour garantir au maximum une exécution sans faille. Autant je comprends qu'on qualifie Perl ou Python de "souple", autant pour Ada j'ai plus de mal :)

        • [^] # Re: promouvoir Java plutot que C#

          Posté par Lionel Draghi (site web personnel) le 09 mai 2003 à 02:07. Évalué à 3.

          

          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.

          • [^] # Re: promouvoir Java plutot que C#

            Posté par Larry Cow le 09 mai 2003 à 11:47. Évalué à 1.

            

            Ce que je voulais dire par "chiant", c'est qu'il ne te laisse pas faire ce que tu veux. Y compris le bug con. Beaucoup de gens trouvent Ada "chiant" justement par le fait qu'il t'empèche de te tirer dans la jambe. C'est bien sur un (énorme) avantage d'Ada, mais ca agace parfois un peu les débutants, c'est pourquoi j'avais mis ca entre guillemets.

      • [^] # Re: promouvoir Java plutot que C#

        Posté par Guillaume Laurent (site web personnel) le 09 mai 2003 à 01:32. Évalué à 1.

        

        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.

        • [^] # Re: promouvoir Java plutot que C#

          Posté par Lionel Draghi (site web personnel) le 09 mai 2003 à 03:02. Évalué à 2.

          

          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!

          • [^] # Re: promouvoir Java plutot que C#

            Posté par boubou (site web personnel) le 09 mai 2003 à 10:20. Évalué à 4.

            

            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. Sinon, et c'est la partie question, tu parles de la pauvreté de Java comparé à Ada, et la, je suis très très dubitatif. En effet, Ada contient deux choses très intéressantes, la notion de "templates" en bien mieux que les templates du C++ et la notion de contraintes sur les types (du genre un nouveau type int compris entre 0 et 100). Pour les templates, tu auras ça en Java 1.5, avec du F-bound polymorphisme qui, à ma connaissance, explose ce qui existe en Ada (mais bon, comme je le disais plus haut, je ne connais pas bien Ada 95). Pour les contraintes sur les types, il suffit de définir une classe (ok, c'est plus lourd qu'en Ada). Par contre, il existe de nombreuses choses en Java qui n'existent pas (à ma connaissance) en Ada. Je pense en particulier à tout l'aspect dynamique lié au chargeurs de classes, à l'introspection (les proxy dynamiques, quel pied), l'architecture de sécurité. Bref, je pense que les langages sont difficilement comparables en terme de fonctionnalité.

            • [^] # Re: promouvoir Java plutot que C#

              Posté par Lionel Draghi (site web personnel) le 10 mai 2003 à 02:00. Évalué à 1.

              

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

            • [^] # Re: promouvoir Java plutot que C#

              Posté par Lionel Draghi (site web personnel) le 10 mai 2003 à 03:29. Évalué à 1.

              

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

              • [^] # Re: promouvoir Java plutot que C#

                Posté par boubou (site web personnel) le 10 mai 2003 à 15:44. Évalué à 2.

                

                Hum, je vois que tu connais Java aussi bien que je connais Ada...
                
                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.
                
                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/(...)
                
                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).
                
                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 !
                
                Pour l'architecture de sécurité, tu peux lire mon article dans le dernier MISC ;-)
                
                Concernant enfin l'aspect réparti, je suis impressionné. As-tu de la doc ou des références à me conseiller sur le sujet ?

                • [^] # Re: promouvoir Java plutot que C#

                  Posté par Lionel Draghi (site web personnel) le 11 mai 2003 à 11:22. Évalué à 2.

                  

                  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.

                • [^] # Re: promouvoir Java plutot que C#

                  Posté par Lionel Draghi (site web personnel) le 11 mai 2003 à 12:43. Évalué à 2.

                  

                  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.

                • [^] # Re: promouvoir Java plutot que C#

                  Posté par Lionel Draghi (site web personnel) le 11 mai 2003 à 18:33. Évalué à 1.

                  

                  
                  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.

                  • [^] # Re: promouvoir Java plutot que C#

                    Posté par Guillaume Laurent (site web personnel) le 12 mai 2003 à 01:09. Évalué à 1.

                    

                    Par exemple, un langage qui est "case-sensitive" au départ se trainera ce boulet à vie.
                    
                    Je crois que tu aura beaucoup de mal à convaincre les gens actuellement qu'être "case sensitive" est un problème pour un langage :-).

                    • [^] # Re: promouvoir Java plutot que C#

                      Posté par Lionel Draghi (site web personnel) le 12 mai 2003 à 01:57. Évalué à 1.

                      

                      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.

                      • [^] # Re: promouvoir Java plutot que C#

                        Posté par Fabimaru (site web personnel) le 12 mai 2003 à 09:24. Évalué à 1.

                        

                        Bof. Il y a aussi d'autres façons de faire se ressembler des noms de variables (une lettre de plus)...
                        Personnellement, j'utilise en C++ la casse pour différencier les roles des variables:
                        
                        class UneClasse
                        {
                        void Fonction(int superParametre)
                        {
                        int super_locale;
                        }
                        };

                        • [^] # Re: promouvoir Java plutot que C#

                          Posté par Lionel Draghi (site web personnel) le 12 mai 2003 à 10:05. Évalué à 1.

                          

                          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.

                          • [^] # Re: promouvoir Java plutot que C#

                            Posté par boubou (site web personnel) le 12 mai 2003 à 10:42. Évalué à 1.

                            

                            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... Sinon, à titre personnel, je ne pense pas que la syntaxe soit tellement importante que ça dans le design d'un langage, mais j'accepte l'opinion contraire, en particulier quand je vois le succès de Python ou les idées de Sather (dans lequel un nom de classe doit être entièrement en majuscules, sauf erreur de ma part).

                            • [^] # Re: promouvoir Java plutot que C#

                              Posté par Lionel Draghi (site web personnel) le 13 mai 2003 à 01:43. Évalué à 1.

                              

                              Juste une remarque : certains compilateurs évolués, comme jikes pour java, sont capables de détecter des trucs du genre toTo utilisé à la place de toto, au sens où, en l'absence de symboles toTo, le compilateur va te dire qu'il ne trouve pas toTo, mais par contre qu'il trouve toto...
                              
                              Oui, GNAT aussi te sort aussi un truc du genre "Varriable_A_La_Con is possible mispelling de Variable_A_La_Con".
                              C'est d'autant plus sympa que GPS (l'IDE qui fait mal aux yeux délicats de Guillaume :-) permet de réinjecter la correction dans le code (et ca peut également s'ajouter au mode Ada d'emacs).
                              
                              Sinon, à titre personnel, je ne pense pas que la syntaxe soit tellement importante que ça dans le design d'un langage
                              
                              Je suis d'accord, la sémantique est bien plus importante, mais :
                              
                              1 - on a parlé que de la sensibilité à la casse, ce qui parait anecdotique pris isolément. Si tu ajoutes tous les autres pièges comme le = qu'on peut utiliser aux mêmes endroits que le ==, les nombres qui deviennent octal par la magie d'un zéro devant, les opérateurs cabalistiques (et il y en a jusque dans Eiffel ;-), la gestion piégeuse de la précéence des opérateurs, etc. etc., et bien c'est tout de suite moins anecdotique.
                              
                              2 - on a aucune raison d'être indulgent avec ces erreurs de conceptions des langages. Elles sont connues depuis bien longtemps, tu as une litérature abondante (dont mon chouchou, le guide du code inmaintenable), et surtout, surtout, ca ne coute rien de les éliminer.
                              Des milliards de neurones sont morts partout à travers le monde dans d'atroces soufrances en planchant sur "faut-il l'héritage multiple?". Une petite poignée d'entre eux, même choisit parmi les moins doués, aurait suffit à éliminer ces faiblesse syntaxique. Donc, pas de pitié!
                              
                              PS : pour être juste, tout ca aurait pu couter à C++ la compatibilité avec C, c'est à dire la vie :-), mais si on prend le cas de Java, cet argument ne s'applique pas.

                          • [^] # Re: promouvoir Java plutot que C#

                            Posté par Fabimaru (site web personnel) le 12 mai 2003 à 15:01. Évalué à 1.

                            

                            Utiliser cela, c'est un classique, mais ça s'appelle jouer avec le feux.
                            Je ne me souviens pas d'avoir eu une seule erreur sur les deux dernières années (ma mémoire ne va pas plus loin :-) ).
                            Tu ne penses pas que ça peut amener des programmeurs à nommer des variables différemment, et de rendre moins lisible ?

                            • [^] # Re: promouvoir Java plutot que C#

                              Posté par Lionel Draghi (site web personnel) le 13 mai 2003 à 00:29. Évalué à 1.

                              

                              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?

                        • [^] # Re: promouvoir Java plutot que C#

                          Posté par Philip Marlowe le 12 mai 2003 à 11:13. Évalué à 1.

                          

                          En Eiffel objet: OBJET sans problèmes et c'est insensible à la casse. Il y a un compilateur qui fait son boulot.

                        • [^] # Re: promouvoir Java plutot que C#

                          Posté par Philip Marlowe le 12 mai 2003 à 11:18. Évalué à 1.

                          

                          Ah oui et puis OBJET: objet objet: objet OBJET: OBJET et toute autre combinaison de majuscules/minuscules marche. Ceci dit, ce n'est pas la principale caractéristique du langage...

                • [^] # Re: promouvoir Java plutot que C#

                  Posté par Lionel Draghi (site web personnel) le 11 mai 2003 à 18:58. Évalué à 1.

                  

                  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?

                  • [^] # Re: promouvoir Java plutot que C#

                    Posté par boubou (site web personnel) le 12 mai 2003 à 10:45. Évalué à 1.

                    

                    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? Tu l'as dans le cul. Désolé d'être aussi vulgaire ;-), mais c'est la triste vérité. Java n'est pas du tout prévu pour ce genre de chose, c'est le moins qu'on puisse dire. Bien entendu, on peut toujours s'arranger en s'intrefaçant avec du C, mais bon... Et oui, je vais lire ton article sur MISC! Il est encore en librairie, ou il est en ligne? C'est le dernier numéro de MISC (le 7), en librairie mai et juin. Pour la mise en ligne, il faudra attendre une hypothétique autorisation de Diamon Edition...

          • [^] # Re: promouvoir Java plutot que C#

            Posté par Guillaume Laurent (site web personnel) le 09 mai 2003 à 11:19. Évalué à 0.

            

            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.

            • [^] # Re: promouvoir Java plutot que C#

              Posté par Moby-Dik le 09 mai 2003 à 21:31. Évalué à 1.

              

              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,
              
              Bienvenue dans l'île aux buzzwords ;)

            • [^] # Re: promouvoir Java plutot que C#

              Posté par Philip Marlowe le 09 mai 2003 à 21:36. Évalué à 2.

              

              Le domaine de prédilection d'Ada, c'est le temps réel dur. Exemple : commandes d'un avion.
              
              Ceci dit, la mutation objet, Ada 95, a soulevé tellement de controverses dès la période de son élaboration, que Jean Ichbiah, le créateur originel du langage, a claqué la porte avant même la fin des travaux.

            • [^] # Re: promouvoir Java plutot que C#

              Posté par Lionel Draghi (site web personnel) le 10 mai 2003 à 01:04. Évalué à 3.

              

              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!

              • [^] # Re: promouvoir Java plutot que C#

                Posté par Guillaume Laurent (site web personnel) le 10 mai 2003 à 11:01. Évalué à 4.

                

                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.

                • [^] # Re: promouvoir Java plutot que C#

                  Posté par Philip Marlowe le 10 mai 2003 à 12:51. Évalué à 1.

                  

                  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) [...]
                  
                  http://archive.eiffel.com/eiffel/projects/list.html(...)
                  http://archive.eiffel.com/eiffel/projects/calfp/page.html(...)
                  http://archive.eiffel.com/eiffel/projects/hp/creel.html(...)
                  http://archive.eiffel.com/eiffel/projects/montgomery/page.html(...)
                  http://archive.eiffel.com/eiffel/projects/beale/page.html(...)
                  
                  Le dernier lien est intéressant dans la mesure où le papier a été écrit par une personne qui avait initialement choisi Java et lui a finalement préféré Eiffel pour un projet.
                  
                  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. Ca peut évoluer. Une amère victoire d'Eiffel serait qu'il s'impose avec .NET.
                  
                  Une de mes connaissances dirige une SSII (où il n'y a aucun développement en Eiffel, d'ailleurs), où à côté de projets Java des gens font des travaux pour l'Agence Spatiale Européenne en Ada. La commande du métro Météor a été programmée en Ada après spécification formelle. 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.

                  • [^] # Re: promouvoir Java plutot que C#

                    Posté par Guillaume Laurent (site web personnel) le 10 mai 2003 à 13:22. Évalué à 2.

                    

                    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.

                    • [^] # Re: promouvoir Java plutot que C#

                      Posté par Philip Marlowe le 10 mai 2003 à 13:34. Évalué à 1.

                      

                      Une application critique est une application où des vies humaines sont en jeu. Dans le sens "il y a des millions d'€ qui s'envolent", il doit bien y avoir des applications écrites en Visual Basic...

                      • [^] # Re: promouvoir Java plutot que C#

                        Posté par boubou (site web personnel) le 10 mai 2003 à 15:50. Évalué à 2.

                        

                        Sans vouloir être désagréable, de nombreux DSP utilisés dans du matériel embarqué critique (genre controleur des canards dans un avion de chasse, etc.) étaient encore programmés en C ou en assembleur lors de mon passage chez Thales il y a une dizaine d'années. La majorité était en Ada, il est vrai.
                        
                        Sinon, je suis bien d'accord des applications critiques au sens fric, il y en a malheureusement en VB...

                        • [^] # Re: promouvoir Java plutot que C#

                          Posté par Philip Marlowe le 10 mai 2003 à 16:08. Évalué à 2.

                          

                          Je ne vois pas ce qu'il y a de désagréable dans tes propos. Aux USA, dans les boîtes genre Lockeed-Martin, ce genre de choses est fait systématiquement en Ada. Il me semble que imposé par les militaires, je crois avoir lu ça quelque part.

                          • [^] # Re: promouvoir Java plutot que C#

                            Posté par boubou (site web personnel) le 10 mai 2003 à 16:41. Évalué à 1.

                            

                            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é.
                            
                            Pour l'aspect "désagréable", je voulais juste dire que l'argument vie humaine n'est malheureusement pas toujours suffisant pour imposer des langages un peu moins engendreur de bug que le C, voilà, c'est tout.

                            • [^] # Re: promouvoir Java plutot que C#

                              Posté par Lionel Draghi (site web personnel) le 12 mai 2003 à 00:14. Évalué à 2.

                              

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

                  • [^] # Re: promouvoir Java plutot que C#

                    Posté par Guillaume Laurent (site web personnel) le 10 mai 2003 à 13:35. Évalué à 1.

                    

                    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 ? :-)

                    • [^] # Re: promouvoir Java plutot que C#

                      Posté par Philip Marlowe le 11 mai 2003 à 21:27. Évalué à 2.

                      

                      Le premier lien cite des boîtes qui persistent dans l'utilisation du compilateur propriétaire EiffelStudio de Eiffel Software, qui n'est pas la seule possibilité pour programmer en Eiffel.
                      
                      Je n'écris pas du fond d'un hôpital psychiatrique, avec un entonnoir sur la tête : je sais qu'il existe moins d'applications écrites en Eiffel qu'en Java, C, C++, Ada, Perl, Python, PHP, Fortran, Cobol et Visual Basic, liste non limitative. Il semblerait que ce dernier langage soit le plus utilisé de par le monde. En est-il pour autant le meilleur des langages de programmation ?

                      • [^] # Re: promouvoir Java plutot que C#

                        Posté par Guillaume Laurent (site web personnel) le 12 mai 2003 à 01:42. Évalué à 1.

                        

                        En est-il pour autant le meilleur des langages de programmation ?
                        
                        Le meilleur dans l'absolu, non. Mais une option viable, oui. Le problème n'est pas seulement dans la qualité intrinsèque d'un langage (si tant est qu'un critère soit réellement mesurable, il y a une grande part de subjectif dans ce jugement). Pour reprendre une phrase que j'avais lu sur fr.comp.lang.c++ (justement dans un débat opposant C++ à Eiffel, si je me souviens bien): "il y a 2 types de langages, ceux que tout le monde trouve géniaux, bien designés, etc... et ceux qu'on utilise".
                        
                        J'ai une théorie analogue : les langages sont comme les maisons. Si luxueuse et bien pensé que soit l'architecture, il faut toujours des chiottes, sinon tu ne peux pas vivre dedans. Et si tu n'en as pas, tu ira faire ta merde dans le salon et ça sera encore pire.
                        
                        Autrement dit, les langages très propres comme Eiffel ou Ada ne se généraliseront jamais parce qu'ils ne collent pas au cas le plus courant du développement, et dans le cas le plus courant, on essaie de faire des trucs propres le plus souvent, mais de temps en temps on est obligé de faire de la merde, parce que c'est la vie.
                        
                        Ada, Eiffel, ça marche pour des programmes militaires ou financiers spécifiés de A à Z, mais pour des applis "normales" ou le client ne sait pas vraiment bien ce qu'il veut, où tu dois inter-opérer avec du code existant, où tu es pressé, où tu dois être sur de pouvoir facilement trouver des gens ayant les compétences pour maintenir le code, où tu veux des libs pour des fonctions complexes (genre formattage de graphes, optimisation, toolkit graphique complète, etc...), bref, faire des trucs crades, c'est une autre histoire.
                        
                        Donc je suis tout à fait d'accord que Lionel puisse faire son système de com tactiques en Ada. Si il devait faire un browser web ou un traitement de texte, il en chierait 10 fois plus qu'en C++/Qt, et 20 fois plus qu'en Java, parce qu'il lui manquerait 90% des briques nécéssaires, et le typage sophistiqué d'Ada ou la distribution transparente de l'appli ne lui seraient d'aucun secours. Parce que les demandes ne seraient pas "j'ai besoin d'un truc en temps réel", mais "je voudrais pouvoir changer la taille des fonts avec la molette de ma souris", ou "la progress-bar elle s'affiche pas bien", ou "finalement cette fenêtre là je la voudrais ici, et puis celle-ci là".
                        
                        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.
                        
                        Déjà qu'il n'y ait pas de toolkit graphique native en Ada ou Eiffel est le constant d'échec le plus définitif qui soit.

                        • [^] # Re: promouvoir Java plutot que C#

                          Posté par Philip Marlowe le 12 mai 2003 à 09:19. Évalué à 2.

                          

                          Déjà qu'il n'y ait pas de toolkit graphique native en Ada ou Eiffel est le constant d'échec le plus définitif qui soit.
                          
                          L'erreur est humaine. Essaie EiffelStudio 5.3.
                          
                          où tu dois inter-opérer avec du code existant
                          
                          Pour ça, il y a l'appel à des procédures externes quand il s'agit d'utiliser du code existant d'un autre langage depuis Eiffel. Dans l'autre sens, il y a la bibliothèque Cecil.
                          
                          Pour le reste je suis bien d'accord qu'il faut qu'il y ait des chiottes dans une maison. Si possible plusieurs.

                          • [^] # Re: promouvoir Java plutot que C#

                            Posté par Guillaume Laurent (site web personnel) le 12 mai 2003 à 12:55. Évalué à 1.

                            

                            EiffelStudio
                            
                            Ça n'est pas une toolkit native, c'est un IDE. Et d'après les requirements
                            
                            http://www.eiffel.com/products/studio52/sysreq.html(...)
                            
                            ils ont fait une abstraction au dessus de Windows et GTK+ (GTK+ 1.2 qui plus es, méchamment obsolète).
                            
                            Donc, non, ça le fait pas, c'est beaucoup trop limité. Dès que tu veux faire tes propres widgets qui ne soient pas des agrégats de widgets existants, tu es foutu.

                            • [^] # Re: promouvoir Java plutot que C#

                              Posté par Philip Marlowe le 12 mai 2003 à 21:41. Évalué à 1.

                              

                              Tu es très focalisé sur le toolkit graphique des EDI. Sans indiscrétions, dans quel domaine travailles-tu principalement ?
                              Pour ma part, je m'en sers pour commander des robots et des dispositifs automatisés, donc de l'informatique industrielle. L'aspect cosmétique compte, mais n'est pas primordial.

                              • [^] # Re: promouvoir Java plutot que C#

                                Posté par Guillaume Laurent (site web personnel) le 13 mai 2003 à 12:31. Évalué à 1.

                                

                                Sans indiscrétions, dans quel domaine travailles-tu principalement ?
                                
                                Au bureau : un IDE de business rules en Java.
                                A la maison : un séquenceur MIDI et éditeur de partitions en C++/Qt/KDE (Rosegarden, cf. ma homepage).
                                
                                Pour ma part, je m'en sers pour commander des robots et des dispositifs automatisés, donc de l'informatique industrielle.
                                
                                Effectivement, on a pas les mêmes besoins :-).

                        • [^] # Re: promouvoir Java plutot que C#

                          Posté par Lionel Draghi (site web personnel) le 12 mai 2003 à 10:22. Évalué à 1.

                          

                          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é!

                          • [^] # Re: promouvoir Java plutot que C#

                            Posté par Guillaume Laurent (site web personnel) le 12 mai 2003 à 12:47. Évalué à 1.

                            

                            Je ne te dirai pas ca, car la beauté de l'IDE, je m'en...
                            
                            Moi aussi, j'utilisais (x)emacs depuis plus de 10 ans avant de passer à Idea. Et pourtant j'apprécie d'avoir un truc bien foutu devant les yeux. Mine de rien, ça compte. Pour un utilisateur lambda, c'est carrément essentiel.
                            
                            Plus sérieusement, il y a de très belle applis full Gtk, alors ca ne me parait pas un problème.
                            
                            Je ne dis pas que ce soit impossible, je te dis juste que le temps pour y arriver est souvent presque aussi long que celui du dev initial, et requiert souvent de descendre assez bas dans la toolkit. Le genre de truc qu'un binding permet difficilement. C'est typiquement le "devil is in the details", tu te dis que ça va être vite fait, et ça te prend des mois.
                            
                            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.
                            
                            Elles sont un peu moins moches (en standard) sous Windows que sous Linux (et plus rapides aussi), mais je suis d'accord. IntelliJ a fait un boulot monstreux pour rendre leur IDE joli à regarder. Et c'est bel et bien un argument contre Java, parce que ton temps de dev va en souffrir si tu veux un truc ayant de la gueule.

                • [^] # Re: promouvoir Java plutot que C#

                  Posté par DiZ le 10 mai 2003 à 16:23. Évalué à 1.

                  

                  >En général c'est Lisp, Ada, Eiffel, ou Objective C (les grands oubliés de l'industrie en gros)
                  
                  euh ObjC est utilisé pour faire un desktop et il y a de TRES nombreuses applications
                  utilisé par BEAUCOUP de monde ( et pas que pour faire des sites Oueb ),
                  PS : rien que couplé le mot application et Web me font doucement rire :)
                  
                  
                  Au hasard :
                  un desktop Java/C# plus utilisé que MacOSX ?
                  un Mailer Java/C# plus utilisé que Mail.app ?
                  un logiciel de présentation Java/C# plus utilisé que KeyNote ?
                  un browser Java/C# plus utilisé que Safari ou meme Chimera ?
                  un Organizer Java/C# plus utilisé que iCal ?
                  
                  Allez http://versiontracker.com/macosx/index.shtml(...)
                  
                  Désolé mais Java est inexistant pour le grand publique ( et pour l'instant C# aussi )
                  Pour avoir fait de Java(2) pendant un petit peu de temps je peux dire que oui c un joli langage mais que c'est loin d'être très pragmatique :
                  c'est *TRES* lourd
                  c'est plein de bloat
                  1 JVM par application sur le desktop (Java2) c'est un peu a mourir de rire.
                  
                  Au passage Sun c'est principalement inspiré de OpenSTEP pour faire Java....et même
                  pour faire du Oueb ...(et oui WebObject)
                  Ils ont raté leur truc .....
                  
                  Je suis curieux de voir comment IBM va récupéré Java quand Sun va crevé

                  • [^] # Re: promouvoir Java plutot que C#

                    Posté par boubou (site web personnel) le 10 mai 2003 à 16:43. Évalué à 3.

                    

                    c'est *TRES* lourd
                    c'est plein de bloat
                    
                    "Des arguments, des exemples !" demande la foule en délire.
                    
                    1 JVM par application sur le desktop (Java2) c'est un peu a mourir de rire.
                    
                    C'est surtout complètement con, vue qu'on peut très bien avoir plusieurs applications sur une même JVM, c'est même fait pour ça.
                    
                    Je suis curieux de voir comment IBM va récupéré Java quand Sun va crevé
                    
                    Moi aussi, vu que les JVM IBM torchent grave.

                    • [^] # Re: promouvoir Java plutot que C#

                      Posté par Fabimaru (site web personnel) le 10 mai 2003 à 21:40. Évalué à 1.

                      

                      > c'est *TRES* lourd
                      > c'est plein de bloat
                      "Des arguments, des exemples !" demande la foule en délire.
                      Il m'a suffit de lancer Jext pour me rendre que c'est lourd :-(

                  • [^] # Re: promouvoir Java plutot que C#

                    Posté par Guillaume Laurent (site web personnel) le 10 mai 2003 à 16:59. Évalué à 2.

                    

                    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.

                • [^] # Re: promouvoir Java plutot que C#

                  Posté par Lionel Draghi (site web personnel) le 11 mai 2003 à 20:36. Évalué à 1.

                  

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

                  • [^] # Re: promouvoir Java plutot que C#

                    Posté par Guillaume Laurent (site web personnel) le 12 mai 2003 à 02:10. Évalué à 1.

                    

                    pour SQL,cherche GNADE
                    
                    Oui, je l'avais trouvé. GPL. J'utilise ça comment dans une appli commerciale ? L'interface à Oracle est dans un package séparé, ça implique quoi du point de vue de la facilité de mise en oeuvre ? Il n'y a pas de support pour SQL Server ou DBase. Pas de doc en vue non plus.
                    
                    pour HTTP/HTTPS/SOAP/etc/etc, cherche AWS
                    
                    Ah, exact. Rien à dire, ça à l'air assez complet et documenté.
                    
                    GtkAda, c'est un très bon binding portable.
                    
                    C'est un binding. Je pense pouvoir dire que je connais assez bien le problème (jette un oeil à ma page). J'avais même discuté avec son mainteneur à une Linux Expo il y a plusieurs années, du temps où j'étais encore du coté Gnome. Bref, en gros : ça marche bien tant que tu restes dans la limite des widgets disponibles et que tu ne fait rien de trop exotique. Sinon, c'est très vite la merde.
                    
                    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.
                    
                    Dis ça à un utilisateur lambda, tu vas apprécier la réponse.
                    
                    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.
                    
                    Tant mieux pour toi, mais ça n'est pas le cas pour beaucoup d'autres.
                    
                    Secondo, il y a 50 langages qui offrent tous tes buzz words en bibliothèque.
                    
                    A part Java et C# ? Trouve m'en seulement un autre. Dont les libs sont documentées, à jour, et distribuées en standard. Il n'y en a pas, parce que pour sortir un truc pareil maintenant il faut s'appeler IBM, Sun ou Microsoft.
                    
                    Et dans pas mal de cas, les libs, on s'en fout même carrément.
                    
                    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. Tu dis que tous les buzzwords dont je parles sont dispo en Ada. Je t'assure que si tu avais effectivement à les utiliser, tu te rendrais très vite compte qu'entre une recherche sur google qui te sort un pointeur vers une lib et un produit fini et utilisable, il y a un gouffre. Dire "c'est bon, c'est dispo, y a une lib", ça veut le plus souvent dire que 99% du boulot reste à faire.
                    
                    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.
                    
                    Il leur aurait surement fallu 10 fois moins de temps pour le faire en Ruby/Qt. Et alors ? Si tu penses qu'un projet d'étudiant sur un truc aussi trivial est représentatif d'un cas réel, là encore on ne vit pas dans le même monde.

                    • [^] # Re: promouvoir Java plutot que C#

                      Posté par Lionel Draghi (site web personnel) le 12 mai 2003 à 10:32. Évalué à 1.

                      

                      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?

                      • [^] # Re: promouvoir Java plutot que C#

                        Posté par Guillaume Laurent (site web personnel) le 12 mai 2003 à 12:34. Évalué à 1.

                        

                        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.
                        
                        C'est vrai, quoique idéalement une solution encore meilleure est une bonne suite de tests de régréssions :-). Mais c'est très dur à faire, et encore pire quand il s'agit d'une GUI (y a des outils, mais assez lourds en général).
                        
                        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.
                        
                        Oui, mais dans ce cas tu peux presque dire que ton langage est UML, qui compile vers Ada/Eiffel/C++.
                        
                        [OT] : je vais aller voir ton proj libre, je suis curieux. Comment s'appelle-t-il? C'est du QT?
                        
                        http://www.all-day-breakfast.com/rosegarden/(...)
                        
                        C'est du Qt/KDE.

                        • [^] # Re: promouvoir Java plutot que C# tiens, il serait peut-etre temps de changer le titre!

                          Posté par Lionel Draghi (site web personnel) le 13 mai 2003 à 01:06. Évalué à 1.

                          

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

                          • [^] # Re: promouvoir Java plutot que C# tiens, il serait peut-etre temps de changer le titre!

                            Posté par Guillaume Laurent (site web personnel) le 13 mai 2003 à 12:27. Évalué à 1.

                            

                            L'historique est passionnant. Vous avez à peut prêt tout essayé sur ce projet, ou je me trompe? :-)
                            
                            Quasiment :-). Même Objective C, c'est tout dire. D'ailleurs on l'aurait probablement pris si il y avait eu une toolkit graphique :-).
                            
                            Je vois que tu a trempé dans GTK--. Je comprends pourquoi ta conversation avec un des auteurs de GtkAda a du être interressante.
                            
                            A l'époque, tous les auteurs de bindings GTK+ avaient plus ou moins les mêmes problèmes. Gnome était parti de l'idée qu'a partir du moment ou une lib est en C, y a pas de pbs pour faire un binding. De notre coté, on se coltinait des pbs à la con genre "ce char* est-il const ?", "ce membre est-il public ou privé ?", etc... et donc on a cherché à faire la synthèse de ces problèmes pour les faire remonter au mainteneur de GTK+ et des libs Gnome. C'est pour ça que depuis je pense qu'il est plus facile de faire des bindings d'une lib C++ que d'une lib C, parce que l'interface est décrite de manière beaucoup plus complète.
                            
                            C'est pas indiscret de te demandé pourquoi tu a abandonné GTK-- et Gnome?
                            
                            C'est pas indiscret, c'est même sur ma homepage : http://www.telegraph-road.org/writings/why.html(...)
                            
                            Autre question, as tu essayé Kdevellop?
                            
                            Oui, mais la version 2 n'était pas vraiment satisfaisante (disons pas assez de features interessantes pour me faire lacher XEmacs). Par contre, la v3 est beaucoup plus alléchante (avec une vrai analyse syntaxique du code, donc possibilité de complétion et browsing beaucoup plus étendues). Malheureusement elle est encore alpha. Si ils arrivent au bout, ça peut vraiment être interessant.

• [^] # Re: promouvoir Java plutot que C#

  Posté par Troy McClure (site web personnel) le 08 mai 2003 à 17:29. Évalué à 2.

  

  > il y a 8661 projects en Java sur Sourceforge (10812 en C et 10490 en C++ cf http://sourceforge.net/softwaremap/trove_list.p(...) )
  > Il y a deja pleins d'outils libres/proprios pour Java (Eclipse, Ant, Tomcat, Jakarta, JBoss, Xerces, gcj, JUnit, JBuilder, Together ect...)
  
  Et combien de ces projets ont une audience de plus de 2 utilisateurs ? J'ai downloadé un bon nombre de packages sur sourceforge, à 95% écrits en C, mais jamais aucun truc en java.
  
  Et pourquoi tous les outils "connus" (ça dépend par qui, moi j'aurais du mal a en citer plus de trois ou quatre) écrits en java sont aussi peu bandants ? (non non Eclipse, tomcat, et cie ne me mettent pas en émoi) ? (on peut remplacer "bandants" par "grand public")

  • [^] # Re: promouvoir Java plutot que C#

    Posté par Moby-Dik le 08 mai 2003 à 21:50. Évalué à 2.

    

    Et pourquoi tous les outils "connus" (ça dépend par qui, moi j'aurais du mal a en citer plus de trois ou quatre) écrits en java sont aussi peu bandants ? (non non Eclipse, tomcat, et cie ne me mettent pas en émoi) ? (on peut remplacer "bandants" par "grand public")
    
    Parce que, si tu as déjà utilisé un produit "grand public" Java, tu auras vite compris qu'il faudra encore quelques GHz de plus avant que ce genre de softs devienne agréable à utiliser, et relativement léger. Bref ta constatation est effectivement très pertinente : une grande partie des programmes Java existants sont des programmes destinés à l'utilisation de Java lui-même (outils, frameworks...).

• [^] # Re: promouvoir Java plutot que C#

  Posté par Ramón Perez (site web personnel) le 08 mai 2003 à 17:38. Évalué à 2.

  

  <i>> Il est communement admis que l'on programme 50% plus vite en Java qu'en C++ avec au final un code plus propre et moins de bugs d'ou un reel interet (ne parlons meme pas du C).
  
  Les gens sont vraiment cons alors, pourquoi ne codent-ils pas en Java ?
  Parce que c'est lent, incompatible d'une version à l'autre et d'une plateforme à l'autre (un comble pour un langage qui à la base se veut multi-plateformes !) ?
  Foutaise, tous les décideurs pressés le savent bien, 01 le répète d'ailleurs à longueur de journée, tout bon logiciel doit contenir au moins un des mots business, solution, java, workflow, e-blahblah...
  
  Pourquoi tous les gros projets sérieux (c'est à dire destinés à être utilisés et non à être vendus) sont en C ou C++ ? le kernel linux, open office, mozilla, wmcoincoin, xfree...

  • [^] # Re: promouvoir Java plutot que C#

    Posté par kadreg le 08 mai 2003 à 17:44. Évalué à 1.

    

    business, solution, java, workflow, e-blahblah...
    
    On m'appelle ?

    • [^] # Re: promouvoir Java plutot que C#

      Posté par Ramón Perez (site web personnel) le 08 mai 2003 à 17:47. Évalué à 1.

      

      Finis ton coincoin.NET toi !
      (Et passe le bonjour à Pierrot.)

      • [^] # Re: promouvoir Java plutot que C#

        Posté par kadreg le 08 mai 2003 à 20:01. Évalué à 3.

        

        Il est fini.
        
        Il est incapable de fonctionner plus de quelques minutes sans exploser, il est lent, bouffe toute la mémoire, manque de fonctionnalité utile et a des fonctionnalité qui ne servent à rien.
        
        Tout ce que l'on peut attendre d'un logiciel pas libre en fait

  • [^] # Re: promouvoir Java plutot que C#

    Posté par Fulgrim le 08 mai 2003 à 17:57. Évalué à 2.

    

    "Il est communement admis que l'on programme 50% plus vite en Java qu'en C++ avec au final un code plus propre et moins de bugs d'ou un reel interet (ne parlons meme pas du C). "
    
    Communément admis par qui ?

    • [^] # Re: promouvoir Java plutot que C#

      Posté par tanguy_k (site web personnel) le 08 mai 2003 à 18:21. Évalué à 1.

      

      > Communément admis par qui ?
      Par moi et beacoup de gens qui programment en Java
      Tu peux aussi le lire dans Thinking in Java (qui est une reference), disponible gratuite sur le site web de Bruce Eckel qui a fait parti du commite de standardisation du C++ (en gros un expert reconnue par tous pour ces competences).
      
      http://bruceeckel.com/(...)

      • [^] # Re: promouvoir Java plutot que C#

        Posté par Anonyme le 09 mai 2003 à 19:46. Évalué à 2.

        

        Les arguments d'autorité, c'est valable tant que tout le monde admet cette autorité.
        
        Là, il ne me semble pas que ce soit le cas. Venons-en a un exemple concrets : quelles applis java axées utilisation (par opposition à développement) sont populaires ?
        
        Toutes les applis java que j'ai testé dans ma vie ont toujours ramé, que ce soit du temps ou j'avais un P100, du temps ou j'utilisais principalement un PII qu'aujourd'hui ou j'utilise principalement un PIV. Je ne les ais certes pas tous testés - mais t'avoueras que ça fait bizarre. Et là on parle d'utilisation, ce qui en théorie est la finalité de la plupart des logiciels.
        
        Si Java est génial sur le papier mais qu'il n'a aucune réalisation concrête qui arrive au niveau des autres, Java n'est génial *que* sur le papier.

        • [^] # Re: promouvoir Java plutot que C#

          Posté par Guillaume Laurent (site web personnel) le 09 mai 2003 à 21:48. Évalué à 3.

          

          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.

          • [^] # Re: promouvoir Java plutot que C#

            Posté par Jerome Herman le 09 mai 2003 à 22:23. Évalué à 2.

            

            Tu as essayé sous Windows ? C'est triste à dire, mais Java y tourne beaucoup plus vite que sous Linux
            
            Tu as essaye sans graphiques ? non parceque entre le systeme de lock de la xlib et le systeme de lock de java pour la recollection des threads (merci Solaris) on en arrive facilement a avoir une JVM qui ne fait plus rien d'autre que d'attendre de part et d'autre que les interfaces acceptent fianlement de dialoguer.
            
            Par contre un programe java sans interface graphique (ou avec une interface swing) ca marche pas trop mal. Je n'ai pas fait de comparaison chronometree, mais a l'oeuil on est a peu pres dans les memes ordres de grandeurs.
            
            Kha

  • [^] # Re: promouvoir Java plutot que C#

    Posté par boubou (site web personnel) le 08 mai 2003 à 18:05. Évalué à 2.

    

    Les gens sont vraiment cons alors, pourquoi ne codent-ils pas en Java ?
    
    C'est ce qu'ils font. Sors la tête de ton trou, va faire un tour sur theserverside ou d'autres endroits sympa et tu verras que Java est un des langages les plus utilisés actuellement.
    
    Parce que c'est lent
    
    Affirmation grotesque. Sur certains benchs, Java est plus rapide que C++ ou que C.
    
    incompatible d'une version à l'autre
    
    Compatible ascendant, c'est normal, ça s'appelle les progres.
    
    d'une plateforme à l'autre
    
    N'importe quoi. Tout problème de compatibilité est un bug et franchement, il y a en pas plus que dans tout autre logiciel de la même taille.
    
    Pourquoi tous les gros projets sérieux (c'est à dire destinés à être utilisés et non à être vendus) sont en C ou C++ ? le kernel linux, open office, mozilla, wmcoincoin, xfree...
    
    Parce qu'ils sont vieux.

    • [^] # Re: promouvoir Java plutot que C#

      Posté par Ramón Perez (site web personnel) le 08 mai 2003 à 18:07. Évalué à 1.

      

      <i>> C'est ce qu'ils font. Sors la tête de ton trou, va faire un tour sur theserverside ou d'autres endroits sympa et tu verras que Java est un des langages les plus utilisés actuellement.
      
      Ok. Cite-moi donc des logiciels que tu utilises tous les jours et qui sont en Java ?

      • [^] # Commentaire supprimé

        Posté par Anonyme le 08 mai 2003 à 18:11. Évalué à 0.

        

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: promouvoir Java plutot que C#

        Posté par boubou (site web personnel) le 09 mai 2003 à 10:24. Évalué à 3.

        

        JBoss, Tomcat et tous les outils XML que j'utilise (en particulier le moteur xslt), ainsi que ant. Je remplace progressivement des outils très pénibles comme make par des outils beaucoup plus souples comme ant. Bien entendu, mon OS est écrit en C, comme mon navigateur et lecteur de mail. De plus, mon éditeur de texte (emacs) est écrit en C et lisp (horrible langage très lent, n'est-ce pas ?), alors que mon formatteur de document (TeX) est écrit en pascal (horrible, n'est-ce pas). Je connais de nombreuses personnes qui ont déjà remplacé emacs par jedit, et d'autres qui ne jurent que par eclipse. Pour l'instant, je me tate, mais c'est pour bientôt, je pense.

        • [^] # Commentaire supprimé

          Posté par Anonyme le 09 mai 2003 à 16:16. Évalué à 1.

          

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: promouvoir Java plutot que C#

            Posté par boubou (site web personnel) le 09 mai 2003 à 17:02. Évalué à 1.

            

            C'est du WEB, et WEB, c'est du pascal, cf http://www.tex.ac.uk/cgi-bin/texfaq2html?label=webpkgs(...)
            
            Et bien entendu, ça n'a jamais permis de prouver que TeX était sans bug, cf http://www.tug.org/whatis.html(...)

    • [^] # Re: promouvoir Java plutot que C#

      Posté par Gruik Man le 08 mai 2003 à 18:28. Évalué à 2.

      

      « Affirmation grotesque. Sur certains benchs, Java est plus rapide que C++ ou que C. »
      
      Heuuuu... Alors là oui mais c'est bien joli les benchmarks, mais quand ma machine avec 256k de RAM se met à ramer comme c'est pas permis parce que j'ai osé lancer Sun One Studio et ArgoUML simultanément, on n'arrivera pas à me faire croire que ma machine ne rame pas, quelles que soient les qualités ou défauts de Java par ailleurs.

      • [^] # Re: promouvoir Java plutot que C#

        Posté par tanguy_k (site web personnel) le 08 mai 2003 à 18:36. Évalué à 1.

        

        Quand les gens vont-ils comprendre qu'il y a une difference entre:
        - le langage
        - son implementation
        
        C'est pas parceque l'implementation d'un langage n'est pas rapide que le langage en lui meme est une merde qui sera toujours lent.
        
        Sun implemente Java en utilisant une JVM ce qui fait que ca rame (en contre parti ca apporte aussi plein d'avantages qu'un simple compilo n'a pas).
        Mais rien n'empeche d'implementer le langage Java de maniere classique (un compilo qui produit du code machine) sans passer par une JVM. Et oh miracle, ca existe et ca marche !

        • [^] # Re: promouvoir Java plutot que C#

          Posté par Larry Cow le 08 mai 2003 à 18:46. Évalué à 1.

          

          C'est pas pour ca que c'est rapide. Je me souviens d'un test de GCJ que j'avais fait, à base de HelloWorld tout bete. Alors, oui, ca ne présage pas franchement de la rapidité du langage. Par contre, ca met toujours un temps ridiculement elevé à se charger.

          • [^] # Re: promouvoir Java plutot que C#

            Posté par tanguy_k (site web personnel) le 08 mai 2003 à 18:56. Évalué à 1.

            

            Java ne pourra jamais etre aussi rapide que C++, il y a plein d'elements dans Java qui font que ca sera logiquement plus lent (classe Object, tout en virtual, garbage collector...)
            Mais tous ces elements apportent un developpement beaucoup plus rapide et confortable, ca s'appelle l'evolution et c'est necessaire: sinon on utiliserait encore de l'ASM pour programmer tous les jours.
            
            GCJ est encore en developpement, toute l'API Java n'est pas encore supportee et c'est encore moins optimise. En gros c'est au stade alpha et donc se baser la dessus pour comparer la vitesse de Java alors que les compilos C et C++ ca fait 20 ans que ca existe, ca le fait pas du tout du tout.

            • [^] # Re: promouvoir Java plutot que C#

              Posté par gabuzo le 09 mai 2003 à 00:53. Évalué à 3.

              

              <blockquote>Java ne pourra jamais etre aussi rapide que C++, il y a plein d'elements dans Java qui font que ca sera logiquement plus lent (classe Object, tout en virtual, garbage collector...)</blockquote> En fait ce n'est pas si vrai que ça. Java peut être plus rapide que C++ et inversement. Le tout dépendant d'une part de la situation et du programmeur. Effectivment Java déclare par défaut les méthodes en virtual mais rien n'interdit de déclarer une méthode final et la JVM pourra alors faire un branchement direct à l'adresse de la méthode plutôt que de passer par une table d'indirection (c'est finalement assez proche des const en C++ qui sont très importants pour permettre au compilo de prendre les meilleurs décision d'optimisation). Le garbage collector est probablement plus lent qu'un système de déallocation explicite comme en C++. Cependant il faut savoir que le GC peut se déclencher lorsque le programme n'a rien à faire alors qu'un delete en C++ consomme de la CPU immédiatement. On peut bien sûr imaginer en C++ un système qui permettrait de faire des delete différés. Ceci-dit le temps CPU utilisé par le GC est fonction du nombre d'objet en mémoire. Un programmeur expérimenté essayera de minimiser le nombre de création d'objets. Sinon le gros avantage de Java sur C++ en terme de perfs est la possibilité pour la JVM d'optimiser le code à l'exécution donc dans un contexte beaucoup plus complet que lors de la compilation. Dans le cas des méthodes et des attributs en final, la JVM pourra décider de les inliner en fonction de leur usage réel et non de supposition à la compilation.

              • [^] # Re: promouvoir Java plutot que C#

                Posté par boubou (site web personnel) le 09 mai 2003 à 10:29. Évalué à 2.

                

                Sur les méthodes virtuelles, une grosse bouse du C++, ça fait des années qu'on sait que la meilleure méthode, c'est de les virer à la compilation, par une analyse globale du code (cf Sather et Eiffel). Je soupçonne la machine virtuelle d'IBM de faire ça en just in time. Le vrai problème d'ailleurs ne vient pas du passage par un pointeur qui ne coûte pas grande chose, mais plutôt de ne pas pouvoir inliner la méthode et donc d'être obliger de faire un appel. D'ailleurs tu parles de ça dans la suite de ton post ! Le garbage collector est probablement plus lent qu'un système de déallocation explicite comme en C++ Faux. De nombreuses études démontrent le contraire, en particulier grâce au désallocation par bloc impossibles à faire en C++.

                • [^] # Re: promouvoir Java plutot que C#

                  Posté par Guillaume Laurent (site web personnel) le 09 mai 2003 à 11:57. Évalué à 2.

                  

                  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.

                  • [^] # Re: promouvoir Java plutot que C#

                    Posté par boubou (site web personnel) le 09 mai 2003 à 12:06. Évalué à 1.

                    

                    C'était nécéssaire pour garder la compatibilité avec C.
                    
                    Vrai et faux. Il aurait fallu faire exactement le contraire, à savoir par défaut virtuelle, et optionnellement non virtuelle, comme en Java (et en Sather, mais avec un mécanisme plus complexe). Le problème est que C++ est encombré par des "optimisations" stupides qui sont effectivement intéressantes pour certains cas particuliers marginaux (le fait de pouvoir transformer un objet en struct pour pouvoir le passer à du C) mais qui pourissent le cas général. Cette idée du virtuel est vraiment la plus stupide de C++, alors que la volonté d'être compatible avec le C pouvait se résoudre dans l'autre sens. Quelle misère... Mais nous avons déjà eu cette discussion il y a quelques années, mon cher Guillaume.
                    
                    Et si les premiers compilos C++ avaient du implémenter une analyse globale du code pour optimiser ça, on s'en serait jamais sorti.
                    
                    Ca je veux bien le croire. Mais bon, les templates sont tellement délirants en C++ qu'il a fallut des années pour découvrir ce qu'on pouvait faire avec (les expressions templates, par exemple) et aussi des années pour les implémenter correctement (est-ce le cas d'ailleurs).
                    
                    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.
                    
                    Une sacrée connerie du C#, si tu veux mon avis.

                    • [^] # Re: promouvoir Java plutot que C#

                      Posté par Guillaume Laurent (site web personnel) le 09 mai 2003 à 16:09. Évalué à 1.

                      

                      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.

                      • [^] # Re: promouvoir Java plutot que C#

                        Posté par boubou (site web personnel) le 09 mai 2003 à 17:07. Évalué à 1.

                        

                        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 bien simplement quand tu déclares un objet qui doit être compatible C, tu le déclares final ou un mot clé avoisinant. C'est franchement pas compliqué et ça éviter d'avoir à penser au virtuel quand on fait de la vraie programmation objet.
                        
                        Il n'y a aucun rapport ici avec l'analyse du code. L'intérêt de l'analyse statique, c'est de pouvoir faire de l'inlining de méthodes, même quand elles sont virtuelles. Encore une fois, le mécanisme du C++ aurait pu permettre d'optimiser à la main (solution de merde mais effectivement presque indispensable à l'époque) tout en prenant le système inverse (par défaut non optimiser et donc virtuel, sur demande non virtuel).
                        
                        C'est toujours facile de dire "ça c'est une connerie" quand on arrive 15 ans après la bataille.
                        
                        J'aurais du mal à te démontrer la chose, mais en tout cas en 92 déjà, certains de mes amis spécialistes des langages de programmation (caml etc.) disais déjà que l'idée du virtuel était complètement débile et surtout construite à l'envers.
                        
                        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.
                        
                        Ca, c'est ce qui provoquera la mort de C++ dans les années à venir...

                        • [^] # Re: promouvoir Java plutot que C#

                          Posté par Guillaume Laurent (site web personnel) le 09 mai 2003 à 18:39. Évalué à 1.

                          

                          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.

                          • [^] # Re: promouvoir Java plutot que C#

                            Posté par boubou (site web personnel) le 09 mai 2003 à 19:16. Évalué à 1.

                            

                            Facile, la sémantique de base des structs est différente de celle des objets, c'est une sémantique dans laquelle les méthodes sont obligatoirements non virtual. C'est un truc très classique dans Sather et Eiffel par exemple. Par contre, pour avoir une sémantique objet propre (ce qui est le cas de tous les langages objets sauf C++) il faudrait interdire d'hériter depuis une struct.

        • [^] # Not Invented Here

          Posté par Moby-Dik le 08 mai 2003 à 21:57. Évalué à 1.

          

          Mais rien n'empeche d'implementer le langage Java de maniere classique (un compilo qui produit du code machine) sans passer par une JVM. Et oh miracle, ca existe et ca marche !
          
          Engloutir des siècles-hommes de développement, des millions de brouzoufs et des kyrielles de ressources marketing, pour finir avec un langage objet compilé en code natif non-portable alors que C++, Eiffel, Ada95 et autres existaient déjà. Ô miracle, ô désespoir...

      • [^] # Re: promouvoir Java plutot que C#

        Posté par boubou (site web personnel) le 09 mai 2003 à 10:25. Évalué à 1.

        

        Et si Sun One Studio n'était pas bien programmé ? Quel produit te propose les mêmes fonctionnalités, mais implémentées dans un autre langage ?

    • [^] # Re: promouvoir Java plutot que C#

      Posté par Bapt (site web personnel) le 09 mai 2003 à 17:22. Évalué à 1.

      

      Dans tous les cas, JAVA est peut etre rapide, mais pour cela il fo que la JVM soit lancée, et ca c lourd (le lancement tout au moins).
      Je sais on peut compilé natif (c d'ailleur pour ca que JAVA m'intéresse : j'aime bien la langage en lui meme) mais tu perds l'un des principe que java....
      donc SI java c plus lourd et sera toujours plus lourd que CPP car il faut un jvm!!!!! dire le contraire c se foutre de la gueule de gens, après une fois que la jvm est lancée, le java arrive a etre plus rapide sur certains type de calcul.
      
      Dans tous les cas, moi ca me pete les burnes de devoir installer java sur mes machines, ou tout autres JVM, car c pas intégré à mon OS, et c pas des script à la con dans mon path qui vont me faire un java -jar /mon/path/toto.jar qui l'intégrera mieux, voila c tout

      • [^] # Re: promouvoir Java plutot que C#

        Posté par Fabimaru (site web personnel) le 09 mai 2003 à 22:21. Évalué à 1.

        

        Ca ne serait pas possible de faire une jvm partagée pas plusieurs programmes (qui éviterait les static et autre singletons bien sur) ?

        • [^] # Re: promouvoir Java plutot que C#

          Posté par boubou (site web personnel) le 10 mai 2003 à 15:52. Évalué à 1.

          

          Si, bien sûr, c'est le but de l'architecture de sécurité de Java et c'est utilisé par les serveurs d'application type JBoss et compagnie.

          • [^] # Re: promouvoir Java plutot que C#

            Posté par Fabimaru (site web personnel) le 10 mai 2003 à 21:41. Évalué à 1.

            

            Je voulais dire pour l'utilisateur lambda, qui lance des inferfaces utilisateur.

        • [^] # Re: promouvoir Java plutot que C#

          Posté par allcolor (site web personnel) le 10 mai 2003 à 16:46. Évalué à 1.

          

          (qui éviterait les static et autre singletons bien sur)
          
          Pourquoi cela... une bonne hierachie de classloader --> cad un classloader par application (qui elle même pourrait en créer un) qui délégue vers le bas avant d'aller vers le haut de la hierachie des classloaders et tes classes static et des singletons seront parfaitement isolé entre les applis...
          
          C'est grâce à cela que l'on peut utiliser plusieurs versions incompatibles d'une même bibliothèque...

  • [^] # Re: promouvoir Java plutot que C#

    Posté par tanguy_k (site web personnel) le 08 mai 2003 à 18:17. Évalué à 3.

    

    > Les gens sont vraiment cons alors, pourquoi ne codent-ils pas en Java ?
    Oui il y beaucoup de gens qui programment en Java, je viens de t'en donner un exemple avec les statistiques SourceForge.
    
    > Parce que c'est lent, incompatible d'une version à l'autre et d'une plateforme à l'autre (un comble pour un langage qui à la base se veut multi-plateformes !) ?
    C'est vrai que C et C++ c'est multi-plateforme et parfaitement compatible d'une version a l'autre.
    Et si c'est lent c'est pas forcement uniquement de la faute du langage mais aussi de son implementation.
    Comme dit avec plein de bon sens un peu plus haut:
    "rien n'est 100% portable, même en java, il faut programmer "correctement" si on veut de la portabilité, et certaines choses posent toujours des prob"
    
    > Pourquoi tous les gros projets sérieux (c'est à dire destinés à être utilisés et non à être vendus) sont en C ou C++ ? le kernel linux, open office, mozilla, wmcoincoin, xfree...
    Si la majorite avait raison ca ferait longtemps que ca se serait.
    En dehors de la qualite intrinseque d'un langage il y a aussi l'historique du project, les competences des developpeurs dans un langage plutot qu'un autre, les outils disponibles ect...

    • [^] # Re: promouvoir Java plutot que C#

      Posté par Ramón Perez (site web personnel) le 08 mai 2003 à 18:21. Évalué à 3.

      

      <i>> Oui il y beaucoup de gens qui programment en Java, je viens de t'en donner un exemple avec les statistiques SourceForge.
      
      Ah. Il y a aussi beaucoup de gens qui codent en Javascript (1187 projets), ça doit être un super langage le Javascript.

  • [^] # Re: promouvoir Java plutot que C#

    Posté par Lionel Draghi (site web personnel) le 08 mai 2003 à 23:30. Évalué à 2.

    

    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!

    • [^] # Re: promouvoir Java plutot que C#

      Posté par Philip Marlowe le 09 mai 2003 à 22:10. Évalué à 1.

      

      Le logiciel embarqué des imprimantes HP est engendré à partir d'Eiffel. La gestion de la joint-venture entre la banque Lazard et le Crédit Agricole a été faite en Eiffel.
      
      Ceci dit, c'est vrai, à part un jeu qui m'est passé une fois sous les yeux, je ne connais pas de produit très connu, ou grand public, qui soit écrit en Eiffel, si j'excepte les compilateurs Eiffel eux-même. Le domaine d'application principal, c'est les gros projets à l'unité où les contraintes de fiabilité sont grandes et la rapidité de conception primordiale. Va faire un tour sur http://eiffel.com(...) il y a d'autres exemples.
      
      Par contre je ne connais pas (pas encore ?) de cas où Eiffel est venu concurrencer Ada sur son terrain : la programmation parallèle en temps réel. Il faut dire que les spécifications du parallélisme telles que les a conçues Bertrand Meyer n'ont encore été implémentées dans aucun compilateur, pas même celui de sa société. J'espère que ce sera le cas un jour, vu la grande élégance et la simplicité de sa solution. Le compilateur d'Eiffel Software (la boîte de Meyer) implémente la concurrence par le biais des threads, celui du projet GNU, SmartEiffel, ne l'implémente pas. Il y a d'autres compilateurs (Visual Eiffel, Tower Eiffel, Halstenbach, certains ont peut-être disparu), mais je ne les ai jamais pratiqués.
      
      En bref, les projets Eiffel "sérieux" et d'envergure, ça existe.

      • [^] # Re: promouvoir Java plutot que C#

        Posté par Lionel Draghi (site web personnel) le 10 mai 2003 à 01:08. Évalué à 1.

        

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

• [^] # Re: promouvoir Java plutot que C#

  Posté par G. R. (site web personnel) le 08 mai 2003 à 19:05. Évalué à 1.

  

  .NET, c'est un Framework (mieux pensé que celui de java), et un langage (plus agréable que java dans l'exercice), et une machine virtuelle (avec JIT).
  
  Le langage de la machine virtuelle est standardisé. C'est une bonne chose.
  
  Mais il y a aussi d'autres langages au dessus du Framework
  comme Python ou Cobol, ou C++, ou VB.
  
  Je ne suis pas un admirateur de Microsoft ou de .NET, mais globalement, à l'usage, c'est intéressant et bien fait.
  En tout cas bien plus que l'ensemble Java (langage + Framework + JVM)
  
  Alors, pourquoi laisser ça uniquement à la platerforme Windows ?
  Pourquoi se priver de récupérer ce que Microsoft a pu faire de bien ?

  • [^] # Re: promouvoir Java plutot que C#

    Posté par boubou (site web personnel) le 09 mai 2003 à 10:32. Évalué à 1.

    

    .NET, c'est un Framework (mieux pensé que celui de java)
    
    Affligeant. C'est quoi ton argument ? Parce que tu sais beaucoup de gens pensent exactement le contraire ?
    
    un langage (plus agréable que java dans l'exercice),
    
    C'est le même langage ! Les différences entre C# et Java sont plus que minimies, je dirais même pas 10%. Qualifier C# de plus agréable est grotesque.
    
    une machine virtuelle (avec JIT).
    
    Pourquoi, il n'y a pas de JIT dans les JVM Java ?
    
    Mais il y a aussi d'autres langages au dessus du Framework
    comme Python ou Cobol, ou C++, ou VB.
    
    Formidable. Il y a littéralement des centaines de langages qui tournent sur la JVM Java.

    • [^] # Re: promouvoir Java plutot que C#

      Posté par Guillaume Laurent (site web personnel) le 09 mai 2003 à 12:01. Évalué à 1.

      

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

      • [^] # Re: promouvoir Java plutot que C#

        Posté par boubou (site web personnel) le 09 mai 2003 à 12:24. Évalué à 1.

        

        Franchement, je ne pense pas. Certaines idées sont très bonnes, d'autres sont des reculs par rapport à Java (par exemple les méthodes virtuelles ou les sections unsafe (je ne me rappelle plus le nom exact)). Il existe effectivement certaines différences basiques qui simplifient la vie en C#, en particulier la gestion des énumérations (grosse lacune de Java) et l'autoboxing des types fondamentaux, deux éléments qui vont être ajoutés dans le jdk 1.5. Même chose pour le foreach. Le switch de C# est mieux foutu que celui de Java et risque de le rester, par contre le jdk 1.5 apportera les génériques, peut être plus vite qu'en C#.
        
        Ceci étant, comme je n'ai de C# qu'une connaissance académique, car je n'ai jamais rien développé avec, tu as peut être raison pour la mise en oeuvre réelle. Toutes mes excuses pour mettre un peu embalé. Il faut dire que ton .net mieux conçu que J2EE, là, j'ai plus de doute...

        • [^] # Re: promouvoir Java plutot que C#

          Posté par G. R. (site web personnel) le 09 mai 2003 à 20:08. Évalué à -1.

          

          C'est ce que je disais.
          Tu parles sans savoir.
          
          Avant de faire ce jugement, j'ai été confronté aux deux, dans la vie réelle, pas pour des projets d'étudiants.

          • [^] # Re: promouvoir Java plutot que C#

            Posté par boubou (site web personnel) le 10 mai 2003 à 16:37. Évalué à 1.

            

            Oui, oui, tu es un homme fort et surtout tu argumentes à fond. .NET c'est mieux. ça c'est de l'argument ultra puissant.

    • [^] # Re: promouvoir Java plutot que C#

      Posté par G. R. (site web personnel) le 09 mai 2003 à 20:07. Évalué à -1.

      

      > Affligeant. C'est quoi ton argument ?
      
      Mon aregument ?
      C'est l'utilisation quotidienne pour des travaux professionnels des deux.
      Que ça te plaise ou non.
      
      Pour le langage, c'est pareil. Et c'est une expérience que je partage avec de nombreuses personnes, qui ont réellement essayé (plus qu'un hello word) C#/.NET.
      Est-ce ton cas ?
      Vu tes propos j'en doute fort.

      • [^] # Re: promouvoir Java plutot que C#

        Posté par boubou (site web personnel) le 10 mai 2003 à 16:37. Évalué à 1.

        

        Mon aregument ?
        C'est l'utilisation quotidienne pour des travaux professionnels des deux.
        Que ça te plaise ou non.
        
        
        Bravo, ouverture d'esprit, argumentation logique, tout y est, c'est remarquable.

    • [^] # Re: promouvoir Java plutot que C#

      Posté par tene le 09 mai 2003 à 22:17. Évalué à 1.

      

      C'est le même langage ! Les différences entre C# et Java sont plus que minimies, je dirais même pas 10%. Qualifier C# de plus agréable est grotesque.
      
      Properties, delegates, surcharges des opérateurs et surtout attributes, tu es sur d'avoir fait du C#?... [note: j'oublie surement quelques détails, mais ce sont les principaux je pense...]
      
      Pourquoi, il n'y a pas de JIT dans les JVM Java ?
      
      Java a été conçu pour tourner avec ou sans JIT, .NET ne fonctionne qu'avec un JIT...
      
      Formidable. Il y a littéralement des centaines de langages qui tournent sur la JVM Java.
      
      Le bytecode java... s'appelle le bytecode java... ça te donne une idée? sérieusement, le bytecode java a été pensé pour java, pas pour permettre à plusieurs langage de l'utiliser... .NET n'a pas été conçu de la sorte, c'est même parfois légèrement pénalisant pour le C#.

      • [^] # Re: promouvoir Java plutot que C#

        Posté par Jerome Herman le 09 mai 2003 à 22:47. Évalué à -1.

        

        Le bytecode java... s'appelle le bytecode java... ça te donne une idée?
        
        Ourch, comme argument leger celui la il se pose en maitre. Sur la plateforme Java tout s'appelle java. C'est vrai qu'au niveau du choix des termes ca porte a confusion, mais les applets java s'apellent les applets java, les beans java s'apellent les java beans etc. Bien que le bytecode de java permettent d'acceder tres facilement a des meccanismes de classe, il possede aussi un certains nombre de fonctions sous exploitees par java qui prennent toute leur force quand on passe sous un autre language. L'assembleur java, par exemple, est un veritable regal avec ses 255 registres. Ceci etant il est vrai que la cible visee par java etait avant tout l'embarque, ce qui n'est pas le cas pour la plateforme C#, c'est clair que ca entrainne des differences majeures au niveau de la conception du code, mais si on considere les JVM seule je ne suis pas vraiment sur que l'on puisse en donner uen vainqueur aussi facilement. Apres tout regarde l'horeur technique qu'est la plateforme (reelle celle la) ix86. Ca n'a jammais empecher les programmes de tourner et d'etre performant, ni les langages de pulluler.
        
        kha

        • [^] # Re: promouvoir Java plutot que C#

          Posté par tene le 10 mai 2003 à 01:35. Évalué à 0.

          

          Ourch, comme argument leger celui la il se pose en maitre.
          
          Relis ma phrase.
          
          L'assembleur java, par exemple, est un veritable regal avec ses 255 registres.
          
          Et moi qui croyais que la JVM était basé (tout comme .NET) sur une pile... (http://www.javaworld.com/javaworld/jw-06-1996/jw-06-vm-p2.html(...) )
          
          je ne suis pas vraiment sur que l'on puisse en donner uen vainqueur aussi facilement.
          
          Un vainqueur? qui a parlé de vainqueur? nous n'avons même pas parler de besoin...

        • [^] # Re: promouvoir Java plutot que C#

          Posté par Sayena Yefka le 12 mai 2003 à 15:23. Évalué à 1.

          

          "Ceci etant il est vrai que la cible visee par java etait avant tout l'embarque, ce qui n'est pas le cas pour la plateforme C# "
          
          Hem !
          Et le Compact Framework .NET pour WindowsCE et Ozone c'est de la cacahuette ?

      • [^] # Re: promouvoir Java plutot que C#

        Posté par boubou (site web personnel) le 10 mai 2003 à 16:36. Évalué à 1.

        

        Comme tu es un grand garçon, tu peux aller lire http://www.25hoursaday.com/CsharpVsJava.html(...) et tu verras qu'il n'y a pas tant de différences que ça entre les deux langages. Certains points de cet article seront de plus rendu obsoletes par la version 1.5 de Java qui apporte de plus les génériques. Par exemple, la version 1.5 apportera les énumérés et le foreach. Ton exemple des délégates est amusant car les classes anonymes les remplacent avantageusement en proposant une solution beaucoup plus objet et beaucoup plus souple. Normalement, les meta données dévraient être ajoutées aussi dans la version 1.5, mais la situation n'est actuellement pas claire, même si en pratique XDoclet permet de résoudre la plupart des problèmes liés à l'absence de ces méta données (que tu appelles les attributes).
        
        Si tu veux faire vraiment une comparaison, il faut aussi parler de ce qui manque en C#, en particulier une vraie gestion saine de la mémoire, à cause du unsafe, l'absence de vrai chargement dynamique de classes, le système totalement débile du virtual, l'absence des checked exceptions, etc.
        
        Bref, les langages sont effectivement différents et quand la version 1.5 de Java sortira, il restera clairement à C# quelques avantages comme la surcharge d'opérateur, les properties et le passage de référence, mais au prix de la mémoire unsafe et du virtual.
        
        Java a été conçu pour tourner avec ou sans JIT, .NET ne fonctionne qu'avec un JIT...
        
        Et alors ? Le fait est que les JVM Java performantes ont un JIT, je ne vois pas l'intérêt de cet argument foireux.
        
        Le bytecode java... s'appelle le bytecode java... ça te donne une idée? sérieusement, le bytecode java a été pensé pour java, pas pour permettre à plusieurs langage de l'utiliser... .NET n'a pas été conçu de la sorte, c'est même parfois légèrement pénalisant pour le C#.
        
        Et alors ? Oui, le bytecode de .NET a un énorme avantage par rapport à celui de la JVM, il permet de le passage par référence. Donc les langages qui ont besoin de ça sont potentiellement pénalisé par la JVM. Mais la réalité, c'est que de très nombreux langages sont actuellement compilable pour la JVM, éventuellement avec des performances dégradées dans certains cas. D'autre part, si on veut parler de .NET lui même, effectivement, on peut programmer en .NET dans d'autres langages que le C#, mais on reste dans le monde .NET. Avec J2EE, on parle CORBA, RMI et web services, ce qui permet d'être interopérable avec d'autres plate-formes. Tant qu'à faire à comparer tout et n'importe quoi, autant y aller fort !

        • [^] # Re: promouvoir Java plutot que C#

          Posté par tene le 11 mai 2003 à 02:13. Évalué à 0.

          

          Et alors ? Le fait est que les JVM Java performantes ont un JIT, je ne vois pas l'intérêt de cet argument foireux.
          
          Simplement si tu sais que ton code est destiné à être optimisé par un JIT, selon la plate-forme, tu ne ponds pas la même chose... tu trouves cela si compliqué et foireux à comprendre? Tu vas par exemple t'arranger pour qu'il prenne moins de place, au prix d'une éventuelle lenteur (tu connais le trade off classique vitesse/taille dans les compilos C/C++, bah c'est le même genre...). L'optique n'est donc pas la même, par exemple java sera plus adapté si tu n'as pas le temps ou la mémoire pour compiler ton code...
          
          Je te rappelle que le point de départ est simplement de comprendre que .NET et java, c'est pas exactement la même chose... le fait que .NET soit déstiné à un JIT ne le rend pas absoluement meilleurs, personne n'a dit cela...
          
          D'autre part, si on veut parler de .NET lui même, effectivement, on peut programmer en .NET dans d'autres langages que le C#, mais on reste dans le monde .NET. Avec J2EE, on parle CORBA, RMI et web services, ce qui permet d'être interopérable avec d'autres plate-formes. Tant qu'à faire à comparer tout et n'importe quoi, autant y aller fort !
          
          Tout d'abord, dis moi ce que tu veux prouver... ensuite te rends tu compte que t'es en train de dire que java c'est mieux parce qu'il est interropérable, et qu'à ce niveau, grâce au support du natif (.NET ne tourne pas sur une machine virtuelle au sens strict) dans .NET il est largement devant java... (tu as non seulement COM/COM+ mais également et directement, l'appel de fonction externe, le fait que tu puisses créer des attributes personnalisé te permet même d'ajouter le support de virtuellement tout ce que tu veux? corba par exemple...).
          As-tu déjà jouer avec .NET ou alors le seul truc que tu connais est l'url que tu m'as donné (l'url foire, mais bon)? Tu as déjà regarder comment développer un webservice en C#? Pour ma part, j'ai programmé, et je programme encore en java (swing, corba, web application) et je suis en train de découvrir .NET (via le C# essentiellement, si tu veux voir à quoi ressemble mes test: www.myoe.org)... avant cela, je développais essentiellement en C++.
          
          Concernant les delegates: non le concept d'interface et de classe anonyme ne le remplace pas totalement, ou en tous cas pas directement, tu pourrais implémenter un équivalent en java (ça a peut être déjà été fait, perso, je me suis intéressé au implémentation C++), mais le fonctionnement de la sorte est avantageux... tu as joué avec swing? avec winforms? tu ne trouvais pas des avantages à l'approche de .NET?... Enfin si tu t'intéresses au C# (tu me parles bien du langage java), ce qui est surtout pratique, c'est le sucre syntaxique associé... (j'ai 10 boutons sur une fenêtre, faisant 10 actions différentes, ces actions doivent être également faisable depuis n'importe quel endroit de mon code, et même si l'IHM n'est pas visible... comment tu fais avec des interfaces, et comment tu fais avec des delegates... tu as une classe POPConnection allant chercher des mails sur un serveur, dans différents endroits de ton IHM tu veux afficher une info de progression, tu fais comment le tout en java, en C#, lequel est le plus direct?).
          
          Et enfin, ton argument c'est quoi? me dire que .NET/C# c'est la même chose que java, parce que dans l'avenir java va ajouter les choses que j'ai cité à son langage? tu te sens pas un peu ridicule? MultiDeskOS c'est mieux que Linux parce que dans l'avenir va y'avoir plein de truc dans MultiDeskOS... ;)

          • [^] # Re: promouvoir Java plutot que C#

            Posté par tanguy_k (site web personnel) le 11 mai 2003 à 16:39. Évalué à 1.

            

            > Et enfin, ton argument c'est quoi? me dire que .NET/C# c'est la même chose que java, parce que dans l'avenir java va ajouter les choses que j'ai cité à son langage?
            > tu te sens pas un peu ridicule?
            > MultiDeskOS c'est mieux que Linux parce que dans l'avenir va y'avoir plein de truc dans MultiDeskOS... ;)
            
            Faut pas abuser non plus.
            
            http://java.sun.com/features/2003/05/bloch_qa.html(...)
            "The beta release of J2SE 1.5 is scheduled for late 2003"
            
            C'est pas parceque Java va integrer des notions (qui sont tous de meme pas super essentielles) 1 an apres C# que c'est la mort et que ca fait une grosse difference.
            C# et Java restent des langages tres proches dans l'ensemble et vont surement se rapprocher encore plus dans le futur.

• [^] # Re: promouvoir Java plutot que C#

  Posté par G. R. (site web personnel) le 08 mai 2003 à 19:10. Évalué à 2.

  

  Ah oui et puis,
  Il y en a marre de toute ces gueguerres
  C contre C++, C#/.NET contre Java, Python contre Perl, qt contre gtk...
  
  Quand on a un projet sérieux, on choisit la solution la plus adaptée.
  Mono sur Unix, libre, ça augmente ces possibilités.
  
  Pour certains projets, on préfèrera Java, pour d'autres Mono, pour d'autres Python/Zope etc.

• [^] # Re: promouvoir Java plutot que C#

  Posté par Moby-Dik le 08 mai 2003 à 21:45. Évalué à -1.

  

  Il est communement admis que l'on programme 50% plus vite en Java qu'en C++
  
  Ah ? Ca sort d'où ?
  
  On ne peut pas se permettre d'abandonner un langage pour un nouveau sous pretexte que celui est 5% mieux
  
  On peut sûrement utiliser autre chose que des pourcentages pour comparer des langages...
  
  le developpement de logiciel libre avancerait plus vite et probablement plus de personnes joindraient l'aventure.
  
  Il y a beaucoup de gens qui ne supportent pas Java.

  • [^] # Re: promouvoir Java plutot que C#

    Posté par Guillaume Laurent (site web personnel) le 09 mai 2003 à 01:19. Évalué à -1.

    

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

• [^] # Re: promouvoir Java plutot que C#

  Posté par tanguy_k (site web personnel) le 10 mai 2003 à 05:55. Évalué à 2.

  

  Ce que je voulais faire comprendre surtout par mon 1er post c'est que pour les logiciels libres cote desktop/appli graphique de tous les jours:
  - il faut un autre langage moderne en plus de C / C++ (dans le sens un binding pour KDE/GNOME bien supporte, bien fait et sans bug).
  - que ce langage ne doit pas etre juger uniquement que sur ces qualites techniques.
  
  Je trouve que Java est un bon candidat car (en autre)
  - il permettrait de "recuperer" un bon nombre de developpeurs, il est tres utilise et la plupart des gens aime programmer en Java
  - c'est probablement l'un des meilleurs langage pour ce type d'applications.
  
  Je suis pas sur que faire des bindings Eiffel/OCaml/Ruby... par exemple apportent beaucoup (c'est triste mais c'est comme ca).
  De meme, Visual Basic est pas mal utilise mais je suis pas sur non plus que ce soit un bon candidat.
  
  Il faut faire des compromis, il n'y aura jamais de solution parfaite.
  
  
  Pour C# j'ai lu quelques docs, mais je voudrais savoir dans la pratique si les "mieux" qu'apportent C# sont reellement interessants par rapport a Java dans des applications classiques desktop.
  En Java on developpe environ 50% plus vite qu'en C++ avec un code plus propre et un programme plus robuste, en C# on peut esperer quoi ? (je sais que c'est une question difficile de filling et que ca depend de plein de choses).
  D'apres ce que j'ai lu c'est certe mieux, mais la difference est pas enorme et ca se ressemble enormement.

# N'importequoi.net !

Posté par Hive Arc le 08 mai 2003 à 22:39. Évalué à 4.

C'est de la pure propagande pro MS ! Non, mono n'est pas l'implementation libre de MS.net, tout simplement car il n'existe pas de spec complete de MS.net !!!! Ce qui a été (habilement) standardisé à l'ECMA (et en cours à l'ISO) c'est une SOUS PARTIE seulement de l'ensemble. Tout ceci reste du pipotage, et le seul but avoué de l'ensemble est de conforter Windows comme plateforme de référence du poste de developpement et d'eloigner toute alternative. Non mono n'est pas une implementation de .net et non, mono n'est pas une alternative à d'autres solutions libres (PHP/JBoss ...) ! Si le FUD comercial de MS arrive meme ici ou va-t-on ? dotNet ne sera JAMAIS disponible sur une plateforme non krosoft, dixit balmer qui a été clair sur le sujet ! Quand au portage eventuel, c'est niet etant donné qu'il n'y a aucune ouverture du code envisagé ! Enfin, une réecriture avec compatibilité (telle qu'envisagée par mono) est illusoire, sans code de reference et sans spec détaillée de l'ensemble des élements ! Une seule question reste : Qui peut encore croire à de tels "pipotages.net" ?

• [^] # Re: N'importequoi.net !

  Posté par tene le 08 mai 2003 à 22:52. Évalué à 2.

  

  Quand au portage eventuel, c'est niet etant donné qu'il n'y a aucune ouverture du code envisagé ! http://msdn.microsoft.com/msdnmag/issues/02/07/SharedSourceCLI/default.aspx sans spec détaillée de l'ensemble des élements ! http://msdn.microsoft.com/library cherche, tu vas trouver...

• [^] # Re: N'importequoi.net !

  Posté par Jerome Herman le 08 mai 2003 à 23:11. Évalué à 3.

  

  Ce qui a été (habilement) standardisé à l'ECMA (et en cours à l'ISO) c'est une SOUS PARTIE seulement de l'ensemble. Tout a fait exact, mais cela suffit. Le probelem est de faire la difference entre trois choses distinctes et qui portent le meme nom : - la plateforme de developpement - les API de programation - la machine virtuelle .Net Si j'ai bien suivit les API sont brevetes, donc essayer de les copiers sans authorisation revient a laller faire un tour en prison. La plateforme de developpement c'est tout sauf grave, on s'en passe tres bien (perso mon outil de dev favori en ce moment c'est Jedit, mais Emacs et Vi font tres bien l'affaire a ce qu'on m'a dit). En ce qui concerne la machine virtuelle .Net la quasi totalite de celle-ci est normalise, et il est donc possible de faire une implementation parfaitement fonctionelle. On risque d'arriver a l'abberation suivante : les sources ne seront pas transposables d'un environement a l'autre, mais par contre les binaires le seront. Il faut bien se rendre compte que MS essaye a tout prix de s'imposer sur le marche serveur, son produit MS Serveur 2003 fait un peu office de va-tout a ce niveau. Je trouve au contraire que c'est un tres beau pied de nez que d'implementer les idees de MS sur toute une variete de plateforme. La pub MS en ce moment aux US explique de facon un peu allegorique qu'avec .Net on peut ecrire un ERP completement adapte aux besoins d'une grande entreprise en moins de deux mois (beaucoup rigole sur ce coup la). Et moi perso il n'y aurait rien qui me ferais plus rire qu'une boite qui develloperait des composants en MS.Net avant de les deployer en production sur une plateforme unix-like. Kha

  • [^] # Re: N'importequoi.net !

    Posté par Jak le 08 mai 2003 à 23:43. Évalué à 1.

    

    <i>> La pub MS en ce moment aux US explique de facon un peu allegorique qu'avec .Net on peut ecrire un ERP completement adapte aux besoins d'une grande entreprise en moins de deux mois C'est le principal argument commercial de Microsoft, et ce, depuis toujours : Windows (et tout ce qui va avec), est facile. Grâce à cette formidable stratégie de communication, on a aujourd'hui des gens qui prétendent s'y connaître en informatique et qui trouvent que c'est de la paranoïa de ne pas travailler sur le compte Administrateur/Root en permanence, entre autres ... Tiens, voilà pourquoi Windows est facile : http://pinsa.escomposlinux.org/sromero/linux/pringao/techslacky.html :)

# Re: Mono 0.24

Posté par enicolas le 09 mai 2003 à 11:07. Évalué à 3.

Ah, en voilà une discussion bien intéressante, car à mon avis elle
touche à des problèmes fondamentaux de l'informatique moderne et
du logiciel libre : quel language(s) ? quel api(s) ? portabilité ?

Tout d'abord, je pense que l'effort Mono est un cul de sac. J'ai lu
récemment une interview (sorry, impossible à retrouver...) ou quelqu'un
disait que la communauté du libre devrait moins passer de temps à
clôner et plus à inventer. Je suis 100% d'accord avec ça.

C'est vrai que parfois le "clônage" a du bon, surtout pour se mettre
à niveau et rendre le libre "intéressant". Par exemple Open Office
a en partie cloner Ms Office, mais maintenant chaque release de OO
apporte son lot de nouveautés innovantes (source SGBD partout, export
PDF...) et se démarque de plus en plus.

Et notez que les logiciels vraiments connus, impressionants du libre
sont des logiciels qui ne clônent pas, mais qui innovent. Mozzila
par exemple, avec le tab browsing, le filtrage bayesien de spam.

Alors quel est l'intérêt pour une communauté libre de clôner (ou
d'implémenter, appellez ça comme vous voulez) une plateforme Microsoft ?
Est-ce que l'effort ne serait pas mieux placé dans le développement
de logiciels libres innovants et utiles ?

Il a été dit que cela permettra d'effectuer des developpements
portables plus facilement. Il existe déjà pour celà de (très) nombreuses
solutions plus ou moins libre. Java bien sûr (je vais y revenir),
mais aussi QT (oui je sais sous Windows c'est payant... mais si vous
pouvez payer pour l'operating system et le compilateur, vous pouvez
surement payer pour l'API, non ?), GTK, wxWindows, et j'en passe.

De plus, il ne faut pas se leurer. Ca ne plaira pas à Microsoft de
voir des applications faites pour .Net marcher aussi bien sous GNU/Linux
que sous Windows. Et il fera son possible pour l'empêcher. Le dépôt
des brevets sur l'API est là pour ça. Il peut aussi changer les APIs
régulièrement de sortes que la communauté libre ne pourra pas suivre.

Il a été dit que ça ne se passera pas comme ça, car :
NET est un produit commercial, déjà en production sur certains sites, ms
n'a donc plus la possibilité de changer du tout au tout...
Et pourtant... IIS/ASP est un produit commercial, déjà en production sur
de très nombreux sites, et MS ne se gène pas pour le mettre à la poubelle
et annoncer à ses grands comptes officiellement que cette plateforme
est remplacée par la .Net chose et ne sera plus supportée dès 2005.

Mais revenons aux alternatives. Il a été dit beaucoup de choses sur
Java, notemment "Java est promu par Sun et j'ai 10x plus confiance en
Sun que Microsoft" ou "Java n'est pas propriétaire". Je ne suis pas
d'accord. Pour moi, Sun est le "Microsoft de l'Unix". C'est certes moins
visible car la position de monopole n'est pas là, mais le comportement
s'en rapproche.

Eh oui, il faut voir les choses en face, Java est propriétaire. Ok, la
spécification est publique, mais l'implémentation ne l'est pas du tout.
Alors peut être que de nombreux projets libres comblent le vide
(GNU classpath, jikes, GCJ, ...) mais c'est tout comme Mono vis à vis
de .Net, c'est de l'effort passé par la communauté libre pour implémenter
(clôner, quoi) une plateforme propriétaire.

Mais au final, qu'est que nous recherchons dans .Net, Java... c'est
une combinaison de plusieurs choses : Langage, API, Outils qui nous
permettent de développer des applications portables sur les trois
plateformes principales (GNU/Linux sur divers matériels, MacOSX et
MsWindows).

Et là je rejoins les défenseurs de Java. Le langage est relativement
propre (même s'il est très pauvre, malheureusement, mais ça s'améliore
avec le temps, cf l'ajout d'une forme peu développée de généricité dans
le 1.5), avec une des APIs les plus complètes à l'heure actuelle et
à la portabilité très raisonnable (à condition de ne pas faire n'importe
quoi).

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" !! Ok,
il y a beaucoup de projets Java sur SourceForge, mais il suffit de
regarder ce que sont ces projets
ça peut être
un peu lent parfois, c'est propriétaire. Alors que faire d'autre ?

Autres choix de langages. Il y a des "vrais" langages dans la nature,
je veux dire des langages qui ont été réfléchis, fait pour faire
du "gros" logiciel fiable. En comparaison (et ça a été dit), C, C++,
Java, C# et autres ne sont que des "jouets". Je veux bien sûr parler
de ADA95 et de EIFFEL (et peut être d'autres que je connais moins).
Et la supériorité de ces langages est réelle. Ce n'est pas du "sucre
syntaxique", mais bien une façon différente de penser l'informatique.

Malheureusement, ADA95 souffre du manque de librairies dans beaucoup
de domaines, quand à EIFFEL, sa communauté de développeurs tends vers
le zero absolu (signe des temps, le livre de référence "Eiffel, The
Language" est épuisé et introuvable, à part en occasion...).

Alors à mon avis, la communauté du libre aurait bien besoin de
se fédérer autour d'un environnement plustôt que de s'éparpiller sur
de multiples projets (Mono étant un de plus dans la longue liste,
et probablement le moins intéressant). Et même s'il y a les briques
de base pour cet environnement (encore faudrait-t-il "choisir" parmis
QT, GTK, wxWindows, GnuStep...), l'environnement complet n'est pas là
(par exemple, une application GNOME ne sera pas bien intégrée sous
Windows).

En fait, il y a problement une erreur dans la façon de perçevoir
le problème. On parle tous d'APIs et quelqu'un disait ici que porter
.Net sous GNU/Linux doit être aussi rigolo que de porter fork() sous
Windows. Mais ce que veut un développeur d'application ce n'est ni
"fork()" ni "WM_PAINT", il veut une API simple pour lancer un autre
process et une façon simple de peindre dans une fenêtre.

L'environnement idéal devrait être plus "haut niveau" et dans bien
des domaines QT et GTK sont bien placés de ce point de vue. Reste
que ces outils sont basés sur des langages pas très joli-joli.
Développer tout en C à notre époque équivaut quand même à faire table
rase de 20 ans (au moins) de progrès informatique. Et développer
en C++ impose un lot de contorsions, de problèmes de compilation,
de lenteur de compilation et de bugs obscurs.

Tout ça pour dire que les efforts passés dans Mono ou dotGNU seraient
mieux placés dans le développement d'une plateforme de développement
libre qui apporterait quelque chose d'équivalent à QT et GTK, portable
et basé sur un langage digne de ce nom (ne me demandez pas lequel,
je ne sais pas, mais en tout cas ce n'est ni Java ni C# ni C ni C++).
Ah oui, il faudrait que cette plateforme soit "native" (i.e. *pas*
basée sur une machine virtuelle) pour offrir les performances que
l'on attends des logiciels "qui marchent".

Un travail énorme, que personne n'a encore démarré, en partie à
cause de la dispersion dans tous ces projets inutiles.

Eric Nicolas
http://www.nosica.net/(...)

• [^] # Re: Mono 0.24

  Posté par Jak le 09 mai 2003 à 11:34. Évalué à 1.

  

  Et l'ObjectiveC de GNUstep ne te va pas ? Car au niveau intégration à un Unix, MacOS ou Windows, c'est pas mal du tout, GNUstep.

  • [^] # Re: Mono 0.24

    Posté par David Latapie le 11 décembre 2003 à 04:08. Évalué à 1.

    

    Je vois pas mal de référence à Objective-C dans ces posts. Pour moi qui ait un Mac mais ne programme pas, Objective-C, c'est le C de Apple, parce qu'il ne veulent jamais faire comme les autres et pensent que le solution « à eux » est meilleure que celle des autres.
    
    Apparemment, je me trompe (je vois « GNUStep », « Obj-C, c'est bien »…)
    
    Quelqu'un pourrait-il me dire ce que vaut Ojj-C par rapport heu, au reste ? CPeut-on imaginer que Cocoa sera multi-plateforme ?
    
    Et LA question : quelle est la durée de vie d'un thread sur DLFP ? Parce que s'il faut poster dans les 3 heures pour être certain que quelqu'un lira, autant que j'arrête les frais.

• [^] # Re: Mono 0.24

  Posté par boubou (site web personnel) le 09 mai 2003 à 11:41. Évalué à 3.

  

  Eh oui, il faut voir les choses en face, Java est propriétaire. Ok, la
  spécification est publique, mais l'implémentation ne l'est pas du tout.
  
  Putain, mais c'est incroyable de continuer à lire des conneries pareilles. Une grande partie de l'implémentation de Java est libre, point final. Par exemple, toute la partie XML du jdk 1.4 (versions se et ee) vient du projet apache. C'est très clairement indiqué dans la doc et la licence. Il s'agit de l'implémentation de référence, pas d'un clonage. De même, la meilleure implémentation des web services en Java (les api JAXRPC, entre autres) est clairement Axis qui est en avance sur Sun sur ce point. L'implémentation de référence des JSP et servlets est Tomcat, logiciel open source du groupe apache ! La spécification J2EE 1.4 est en cours d'implémentation par deux projets open source, JBoss et JOnAS qui implémentent déjà l'intégralité de J2EE 1.3, c'est-à-dire l'ensemble des api ajoutées à l'édition standard. La partie graphique spécifique au système du jdk 1.4 passe sous unix de motif à GTK dans l'implémentation de référence.
  
  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" !!
  
  Sort de ton trou ! Ce n'est pas un répétant une connerie qu'elle devient vraie. Le site web de la SNCF est en Java (EJB), celui de Chronopost aussi. Les exemples sont légions. Et je ne parle pas simplement de la partie présentation (JSP servlet), mais bien sûr de la partie métier et de l'interfaçage avec les gros systèmes qui tournent derrière. Sur le serveur, Java est utilisé massivement. Autre exemple, j'ai participé à un appel d'offre gagné par une entreprise pour refaire le système de billeterie de la fnac (fance billet et billetel), le plus gros système de ce genre en France, et devine quoi, on va le faire en JAVA !!!!
  
  
  Ah oui, il faudrait que cette plateforme soit "native" (i.e. *pas*
  basée sur une machine virtuelle) pour offrir les performances que
  l'on attends des logiciels "qui marchent".
  
  C'est marrant les gens qui se la petent avec Eiffel super bien conçu, etc. et qui ensuite font "table rase" des énormes progrès réalisés par les machines virtuelles. Les machines virtuelles avec leur JIT offrent des performances excellentes, souvent meilleures que le code compilé. Elles peuvent en effet réaliser des optimisations basées sur le profil d'utilisation d'une méthode, chose impossible à faire sans VM, comme par exemple un inlining de méthode quand le besoin s'en fait sentir. De plus, le byte code extrêmement contrôlé permet des optimisations et une adaptation au hardware. Il est remarquable de voir que pour du calcul matriciel par exemple, la JVM d'IBM est capable d'obtenir des performances environ 2 fois inférieures à celle de la bibliothèque MKL d'intel implémentée en assembleur et adaptée à l'architecture physique de chaque CPU (en particulier la taille du cache). Par rapport à une implémentation naïve de calcul matriciel (en C ou C++), une bibliothèque évoluée comme COLT peut être 300 fois plus rapide, grâce aux algorithmes utilisés, mais aussi grâce à l'excellence de la JVM d'IBM, qui est capable par exemple de supprimer au vol les tests de débordement d'un tableau quand le prouveur de byte-code intégré démontre que les tests sont inutiles.

  • [^] # Re: Mono 0.24

    Posté par TImaniac (site web personnel) le 09 mai 2003 à 12:31. Évalué à 1.

    

    Oué enfin voilà quoi : y'a encore des trucs propiétaires... le problème est toujours présent...
    et reste que le Java a des lacunes : impossible de gérer les pointeurs : "Sécurité" !! oui mais des fois c bien pratique : c bizzare, quand j'essai en C# (sous ms.NET) de manipuler les pixel d'une image avec les routines dispo, je vais environ 40 fois plus vite avec un accès direct par pointeur...

    • [^] # Re: Mono 0.24

      Posté par boubou (site web personnel) le 09 mai 2003 à 12:45. Évalué à 1.

      

      Oué enfin voilà quoi : y'a encore des trucs propiétaires... le problème est toujours présent...
      
      En effet, je ne dis pas le contraire. Mais lire que l'implémentation n'est pas du tout libre, c'est pénible parce que c'est faux.
      
      et reste que le Java a des lacunes : impossible de gérer les pointeurs : "Sécurité" !! oui mais des fois c bien pratique : c bizzare, quand j'essai en C# (sous ms.NET) de manipuler les pixel d'une image avec les routines dispo, je vais environ 40 fois plus vite avec un accès direct par pointeur...
      
      Je ne comprends rien à ton post. Tu parles de java ou de C# ? Si les routines de manipulation d'image en C# sont mauvaises, je ne vois le rapport 1) avec les pointeurs, 2) avec Java. En Java, la version 1.4 a apporté beaucoup de nouvelles choses pour la manipulation des images et tu peux bien sûr les manipuler pixels par pixels de façon très efficace, en accédant directement au raster.
      
      Le lien que tu fais entre pointeurs et efficacité me semble tout à fait hasardeux, soit dit en passant...

  • [^] # Re: Mono 0.24

    Posté par enicolas le 09 mai 2003 à 12:52. Évalué à 4.

    

    Euh, d'abord quel besoin d'être agressif et grossier ?
    
    Ensuite, la discussion (et LinuxFR) porte sur le logiciel libre. Et je persiste à dire que je ne connais pas d'application utile, libre et écrite en Java. Les seules choses libres en Java que je connaisse sont des outils... pour développer en Java !
    
    Alors ok, tu me parles de grands systèmes d'information et de site webs en Java, c'est très bien, mais ce n'est pas du logiciel libre tout d'abord, et ensuite c'est fait par et pour des sociétés qui peuvent se permettre de dépenser des millions (d'euros!) en matériel de pointe et en piles de serveurs dans des data centers pour compenser la différence de performances de Java.
    
    La pluspart des entreprises (et encore plus des particuliers) n'ont pas ces resources et veulent pouvoir exploiter le peu de puissance qu'ils ont (cpu & mémoire) au mieux.
    
    En bref, j'attends qu'on me montre une application utilisable par le grand public (genre Open Office, Mozilla, MPlayer...), qui soit du logiciel libre et qui soit en Java. Pour l'instant je n'en ai pas vu. D'où ma remarque.
    
    Enfin, je ne suis pas tout à fait d'accord avec tes remarques sur le calcul mathématique. En effet, certes les librairies les plus performances sont en assembleur, mais il existe également des librairies écrites dans des langages de haut niveau avec des techniques de programmation modernes qui battent souvent les codes écrits à la main. Exemple: Blitz en C++, à patir du template metaprogramming, va plus vite que le LAPAC qui a été codé à la main (et ici je parle bien de "plus vite" pas "2 fois moins vite" comme toi).
    
    Alors c'est effectivement vrai qu'une JVM peut optimiser au runtime de certaines façons qui sont impossible à voir pour un compilateur C ou C++, mais par contre je te fais remarquer que ces optimisations sont possible pour un compilateur Eiffel car il dispose de la possibilité d'effectuer l'analyse globale du code.
    
    Donc tant mieux si les machines virtuelles progressent, cela permet de diminuer l'écart de performances entre un code compilé et un code interprété, mais cet écart existe toujours et cela restera un fait.

    • [^] # Re: Mono 0.24

      Posté par boubou (site web personnel) le 09 mai 2003 à 13:32. Évalué à 2.

      

      Euh, d'abord quel besoin d'être agressif et grossier ?
      
      Ok, désolé. Cependant, ça devient insupportable de répondre toujours au même FUD. Donc toutes mes excuses pour l'aggressivité, pas pour le qualitificatif "conneries pareilles".
      
      mais ce n'est pas du logiciel libre tout d'abord
      
      C'est sûr que le site de la SNCF n'est pas libre, mais bon, on s'en fout un peu. Par contre, ce qui est plus remarquable, c'est que Chronopost utilise en partie JBoss.
      
      des sociétés qui peuvent se permettre de dépenser des millions (d'euros!) en matériel de pointe et en piles de serveurs dans des data centers pour compenser la différence de performances de Java.
      
      C'est de l'humour ? Le matériel de pointe en question, ce sont surtout les 4Go de mémoire par serveur, à part ça, je te fais remarquer que ce qui coûte cher, ce n'est pas le matériel, mais les programmeurs. Et vu l'efficacité pour le développement de framework comme .Net ou J2EE, la boite gagne. Quand nous avons remporté l'appel d'offre, tout était bien entendu pris en compte, les serveurs comme le coût de développement. Tient d'ailleurs, j'ai oublié de dire que notre solution est entrièrement basée sur de l'open source, excepté la JVM...
      
      Blitz en C++, à patir du template metaprogramming, va plus vite que le LAPAC qui a été codé à la main
      
      Sauf que c'est du pipot intégral. Je connais les benchs, ils sont réalisé contre l'implémentation basique toute pourrie de BLAS et LAPAC, pas contre une implémentation haut de gamme comme la MKL d'Intel ou Atlas (open source). Par contre, les benchs dont je te parlais sont deux de COLT contre MKL et Atlas... Alors oui, Blitz c'est sympa, mais c'est un gadget pour faire du calcul matriciel efficace, contrairement à COLT. Bien sûr, tu peux vraisemblablement utiliser Blitz au dessus d'une implémentation efficace de BLAS, mais c'est aussi possible en Java. L'intérêt de COLT, c'est que c'est 100% pur Java.
      
      je te fais remarquer que ces optimisations sont possible pour un compilateur Eiffel car il dispose de la possibilité d'effectuer l'analyse globale du code.
      
      En effet, comme en Sather, et dans une certaine mesure. Sauf qu'à ma connaissance, la décision d'inlining est prise en se basant sur des critères heuristiques de complexité de la méthode, alors qu'avec un JIT, tu peux faire des évaluations par chronométrage. De plus, dès que l'analyse globale laisse un doute (à cause de la covariance en Eiffel, par exemple), tu ne peux plus inliner. Avec un JIT, on peut imaginer maintenir deux codes, une version inlinée parce qu'en général on doit utiliser celle-ci et une version sans inline quand on détecte (par un simple test de plus) qu'en fait l'objet passé n'est pas du bon type.
      
      Donc tant mieux si les machines virtuelles progressent, cela permet de diminuer l'écart de performances entre un code compilé et un code interprété, mais cet écart existe toujours et cela restera un fait.
      
      Bien entendu, mais les machines virtuelles compilent le code au vol. Pour une application qui tourne longtemps, elles peuvent battre la compilation statique...

      • [^] # Re: Mono 0.24

        Posté par DiZ le 10 mai 2003 à 16:50. Évalué à 1.

        

        >C'est sûr que le site de la SNCF n'est pas libre, mais bon, on s'en fout un peu.
        
        Oui et puis le site de la SNCF tu m'excusera, ce n'est pas terrible terrible .....
        
        >Par contre, ce qui est plus remarquable, c'est que Chronopost utilise en partie JBoss.
        Avec une JVM libre ?

        • [^] # Re: Mono 0.24

          Posté par boubou (site web personnel) le 10 mai 2003 à 17:47. Évalué à 2.

          

          Oui et puis le site de la SNCF tu m'excusera, ce n'est pas terrible terrible ....
          
          C'est marrant, parce que personnellement, je suis d'accord, mais les enquêtes de satisfaction commandées par la SNCF semble prouver que le site est très apprécié des utilisateurs. Comme quoi...
          
          Avec une JVM libre ?
          
          Au dernières nouvelles (mailing list de classpath), ce n'est pas encore possible, il y a quelques problèmes liés au chargement dynamique des classes, qui est une des parties les plus subtiles de Java. De toute manière, aucune JVM libre n'est complètement compatible avec le jdk 1.2, donc...
          
          Comme je percois une pointe d'ironie dans ton post (!), j'en profite pour redire pour la centième fois que je trouve insupportable de lire que Java est propriétaire car c'est faux. Cependant, je ne dis pas que Java est libre car c'est tout aussi faux. Par contre, je pense que la plateforme est beaucoup plus libre que .NET car Mono semble beaucoup plus en retard sur le .NET de MS que l'ensemble des projets libres Java sur SUN (et s'en entrer dans les considérations liées aux brevets etc.).

        • [^] # Re: Mono 0.24

          Posté par Sayena Yefka le 12 mai 2003 à 15:41. Évalué à 1.

          

          le site de la SNCF a ete elu par je ne sais plus quel mag/e-zine meilleur site commercial de l'annee...
          
          Hem !
          c'est l'un des site "pro" les plus lents et les moins conviviaux qui trainent sur le net.

• [^] # Re: Mono 0.24

  Posté par Larry Cow le 09 mai 2003 à 11:42. Évalué à 0.

  

  Et notez que les logiciels vraiments connus, impressionants du libre
  sont des logiciels qui ne clônent pas, mais qui innovent. Mozzila
  par exemple, avec le tab browsing, le filtrage bayesien de spam.
  
  Euh, Mozilla c'était avant tout un fork de netscape. Alors coté clone, il se posait la. Et de même pour gimp, sylpheed et bien d'autres.
  
  Le truc c'est, un peu comme tu l'a dis, que les logiciels libres commencent par cloner, puis rajoutent leur propre sauce. Et c'est ce que fait Mono: il clone .NET, puis lui ajoute des choses nouvelles (les itérateurs, GTK#)

• [^] # Re: Mono 0.24

  Posté par Guillaume Laurent (site web personnel) le 09 mai 2003 à 12:05. Évalué à 0.

  

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

• [^] # Re: Mono 0.24

  Posté par tene le 09 mai 2003 à 16:55. Évalué à 1.

  

  Tu te rends comptes que t'es en train, entre autre divagation (mozilla n'est pas un clone, java n'est pas utilisé, tous les langages sont très mauvais, IIS/ASP n'existera bientôt plus, ...) de comparer .NET à QT/GTK?... compare à la limite winforms à Qt/GTK, pas à tous .NET...

• [^] # Re: Mono 0.24

  Posté par Philip Marlowe le 09 mai 2003 à 22:20. Évalué à 1.

  

  signe des temps, le livre de référence "Eiffel, The Language" est épuisé et introuvable, à part en occasion...
  
  Il ne risque pas d'être réédité en ce moment. L'éditeur attend la troisième version de l'ouvrage où, entre autres, est abordée l'introduction dans le langage de la notion d'agent. Notion déjà implémentée dans EiffelStudio et SmartEiffel.
  
  En principe, quand un livre est épuisé, c'est qu'il a du succès, non ?

  • [^] # Re: Mono 0.24

    Posté par Guillaume Laurent (site web personnel) le 10 mai 2003 à 08:55. Évalué à 1.

    

    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.

    • [^] # Re: Mono 0.24

      Posté par Philip Marlowe le 10 mai 2003 à 10:16. Évalué à 1.

      

      Je me demande si mon obstination à ne pas utiliser les smileys (et laisser chacun trouver si ce que je raconte est sérieux ou si c'est une blague), ne finira pas par me causer du tort...-:)))))))))))))))))))))) Bon, là c'est peut-être un peu trop...

      • [^] # Re: Mono 0.24

        Posté par Guillaume Laurent (site web personnel) le 10 mai 2003 à 11:27. Évalué à 1.

        

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

• [^] # Re: Mono 0.24

  Posté par Lionel Draghi (site web personnel) le 10 mai 2003 à 01:23. Évalué à 2.

  

  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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.