Mono 0.24

Posté par . Modéré par Nÿco.
Étiquettes :
0
8
mai
2003
Linux
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

  • # Re: Mono 0.24

    Posté par . Évalué à 8.

    Pour l'histoire des itérateurs, ca peut être une excellente nouvelle. Si Ximian commence à prendre de l'avance sur les futures versions de C#, il pourrait bien devenir une implémentation de référence...

    Comment ca, on n'a plus le droit de rever?
    • [^] # Re: Mono 0.24

      Posté par . Évalué à 9.

      D'où l'utilité de la part Microsoft d'avoir standardisé C#...
      • [^] # Re: Mono 0.24

        Posté par . Évalué à 5.

        pour combien de temps ??
        le probleme c'est qu'ils changent a chaque version parceque ca les emmerde que la concurence soit devenue compatible
        • [^] # Re: Mono 0.24

          Posté par . Évalué à 9.

          Sauf que C# est standardisé auprès de l'ECMA, de même que JavaScript et quelques autres. Et il semblerait que la CLI soit standardisée aussi. Donc, le seul truc qu'ils peuvent s'amuser à changer, c'est les APIs de .NET. Et ca, à part fatiguer les développeurs, ca risque pas de leur apporter grand chose.

          D'une certaine manière, c'est une tentative de MS de mettre en place un framework "vraiment" potable. Je doute que leur désir de pouvoir soit fort au point de leur faire saccager leur nouveau bébé.
          • [^] # Re: Mono 0.24

            Posté par . Évalué à 10.

            D'une certaine manière, c'est une tentative de MS de mettre en place un framework "vraiment" potable. Je doute que leur désir de pouvoir soit fort au point de leur faire saccager leur nouveau bébé.

            Euh, je te trouves un peu optimiste concernant la stratégie de microsoft.
            Une chose est sure, microsoft a toujours su prendre les bonnes décisions pour préserver sa position dans le domaine informatique. Celà fait longtemps que le marketing et le commercial passent avant le technique chez eux et c'est vital pour eux s'ils veulent conserver leur place. Une entreprise en position de monopole doit avant tout contrôler ses adversaires pour que les avancées du domaine dans lequel elle évolue soient de son fait ou disparaissent purement et simplement. Si tu fouilles le passé de microsoft, tu te rapelleras qu'ils empêchaient aux autres dos de faire tourner windowset ses applications, qu'ils ne documentaient pas la totalité de leur API pour conserver de l'avance sur les éditeurs travaillant sur leur plateforme, qu'ils ont racheté un nombre considérable de boites pour combler des vides dans des domaines où ils étaient largués (sybase et bien d'autres...),qu'ils ont récupéré du code provenant d'autres systèmes....la liste est encore longue mais nous avons tous les éléments qui nous permettent de savoir que microsoft fait tout ce qu'il faut pour conserver sa position.
            Penses-tu toujours qu'un ingénieur fou de chez microsoft à eu une vision et que ça a donné .net? Non, bien sûr. L'objectif qu'ils poursuivent depuis plus de 5 ans, c'est faire disparaître java! Ils ont essayé de se l'approprier à une époque mais Sun s'en était sorti (en allant devant un tribunal tout de même). Maintenant, ils tentent de le détroner en créant leur propre langage miraculeux. Ils ont débauché l'inventeur de c#, ont repris ce qui faisait la force de java et le ressortent avec leur propre discours.
            Ils veulent tout simplement récupérer les développeurs java et qui plus est, ceux qui développent sous une autre plateforme. Ils annoncent bien le multi-plateforme pourtant mais n'ont pas fait un trés grand effort dans ce sens. Ils doivent bien rigoler en regardant les mecs de mono galérer pour les rattraper. En plus, ils leur permettent d'affirmer qu'il s'agit vraiment de multi-plateforme puisqu'ils n'ont aucune crainte à avoir de cette version qui aura toujours un trés long train de retard.
            Ce que je trouve domage dans cette histoire, c'est qu'une partie de la communauté ne voit pas l'absurdité que celà représente d'implémenter une soit disant nouvelle technologie de microsoft alors qu'elle n'a même pas encore été adoptée par les développeurs. C'est aider microsoft et être stupide au point de ne pas penser que microsoft à tout prévu pour garder le contrôle sur sa technologie et surtout privilégier SA plateforme.
            • [^] # Re: Mono 0.24

              Posté par . Évalué à 0.

              Rien ne permet de dire que mono sera toujours intrinséquement en retard. Il ya quelque chose qui s'appelle l'existant, les API de .NET finiront bien par converger et se stabiliser un jour, MS n'est quand même pas fou pour les changer à tout bout de champ simplement pour qu'ils ne soient pas clonés.

              Il y avait parait-il une blague qui circulait à un certain moment chez MS : "pourquoi dieu a-il crée le monde en 6 jours, réponse : c'est parce qu'il n'avait pas d'existant"
              • [^] # Commentaire supprimé

                Posté par . Évalué à 7.

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

                • [^] # Commentaire supprimé

                  Posté par . Évalué à -3.

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

                  • [^] # Re: Mono 0.24

                    Posté par . Évalué à -1.

                    J'ai aussi été "moinssé" pour la même remarque :
                    http://linuxfr.org/comments/205985.html(...)

                    A croire que cela dérange quelque uns de signaler la chose.

                    Bienvenue dans le nouveau monde de la notation linuxfr :))
                    Bof rien à voir, surtout du fait des afficionnados de PgPg et autres tordus...

                    -200
                    • [^] # Commentaire supprimé

                      Posté par . Évalué à -1.

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

                      • [^] # Re: Mono 0.24

                        Posté par . Évalué à -1.

                        Ca vient de certaines personnes qui ne se rendent pas compte que le systéme de notation négatif est la pour faire disparaitre ce qui nuit au débat et non pour baisser les opinions différentes de la leur.
                        • [^] # Re: Mono 0.24

                          Posté par . Évalué à -1.

                          Une opinion sur un commentaire qui ne fait que signaler un fait ?
                          Je crois surtout que c'est parce qu'on a "osé" parler de ce fait dans donner le lien qui le prouve. Certains ont la flemme de chercher par eux même une news qui n'a que 3 mois et qui est classé 18 sur le moteur de recherche Linuxfr avec comme clé "Microsoft". Par contre avec "microsoft API" il ne trouve rien, pas bien au point ce moteur.
              • [^] # Re: Mono 0.24

                Posté par (site web personnel) . Évalué à 1.

                ils pourraient rendre les versions Windows de C# incompatibles avec les autres (comme le champ inutilise de kerberos si mes souvenirs sont bons)
                • [^] # Re: Mono 0.24

                  Posté par . Évalué à 6.

                  Le champs inutilise de Kerberos ca n'a pas ete fait pour "rendre incompatible".

                  Simplement Windows est un systeme qui utilise des ACL, et il faut bien pouvoir stocker les infos qqe part, ce "champs inutilise" est un champ "vendor specific", et les infos ont ete mises dedans, c'est fait pour ca, et d'ailleurs MS n'est pas le 1er vendeur a avoir fait cela.

                  Le bruit venait du fait que MS n'avait pas voulu publier sont format, mais techniquement parlant ce que MS a fait avec Kerberos est tout a fait normal, il n'y a pas d'autres moyen de le faire.
                  • [^] # Re: Mono 0.24

                    Posté par (site web personnel) . Évalué à 0.

                    oui est donc? c'est bien comme l'histoire des champ non utilisé de kerberos
                    specifiques et pas publiés
                    • [^] # Re: Mono 0.24

                      Posté par . Évalué à 2.

                      oui est donc? c'est bien comme l'histoire des champ non utilisé de kerberos
                      specifiques et pas publiés


                      Qu'est-ce que ça veut dire, en français ?
                    • [^] # Re: Mono 0.24

                      Posté par . Évalué à 1.

                      Donc ? Donc ils ne l'ont pas fait pour casser la compatibilite, ils l'ont fait car il n'y avait pas d'autre methode possible.
          • [^] # Re: Mono 0.24

            Posté par . Évalué à 6.

            Sauf que C# est standardisé auprès de l'ECMA, de même que JavaScript

            Sans vouloir être pessimiste, le JavaScript n'est pas vraiment un exemple ... Ecris un peu de code en JavaScript (en te suivant le standard), tiens il tourne sous IE4 mais pas sous IE5 ou 6. Par contre il tourne sous Mozilla mais pas sous Opera ... Bref, on ne sait jamais sur quels browsers il fonctionnera ni sur quelles versions de browsers ...

            Tu vois ou je veux en venir ?
            • [^] # Re: Mono 0.24

              Posté par . Évalué à -4.

              <i>> Tu vois ou je veux en venir ?

              C# (et le Javascript), c'est de la merde !

              J'ai bon ?
            • [^] # Re: Mono 0.24

              Posté par . Évalué à 3.

              Non on ne vois pas. ne pas confondre JavaScript, EcmaScript, et DOM.
              Les 2 premiers marcheront de la meme facon dans IE, Opera, Mozilla, etc.
              C'est l'implementation du deuxieme qui pose probleme (et encore, si tu suis le DOM,
              maintenant tu ne devrais avoir aucun probleme avec IE6, Mozilla1.x et Opera7)

              http://www.openweb.eu.org/dom/(...) (attention justement, les articles concernant javascript se retrouvent dans le dom, vu que dans les navigateurs, la seule implementation dom disponible concerne le javascript/ecmascript)
              • [^] # Re: Mono 0.24

                Posté par . Évalué à 5.

                Merci. Je parlais bien entendu de la version ECMA de JavaScript (aussi appellée EcmaScript). Les implémentations du passé n'étaient pas forcément des modèles d'interopérabilité, mais c'est désormais lettre morte.

                Et pour en revenir à .NET et à Mono, si une technologie libre permet de faire des applis aussi portables qu'en Java, mais avec des meilleures perfs et une meilleure intégration (et éventuellement en plus libre), j'achète. Qu'elle vienne de Microsoft ou non n'est pas un critère.
              • [^] # Re: Mono 0.24

                Posté par . Évalué à 1.

                ... C'est l'implementation du deuxieme ...
                Il fallait lire, du 3eme bien sur. (vu que microsoft poussait bcp jusqua present, moins maintenant, "son" DOM)

                PS: pourquoi des [-] alors que je tente d'expliquer un truc a quelqu'un dans l'erreur ?
            • [^] # Re: Mono 0.24

              Posté par (site web personnel) . Évalué à 0.

              A moins que ça n'ai changé entre temps, IE ne supporte pas officiellement JavaScript. quelques temps après le lancement de JavaScript par Netscape, MS a décidé de créer "son propre language", le JScript, qui utilise la même syntaxe que JavaScript, mais des api juste un peu différentes, et qui réponds aux mêmes balises < script type = "javascript">. D'ou les problèmes de compatibilité, mais le JavaScript proprement dit est assez bien défini.
          • [^] # Re: Mono 0.24

            Posté par . Évalué à 1.

            Donc, le seul truc qu'ils peuvent s'amuser à changer, c'est les APIs de .NET. Et ca, à part fatiguer les développeurs, ca risque pas de leur apporter grand chose.

            Sans trop faire chier les développeurs il suffit à Microsoft d'ajouter des API qui n'existent pas ailleurs ou de mettre dans les API des trucs très proches de Windows qui seront très difficiles à implementer sur d'autres plates-formes.

            Sans jouer sur les APIs il serait très facile à Microsoft de modifier l'implémentation de sa plate-forme .Net pour dégrader les performances lorsqu'elle dialogue avec un système non Microsoft (en utilisant un protocole de communication non-standard par exemple). Ainsi il serait très très facile à un commercial de démontrer la supériorité d'une solution tout Microsoft (vous voyez, il a suffit de remplacer votre serveur Linux par un NT2003 pour que les clients ne rament plus).

            D'une certaine manière, c'est une tentative de MS de mettre en place un framework "vraiment" potable. Je doute que leur désir de pouvoir soit fort au point de leur faire saccager leur nouveau bébé.

            Bien sûr l'un des but de .Net est de drainer des développeurs (compétents si possible) il ne faut donc pas en faire un poubelle mais l'un des autres but de Microsoft est de vendre les logiciels de la maison (Windows, Visual Studio, etc.). Connaissant le poids du marketting chez Microsoft il est évident que .Net servira de tremplin à la migration de clients de Unix vers Windows. À mon avis perso Mono et toutes les ouvertures de .Net n'ont été autorisées par le marketting que pour éviter de nouveaux procès pour abus de position dominante (c'est probablement la même chose avec media player 9).
            • [^] # Re: Mono 0.24

              Posté par . Évalué à 2.

              Sans jouer sur les APIs il serait très facile à Microsoft de modifier l'implémentation de sa plate-forme .Net pour dégrader les performances lorsqu'elle dialogue avec un système non Microsoft (en utilisant un protocole de communication non-standard par exemple). Ainsi il serait très très facile à un commercial de démontrer la supériorité d'une solution tout Microsoft (vous voyez, il a suffit de remplacer votre serveur Linux par un NT2003 pour que les clients ne rament plus).

              ??? t'es en train de nous expliquer que si ms (ou n'importe qui) fait un truc fermé sans spécification, ça communiquera pas facilement avec l'extérieur... tu le sais, je le sais, on le sait tous... mais euh... rapport?

              On parle d'implémentation une API (une API est par définition une interface), ce que ms peut faire c'est rajouter quelques classes et quelques méthodes qui vont bien dans son framework histoire de l'avantager par rapport au reste... (ce que Mono fait déjà, leur implémentation du framework contient certaines améliorations par rapport à celui de ms ... ainsi qu'une implémentation des itérateurs en avance sur le planning ms...).

              Personnellement je vois .NET comme une façon pour microsoft de nettoyer son bordel, de le rendre plus cohérent, effiace et facile d'emploi... le C# contient quelques concepts intéressant (delegates, attributes, foreach) bien que peu novateurs, .NET apporte certaines choses sympathique dans son framework et dans ses idées... Mono tente d'avoir tous cela en libre, que vouloir de plus? si c'est mauvais, on l'utilise pas, si c'est bon, ça fait un moyen de plus de développer...

              Concernant la portabilité, ms en parle très peu, et c'tait pas vraiment le concept de base de .NET... ils n'ont visiblement pas tout fait pour que ce ne soit pas portable, mais ils ne font pas grand chose pour... il y a bien rotor l'implémentation "shared source" du CLI, mais les parties réellement "intéressantes" n'y sont pas (winforms, ASP.NET, ADO.NET, ...).
              • [^] # Re: Mono 0.24

                Posté par . Évalué à 2.

                Si je te suis bien, le manque d'ouverture du code par MS indique qu'ils n'ont pas pensé leur truc en termes de portabilité. Si c'est le cas, je m'inscris en faux:

                Il y'a une différence entre faire un code portable et faire un code ouvert. Les deux concepts sont orthogonaux: tu peux tout à fait avoir un code ouvert et galèrissimal à porter (exemple: un truc plein d'assembleur, pas commenté et bordélique), comme un code fermé mais pensé de façon à être portable.

                Alors oui, dans le deuxième cas, seuls les (heureux?) possesseurs du code pouront facilement faire quelquechose, mais ca n'ôte rien à la portabilité intrinsèque du bazar.
                • [^] # Re: Mono 0.24

                  Posté par . Évalué à 3.

                  Si je te suis bien, le manque d'ouverture du code par MS indique qu'ils n'ont pas pensé leur truc en termes de portabilité.

                  Non je n'ai pas voulu faire un tel lien entre les deux (parce que source ne veut pas dire portable... spec non plus d'ailleurs, mais c'est souvent plus simple avec...).

                  Quand je parle de ne pas vouloir en faire un truc portable, je pars de mon expérience personnelle (je suis en train de tester C#/.NET sous windows): MSDN (la doc http://msdn.microsoft.com(...)) parle très peu de portabilité, rotor contient peu de code (ce qui empêche d'affirmer que .NET est portable, ça ne veut pas dire que c'est impossible!), mais surout, en regardant la série de classe de .NET. Un programmer Win32 s'y retrouve très vite parce qu'il y retrouve un gout de Win32, plus dans certaines parties que dans d'autre:
                  - les thread sont géré "à la windows", c'est d'ailleurs un gros problème que mono a rencontré, ce n'est pas apparent, mais ça a du être chaud! (ainsi que tous les objets systèmes).
                  - winforms est mappé sur Win32, boucle de message, owner draw, style, etc... on y retrouve tout, alors que X utilise un modèle relativement différent!
                  - tous le remoting est basé sur COM+.
                  - ...

                  Ca permet à .NET d'être plus "rapide" que java, ils ne sont pas parti des mêms bases et avec les mêms contraintes: ms a pris le plus petit dénominateur commun de ses propres OS (et encore en droppant Windows 95) par contre il a voulu conservé l'existant et supporté plusieurs langages, Sun a du jouer avec son OS ainsi que tous les autres mais a pu se concentrer sur un seul nouveau langage... je crois que .NET est bien pour un programmeur Win32 et que Java reste l'une des seules solutions pour faire un truc portable... si .NET existe sous linux, même sans être 100% portable (ceci dit, 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...) il peut amha offrir une nouvelle façon de programmer au développeur linux (certains aimeront, d'autre pas, ça donne plus de choix!).
                  • [^] # Re: Mono 0.24

                    Posté par . Évalué à 1.

                    Alors j'approuve complètement :)

                    En ce qui me concerne, Java commence sérieusement à me peser, il me tarde vraiment de voir arriver un langage de programmation multiplateformes, libre et riche en bibliothèques "standard". Il y'a bien Python (mon choix actuel), mais c'est pas la panacée non plus.

                    Je doute fort que Mono/.NET soit LA solution, mais ca peut être un pas dans la bonne direction, donc je garde un oeil dessus au cas où :)
                    • [^] # Re: Mono 0.24

                      Posté par . Évalué à 2.

                      >En ce qui me concerne, Java commence sérieusement à me peser, il me tarde vraiment>de voir arriver un langage de programmation multiplateformes, libre et riche en>bibliothèques "standard".


                      GNUstep / Cocoa ?
                      • [^] # Re: Mono 0.24

                        Posté par . Évalué à 1.

                        J'y avais pensé, mais d'une part j'ai vraiment pas accroché à l'Objective-C, et d'autre part ca me "limite" la portabilité à Unix et MacOSX. Et dans le cas d'un prof qui demande des binaires sous Windows, ca m'arrange grave de pouvoir générer directement le binaire windows depuis mon Linux (je suis passé par un mingw comme cross-compiler, mais c'est vraiment pas idéal).
                        • [^] # Re: Mono 0.24

                          Posté par . Évalué à 1.

                          GNUstep fonctionne sous Windows
                          Mais c'est sur que cross compiler n'est pas l'ideal .....
                        • [^] # Re: Mono 0.24

                          Posté par . Évalué à 2.

                          Pourtant ces systèmes ont tout ce qu'il faut, la portabilité (Windows, Unix, MacOS X), un standard (OpenStep), un excellent langage (Objective C), un système d'objets distribués (avec NSConnection).

                          Je déplore le fait que trop peu de développeurs utilisent GNUstep.
              • [^] # Re: Mono 0.24

                Posté par . Évalué à 2.

                ??? t'es en train de nous expliquer que si ms (ou n'importe qui) fait un truc fermé sans spécification, ça communiquera pas facilement avec l'extérieur... tu le sais, je le sais, on le sait tous... mais euh... rapport?

                Le rapport ? Si Mono veut être une implémentation libre de .Net, son interopérabilité avec l'implémentation de Microsoft en terme de performance et de compatibilité sera primordiale pour la crédibilité de Mono. Le fait que la spec de .Net appartienne entièrement à Microsoft est déjà un gros problème pour Mono car lorsque de nouvelles version sortiront, la plate-forme de Microsoft implémentera déjà la spec alors que Mono devra l'implémenter. C'est un premier problème. Ensuite comme je le disais dans mon message original si Mono devient un concurrent pour Microsoft (par exemple en permettant à des entreprises d'utiliser des applications .Net sans avoir à remplacer leurs Unix par du Windows) il serait extrêmement facile de désavantager l'implémentation libre par rapport à l'implémentation de Microsoft.

                J'ai donc du mal à imaginer que Mono puisse être réellement crédible lorsqu'il faudra une interopérabilité avec .Net.

                si c'est mauvais, on l'utilise pas, si c'est bon, ça fait un moyen de plus de développer...

                Je n'avais effectivement pas pensé à l'hypothèse dans laquelle Mono ne cherche pas à être nécessairement compatible avec .Net mais à fournir pour les plates-formes Linux/*BSD/Unix un nouveau framework de développement. C'est effectivement intéressant mais dans un article suivant tu précises que certains aspect de .Net sont complètement calqués sur Windows et pose des problèmes d'implémentation sous Linux (les threads par exemple). Lorsque je lis ça je me demande à quel point Mono sera efficace sous Linux et si l'on ne cherche pas la compatibilité avec .Net pourquoi ne pas sortir un framework inspiré de .Net mais qui ne reprenne pas ce qui est clairement trop lié à Windows.
                • [^] # Re: Mono 0.24

                  Posté par . Évalué à 3.

                  Le fait que la spec de .Net appartienne entièrement à Microsoft est déjà un gros problème pour Mono car lorsque de nouvelles version sortiront, la plate-forme de Microsoft implémentera déjà la spec alors que Mono devra l'implémenter.

                  Les spec .NET 1.1 sont là depuis un moment, .NET 1.1 est sorti y'a 2 quelques semaines...

                  L'amélioration des iterator est déjà présente dans Mono, microsoft compte ajouter cette fonctionnalité en 2004/2005...

                  J'ai l'impression que la réalité contredis tes craintes, que je trouve des craintes justifiées, mais d'un autre côté:
                  - tant que mono n'est pas équivalent (ou supérieur) à .NET, ms a plutôt intéret à ne rien empêcher: ce n'est pas un concurrent dangereux, mais ça fait parler de .NET.
                  - .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... regarde l'évolution de l'API Win32: des choses ont étés ajoutées, mais pratiquement, peu de développeurs les utilisent: faut que ça reste compatible avec tous les windows... à terme, y'aura je pense le même effet sur .NET...
                  - Même si ms modifie toutes les semaines ses classes, comme il doit aussi rester compatible avec l'existant, tu feras tourner une appli mono.NET sur ms.NET... faudra comme toujours (même en java), ne pas utiliser de fonctionnalité spécifique.

                  Lorsque je lis ça je me demande à quel point Mono sera efficace sous Linux et si l'on ne cherche pas la compatibilité avec .Net pourquoi ne pas sortir un framework inspiré de .Net mais qui ne reprenne pas ce qui est clairement trop lié à Windows.

                  En fait, je vois cela d'une façon un peu différente: il y'a portabilité et possibilité de portabilité... visiblement mono tente de calquer sur ms pour ce qui va bien, ce qui permet d'être portable, même leur but n'est pas d'exécuter des programmes ms.NET (ce n'est pas wine!). Ce qui je trouve est une attitude intelligente: on aura le même langage, les mêmes classes de bases, les mêmes réflexes, la possibilité de faire une application riche et portable si nécessaire (avec Gtk# par exemple), la facilité d'interraction avec des assembly non portable (ce que java ne propose pas vraiment, utiliser du natif n'est pas trivial), tous cela sans être contraint dans un moule type vm java.

                  Niveau perf, je n'en sais pas plus, je suis déjà en train de ramer pour évaluer les perfs de ms.NET, pour celle de mono, j'attendrai un peu ;-)
                  • [^] # Re: Mono 0.24

                    Posté par . Évalué à 1.

                    <i>> on aura le même langage, les mêmes classes de bases, les mêmes réflexes, la possibilité de faire une application riche et portable si nécessaire (avec Gtk# par exemple), Scuze, mais tu pourrais préciser ? J'avais cru comprendre qu'une fois compilée, une appli .NET aurait fonctionné indifféremment sur MS.NET ou Mono.NET (comme un truc en Java, donc). Là, tu donnes l'impression qu'il faut recompiler pour chaque plate-forme. Quelqu'un pourrait-il me donner une explication, j'ai dû tout comprendre de traviole.
                    • [^] # Re: Mono 0.24

                      Posté par . Évalué à 4.

                      Tu n'as pas compris de traviole, tu peux faire tourner du code .NET sans le recompiler sous ms.net ou mono.net... mais comme j'essaie de le dire, .NET permet d'utiliser facilement des composant "non managé", et ça c'est absolument pas portable... (un racourci à la hache: winforms est un wrapper pour le toolkit windows...) en bref, quand tu développeras, ce sera "un peu comme en C", tu peux faire du portable, mais faudra alors s'arranger pour n'utiliser que des composants portables... (ceci dit, le prob se pose même en java...). Donc dans le meilleurs des cas, on a .NET tous portable, ou on l'a pas, et alors, on se retrouve avec: "on aura le même langage, les mêmes classes de bases, les mêmes réflexes, la possibilité de faire une application riche et portable si nécessaire (avec Gtk# par exemple), ". Ceci dit, pour plus d'informations, je te conseille la poubelle microsoft (http://msdn.microsoft.com) ou le site de mono (http://go-mono.com).
              • [^] # Re: Mono 0.24

                Posté par . Évalué à 1.

                je vous rappelle que MS ne s'interesse pas tellement a la portabilite, mais a l'interoperabilite, qui elle est bien plus importante, et meme primordiale.
    • [^] # Re: Mono 0.24

      Posté par (site web personnel) . Évalué à 1.

      Euh, les itérateurs sont une des nouveautés prévu dans la prochaine implémentation du C# par Microsoft (tout comme la généricité etc.), suffit d'aller jeter un coup d'oeil sur gotdotnet pour voir un beau pps qui explique très bien les plans de Microsoft depuis un bout de temps...
      Donc non, Ximian ne prend pas le risque d'implémenter un nouveau standard, tout juste sort-il la gestion des itérateurs avant Microsoft... (sont pas fou non plus chez Ximian)
      • [^] # Re: Mono 0.24

        Posté par . Évalué à 2.

        J'ai pas dit le contraire: j'ai juste dit qu'ils prenaient de l'avance, pas des initiatives.
  • # Re: Mono 0.24

    Posté par . Évalué à 7.

    programmer en .net c'est encourager le monopole ms donc poubelle
    • [^] # Re: Mono 0.24

      Posté par . Évalué à 3.

      Je trouve que tu as tort.

      .net a été copie de JAVA -> ok MAIS Il inclut pas mal d avantage pour les programmeurs.. les objetds prédéfinis etc.. en font 1 outil pratique.. Malgré que c krosoft c'est plutot le concept que j trouve intéressant..
      • [^] # Re: Mono 0.24

        Posté par (site web personnel) . Évalué à 5.

        Je rentre moi aussi dans le troll Java vs C#. Alors on pourrait encore ameliorer C# et creer un troisieme langage ? Est-ce que les ameliorations presentes dans C# par rapport a valent le coup d'un nouveau langage ? J'ai des doutes.
        • [^] # Re: Mono 0.24

          Posté par . Évalué à 2.

          Alors on pourrait encore ameliorer C# et creer un troisieme langage ?

          C# n'est pas le langage le plus avancé pour programmer sous .NET. Il y a aussi Eiffel#, qui a des caractérisques avancées : héritage multiple, etc.

          Participer à .NET, ou mono, c'est collaborer avec l'ennemi. Ceci dit, si .NET tient ses promesses, ça va faire mal...
          • [^] # Re: Mono 0.24

            Posté par . Évalué à 2.

            Participer à .NET, ou mono, c'est collaborer avec l'ennemi.

            Si l'"ennemi" produit quelquechose de qualité, et que le libre peut le cloner avec succès, qu'elle est le problème? Avoir reconnu que MS a produit quelquechose de qualité?
            • [^] # Re: Mono 0.24

              Posté par . Évalué à 3.

              Cloner une chose verrouillée par des brevets est dangereuse. Le mieux serait peut-être de reprendre l'idée et de la porter sur un autre terrain, ce que semble vouloir faire dotGNU.
              Le travail à faire pour concevoir une plateforme comparable à .NET est énorme. Qu'il y ait deux projets libres concurrents qui veulent poursuivre ce but n'est pas une bonne chose.
              • [^] # Re: Mono 0.24

                Posté par . Évalué à 2.

                L'ennui, c'est que soit tu fait quelquechose de compatible, et si tu y'a arrives malgré les brevets tu auras un vrai public (les gens qui veulent faire tourner du .NET sous Linux, au moins). Mais tu a effectivement le danger des brevets.

                Soit tu fais quelquechose d'équivalent en fonctionnalité, mais suffisament éloigné pour ne pas être inquiété. La par contre, c'est un peu plus simple vis-à-vis du code (tu ne t'embarasses pas à essayer de maintenir une compatibilité), mais plus compliqué vis-à-vis de la conception (tu n'utilise pas un truc déjà tout pensé). Et accessoirement, tu es obligé d'aller gagner tes utilisateurs à la sueur du front (en les convainquant que ton truc est mieux que celui d'en face, et qu'il faut oublier celui d'en face pour venir chez toi).

                Je sais pas pourquoi, mais je vois plus d'avenir (malgré le danger des brevets) dans le premier cas.
                • [^] # Re: Mono 0.24

                  Posté par . Évalué à 3.

                  Je sais pas pourquoi, mais je vois plus d'avenir (malgré le danger des brevets) dans le premier cas. Oullala! Je sens que c'est pas gagné avec toi! C'est quoi ce raisonnement de commercial? Tu es en train de sous-entendre qu'on est obligé de copier .net pour survivre. Et accessoirement, tu es obligé d'aller gagner tes utilisateurs à la sueur du front Tu n'as pas tout compris à la philosophie du libre ou alors tu ne la partages pas. Personne ne cours aprés les utilisateurs à tout prix. Il s'agit de rendre disponible à tout un chacun le travail de ceux qui le veulent, librement. Concernant .net, la communauté n'était pas concernée. Il se trouve que MDI et sa bande d'investisseurs de Ximian ont décidé de devenir les leaders du .net sous linux avec pour but de vendre des outils de développement aux futurs développeurs .net sous linux. Au passage, le gros coup de pub que ça représente ne fait que les réjouir. Maintenant, comme bien souvent quand MDI annonce connaitre la vérité ultime, beaucoup de linuxiens sont convaincus que le futur passe par .net sous linux et rien d'autre... Moi, je te demande simplement de me donner un exemple concret d'une application rélle qui permettra d'utiliser linux exclusivement à la place de machines sous windows. Je note déjà que les machines linux pourront être totalement remplacée par des windows si l'interopérabilité est respectée mais que l'inverse peut trés facilement être rendu impossible tout simplement par l'usage de classes non encore implémentées dans mono.
                  • [^] # Re: Mono 0.24

                    Posté par . Évalué à 1.

                    C'est quoi ce raisonnement de commercial? Tu es en train de sous-entendre qu'on est obligé de copier .net pour survivre.

                    Non, juste qu'une alternative à .NET sera plus viable si elle est compatible .NET que si elle ne l'est pas. A sans cesse inventer des roues incompatibles entre elles, on risque pas d'avancer. Et après tout, quand MS introduit des incompatibilités avec des softs libres on braille (et moi le premier), mais il faudrait laisser le libre introduire des incompatibilités avec les autres?

                    Après, savoir si on a besoin d'une alternative à .NET ou pas, c'est un autre débat.

                    Moi, je te demande simplement de me donner un exemple concret d'une application rélle qui permettra d'utiliser linux exclusivement à la place de machines sous windows.

                    Je ne vois pas le rapport. Mono n'est pas fait pour être l'argument ultime en faveur de la migration intégrale. C'est un moyen de ne pas rester à la traine, et d'éviter que des gens ne repartent vers du propriétaire (ou hésitent à migrer) "parce que leur couteuse application codée sous .NET ne tourne pas sous Linux, et que la porter reviendrait trop cher".
                    • [^] # Re: Mono 0.24

                      Posté par . Évalué à 3.

                      Je ne vois pas le rapport. Mono n'est pas fait pour être l'argument ultime en faveur de la migration intégrale. C'est un moyen de ne pas rester à la traine, et d'éviter que des gens ne repartent vers du propriétaire (ou hésitent à migrer) "parce que leur couteuse application codée sous .NET ne tourne pas sous Linux, et que la porter reviendrait trop cher".

                      Il y aura forcément un travail de portage à effectuer. De plus, au vu des exemples peu concluants que propose mono et qui ne cassent vraiment pas la baraque, je ne vois pas comment l'existance de mono avec son retard éternel pourrait lutter contre l'implémentation de l'inventeur, développé sur la plateforme de l'inventeur et utilisant les optimisations non portables lièes à la plateforme de 'inventeur.
                      Non, vraiment, je ne pense pas que linux puisse lutter à armes égales avec windows sur le plan de l'interopérabilité concernant .net.
                      Si l'application est écrite dés le départ sous linux en utilisant mono, ca peut par contre devenir un point faible dans une architecture d'entreprise puisque le serveur linux pourra se faire remplacer sans souçis par une machine windows qui représente quand même le standard quand on parle de .net.
                      Voilà pourquoi vouloir imiter quelquechose que l'on ne maitrise pas du tout peut nous amener tout droit dans le mur. Il faut innover et proposer mieux. Jusqu'à présent, tu défends beaucoup mono mais tu ne m'as toujours pas donné un cas concret prouvant l'intérêt indéniable de mono...
              • [^] # Re: Mono 0.24

                Posté par . Évalué à 6.

                Je commençais à désespérer devant l'engouement sucité par .net et mono chez des "linuxiens".
                Je ne pense pas que linux manque de langages et d'aPI performants au point de devoir se jeter sur la dernière tentative de framework d'une boite ayant le monopole comme culture.
                On se retrouve encore comme des moutons à suivre le champion du propriétaire alors que les ressources gachèes à vouloir imiter permettrait d'améliorer l'existant bien au delà de ce que ne pourra jamais offrir .net.
                .net apporte si peux de choses réellement nouvelles et rien d'indispensable qu'on ne peut que reconnaitre la puissance de persuation du marketing microsoft.
                J'aimerai que ceux qui comptent utiliser .net me disent ce qu'ils comptent en faire pour m'aider à comprendre les avantages qui m'auraient échappé. Ce qui serait encore plus intéressant dans vos réponses, ça serait de faire un comparatif avec la mise en place de la même solution grâce à un environment uniquement linux.
                Merci pour vos réponses.
                • [^] # Re: Mono 0.24

                  Posté par . Évalué à 3.

                  Encore une fois, ca sent l'amalgame "libre/linux" à plein nez.

                  Quant à un framework type .NET, ca me servirait pour un paquet de chose. Produire des applications multiplateformes avec un minimum d'efforts, notamment.

                  Parce que, aussi malheureux que ca puisse paraître, il y'a encore des gens qui utilisent windows. Et que même si préfererais amplement qu'ils migrent tous vers autrechose, ca ne fait que déplacer le problème. A moins qu'on n'établisse une hégémonie linuxienne (ou unixienne) comparable à l'hégémonie windowsienne qu'on déplore tous, il y'aura toujours besoin de faire des choses portables.

                  Et que le jour où un prof (ou un patron ou un client) me demandera une appli .NET, je serais bien content de ne pas avoir à acheter un windows, à pourrir une partition pour l'installer, etc...

                  Maintenant tu peux peut-être te permettre de refuser un contrat sous prétexte qu'il te demande de faire du .NET, mais c'est loin d'être le cas de tout le monde.
                  • [^] # Re: Mono 0.24

                    Posté par . Évalué à 1.

                    Le problème est la capacité de verrouillage que détient Microsoft sur son propre produit. Dans un premier temps, ça a des chances d'être multi-plateformes, vu que c'est tout de même sa raison d'être. Si ça connaît le succès, les tentations de dérive genre J++ vont être grandes. Cela marchera partout, mais encore mieux sous MS-Windows. Puis, il va y avoir des plateformes où ça ne marchera plus très bien... Il est bien connu que Microsoft adore la diversité, sauf peut-être celle de sa concurrence.

                    D'un autre côté, si une alternative libre équivalente existe, Microsoft aura toujours la possibilité de saboter sa machine virtuelle sous Windows, de cent manières différentes. On a vu leur bonne volonté pour installer la VM Java sous XP.

                    Encore une fois, ca sent l'amalgame "libre/linux" à plein nez.

                    Beaucoup de monde utilise la plateforme GNU/Linux pour développer des logiciels libres... .NET n'est pas là pour faire des applications portables. D'autres langages existent déjà qui permettent ça. .NET est surtout un moyen de faire des applications distribuées et, dans un premier temps au moins, cela implique pour être crédible de pouvoir le faire dans un environnement hétérogène.
                    • [^] # Re: Mono 0.24

                      Posté par . Évalué à 1.

                      Si vraiment .NET montre trop de mauvaise volonté à rester compatible avec lui même, on pourra toujours se tourner exclusivement vers Mono. Après tout, lui est réellement multiplateformes.
                      • [^] # Re: Mono 0.24

                        Posté par . Évalué à 3.

                        Soit je me suis mal exprimé, soit tu as mal compris.

                        Microsoft produit le système d'exploitation et la plateforme .NET. Leur premier adversaire n'est pas Mono (à part pour vouloir produire un effet comique, je ne vois pas pourquoi quiconque affirmerait cela), mais Java. Si .NET venait à supplanter Java, les développeurs de Mono auraient sûrement du souci à se faire pour récupérer les spécifications des évolutions futures de MS-Windows. Ou alors j'ai l'esprit mal tourné.
                  • [^] # Re: Mono 0.24

                    Posté par . Évalué à 1.

                    Tiens, au sujet du portage, dans quelle mesure du code reposant sur .NET sera-t-il multiplateforme ?
                    Est-il prévu des VM pour Unix et MacOS ?
                    Un binaire développé pour windows .NET pourra-t-il être réellement utilisé sur Unix sans aucune adaptation de code (ce que permet de faire Java) ?
            • [^] # Re: Mono 0.24

              Posté par . Évalué à 1.

              "que le libre peut le cloner avec succès, qu'elle est le problème?"

              ça permet à certains CEO de sortir des phrases comme ça :

              "Innovation is not something that is easy to do in the kind of distributed environment that the open-source/Linux world works in. I would argue that our customers have seen a lot more innovation from us than they have seen from that community."

              (indice: il fut vendeur de lessive ^^ )
              • [^] # Re: Mono 0.24

                Posté par . Évalué à 0.

                C'est pas faux, mais c'est un tout autre problème. Dans ce cas là, Mono est loin d'être le premier sur lequel il faut taper, bien après GNU, KDE et d'autres encore...
          • [^] # Commentaire supprimé

            Posté par . Évalué à 2.

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

            • [^] # Re: Mono 0.24

              Posté par . Évalué à 3.

              De la biere et des filles pour tout le monde.
              • [^] # Re: Mono 0.24

                Posté par (site web personnel) . Évalué à 2.

                Il y a un probleme ce que tu dis: les filles n'auront pas "de la biere et des filles" car elles auront des mecs buvant de la biere.
            • [^] # Re: Mono 0.24

              Posté par . Évalué à 2.

              En gros, la même chose que JAVA, avec la possibilité de choisir le langage dans lequel tu programmes.
              Pour en savoir plus, expliqué plus clairement que je ne pourrais le faire : http://www.01net.com/article/154757.html(...) .
              • [^] # Re: Mono 0.24

                Posté par . Évalué à 1.

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

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

                Par contre, par rapport à Java, .NET offre de bien meilleures performances à l'exécution.
                • [^] # Re: Mono 0.24

                  Posté par . Évalué à 1.

                  En .NET tu développes en C#, rien d'autre.
                  Il me semble avoir vu que l'on adresse la même cible avec des langages différents. Que le langage soit plus ou moins adapté est un autre problème. Eiffel Software propose un produit spécifique, Eiffel ENViSioN! ( http://www.eiffel.com/products/envsn10(...) ), adapté à la plateforme. Si je devais avoir à programmer pour .NET, c'est le langage que je choisirais, vu que je le pratique. Il me resterait à apprendre les bibliothèques spécifiques.
                • [^] # Re: Mono 0.24

                  Posté par . Évalué à 3.

                  Pas vraiment. En .NET tu développes en C#, rien d'autre.
                  Non il existe le C#, le J# (marrant non ?) le VB.net et ainis de suite.
                  En fait vu que .net repose sur un systeme de pseudo machine virtuelle il est possible de programmer pour .net en assembleur et de la d'ecrire tous les languages de programation qui vous plaisent.
                  En theorie la meme chose est possible sur la JVM, mais bon l'assembleur jvm ca a beau etre un jouet extra (255 registres, la fete) on doit pas etre beaucoup a s'en servir.

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

                  Oui, non peut-etre. En fait java est une bouffeur de memoire de premiere. C# par contre lui se goinfre du CPU. A partir de la il n'est pas tres difficile de faire une beccane qui va sur-avantager l'un ou l'autre.
                  Pour des applis Java en production c'est vari qu'il faut souvent pousser jusqu'a 2Go de memoire pour etre bien, par contre si le JIT est active un processeur unique de 500 Mhz tient parfaitement la charge.
                  La seule plateforme .net que j'ai montee (pour test) a arrete de scaler en perf a 512Mo par contre avec un bipro 1Ghz (le top a l'epoque) j'avais encore le CPU a 100% frequement.

                  J'ai des potes qui font toujours du dev sur cette plateforme et apparament c'est toujours le cas (ie CPU limitant).

                  Kha
                  • [^] # Re: Mono 0.24

                    Posté par . Évalué à 2.

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

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

                      Posté par . Évalué à 1.

                      Que reproches-tu au managed C++?
                      • [^] # Re: Mono 0.24

                        Posté par . Évalué à 1.

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

                          Posté par . Évalué à 1.

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

                          Posté par . Évalué à 1.

                          plus complexe je dirais pas, différent oui, mais bon vouloir garder tous ses réflexes du C++ dans un environnement totalement différent, faut pas rêver...

                          Je croyais que tu avais des points particulier à reprocher au C++ managé, par rapport aux autres langages .NET...
                          • [^] # Re: Mono 0.24

                            Posté par . Évalué à 1.

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

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

                      Posté par . Évalué à 2.

                      Bon je vais etre de tres mauvaise fois la, mais le fait que J# et VB.net soit tres limites, pas simple du tout a utiliser, et tout juste bon a servir de glue pour passer sous la nouvelle API qui brille des applis qui fonctionnent de toute facon tres bien sans eux, ca les differencie en quoi des versions precedentes ? Non parceque VB6 (on va etre gentil et on va pas parler de J#) a part pour faire un GUI fonctionnel en 20 minutes pour une demo client j'ai pas encore bien compris a quoi ca servait. Deja que les bugs VisualC++ ont finis par miner ma patience, VB j'ai failli devenir fou une cinquantaine de fois sur le seul projet que j'ai accepte dessus. Kha
                      • [^] # Re: Mono 0.24

                        Posté par . Évalué à 3.

                        D'après certains experts, VB.Net est tellement différent de VB standard, qu'il serait plus productif de passer directement à C#, ce qui confirmerait les posts plus haut qui indiquaient que le vrai langage .Net, c'est C#
                • [^] # Re: Mono 0.24

                  Posté par . Évalué à 2.

                  Pas vraiment. En .NET tu développes en C#, rien d'autre.

                  ???

                  Tu as de base: J# (un simili java), C#, C++ et VB.NET il offre tous les mêmes possibilité, attention cependant le C++ n'est pas du C++ "pur", ils ont du ajouté quelques fonctionnalité, et modifier certains comportement du au Garbage Collector.

                  Tu as aussi d'autre langage Eiffel.NET par exemple, bientôt Delphi.NET... et même une tentative de python.NET...
              • [^] # Re: Mono 0.24

                Posté par . Évalué à 0.

                les projets informatiques dépassent très souvent les budgets, l'échancier, souvent pas assez testé, manque des fonctionnalités.... c'est déjà complexe de gérer un projets avec un langage, alors avec plusieurs...
          • [^] # Stop au pipo !

            Posté par . Évalué à 5.

            "Ceci dit, si .NET tient ses promesses, ça va faire mal... " Quelles promesses ? Faire le menage, la cuisine, raser gratis ou faire des logiciels en un click ? MS.net est un solution produit plus du tout une "plateforme" ! Ainsi le comparer à Java est ridicule, si on veut trouver un concurent à mettre en face dans le monde Java on peut voir IBM Websphere ou Sun One ! Mais MS.net comme plateforme à part entiere est relativement virtuel. Ceci est confirmer par l'arret de l'utilisation des suffixes ".net" dans tous les produits cuvées 2003 et les opérations comerciales (TV, radio, ...). MS c'est rendu compte que ce qui compté c'etat le produit et pas le "virtuel". Au lieu de réver au "golem.net", on ferait peut-etre mieux de booster le projet classpath pour offrir une implementation d'une VM opensource, seul piece non-opensource a lors actuelle pour offrir une veritable alternative modulaire, performante et perenne au rouleau compresseur alimenté par la pompe à fric MS ! Agissez sur maintenant sur : http://www.gnu.org/software/classpath/ http://www.gnu.org/software/classpathx/
      • [^] # Re: Mono 0.24

        Posté par . Évalué à 1.

        Mais pourquoi on n'implémente pas plutôt un compilateur C# sur la JVM (est-ce que ça existe ?) parce que bon c'est une machine virtuel turing complete... donc y a-priori pas de problème ? me trompè-je ?
        • [^] # Re: Mono 0.24

          Posté par . Évalué à 1.

          donc y a-priori pas de problème ? me trompè-je ? En theorie pas de probleme, on est d'accord, a priori un gros probleme : les signaux. Il faudra rajouter au dessus de la machine virtuelle Java une machine virtuelle .Net et donc tous les siganux devront etre converti de natif vers java puis de java vers .Net, avant de redescendre en utilisant les memes chemins. Bref un pur gaspillage de perf. De plus le point fort de .Net reste son compilateur JIT. Hors sur le .Net JVM il faudrait de facon evidente que le compilateur compile en java natif, apres cela le JIT de java aurait toute les peines du monde a recompiler. A moins de faire un compileur JIT qui optimise tres peu de .Net vers Java en comptant sur le compilateur JIT java pour s'en occuper. Bref c'est theoriquemnt interressant, ca peut reserver des surprises (cf emulation dynamo) mais ca peut surtout virer au gaspillage de ressources pur et simple. Kha
          • [^] # Re: Mono 0.24

            Posté par . Évalué à 3.

            au gaspillage de ressources pur et simple. Vraisemblablement. Cependant, la vrai différence entre les deus machines virtuelles, c'est essentiellement le passage par adresse possible pour les types fondamentaux dans celle de MS et pas dans la JVM. Il est donc probable que pour des langages qui utilisent cette fonctionnalité, la version MS soit plus rapide que la version JVM (ça a été démontré pour pascal, par exemple). Sinon, je ne comprends rien à ton passage sur le JIT. Les deux VM ont des JIT, celui de la JVM est très performant, donc je ne vois pas trop le problème.
            • [^] # Re: Mono 0.24

              Posté par . Évalué à 2.

              Moi non plus je ne comprends pas...
              l faudra rajouter au dessus de la machine virtuelle Java une machine virtuelle .Net

              Pourquoi cela... ma vision était plutôt de compiler directement le C# en bytecode JVM... qui lui sera compilé natif par le JIT de la JVM...

              Donc pourquoi devoir implémenter une machine virtuelle .Net au-dessus de la JVM, ça n'a pas de sens...
              • [^] # Re: Mono 0.24

                Posté par . Évalué à 2.

                Si on compile le C# au sens "classique" du terme, alors le programme ne devient plus executable que sur la JVM. Ce qu nuit un peut a son utilite. Je pensais que tu voulais avoir un systeme qui te permette de faire tourner une appli C# sur une JVM, d'ou mes remarques.

                Par contre faire un compilateur C# sur la JVM ca risque aussi d'etre assez complexe, compte tenu du fait que les api de programmations risquent d'etre tres differentes d'une plateforme a l'autre. Il faudra donc un compilateur compatible avec le code C# MS, un compilateur compatible avec le code C# mono etc.

                Personellement je trouve l'idee d'une compatibilite binaire beaucoup plus interressante dans ce cas particulier la.


                Kha
                • [^] # Re: Mono 0.24

                  Posté par . Évalué à 1.

                  alors le programme ne devient plus executable que sur la JVM. Ce qu nuit un peut a son utilite.

                  Je ne trouve pas... bon d'accord tu te retrouves avec le même problème que les langages "classiques", tu dois recompiler...

                  Mais en principe c'est faux... vu qu'il y a des JVM sur pratiquement toutes les plateformes...

                  De plus cela permettrait des portages facile d'appli .net vers une JVM... d'où une grande portabilité... contrairement à .net ou mono est la seule alternative...

                  En attendant une JVM (Java2) complétement libre... ce qui arrivera c'est sur... <=== mon rêve...
                  • [^] # Re: Mono 0.24

                    Posté par . Évalué à 2.

                    De plus cela permettrait des portages facile d'appli .net vers une JVM... d'où une grande portabilité... contrairement à .net ou mono est la seule alternative...

                    Ben justement pas du tout, le code n'est pas portable parceque les versions Mono et MS sont differentes au niveau des API. On pourrait envisager que le compilateur de la JVM utilse les API de Mono, mais pourquoi implementer un GTK#(par exemple) alors qu'un swing# est beaucoup plus facile, plus proche du systeme etc.

                    Ensuite si le programme est compile pur la JVM et non pour la VM .Net on a pas la portabilite binaire non plus.

                    C'est pour ca que j'ai du ma a voir l'interet du truc.

                    Kha

                    N.B pour une JVM completement libre ca se precise. la 1.0 est quasiment finie et la 1.1 bien entamee. Pur l'instant j'attend surtout de voir si java 1.5 (java3 ?) tiendra ses promesses. Si c'est le cas ce sera ca l'objectif a atteindre.
                    • [^] # Re: Mono 0.24

                      Posté par . Évalué à 1.

                      Ensuite si le programme est compile pur la JVM et non pour la VM .Net on a pas la portabilite binaire non plus.


                      Mais si, tu as la portabilité binaire sur une JVM... Et au dernière nouvelles, il y a plus de VM java que de VM .net....


                      allez -1 et je ===>[]
                    • [^] # Re: Mono 0.24

                      Posté par . Évalué à 2.

                      mais pourquoi implementer un GTK#(par exemple) alors qu'un swing# est beaucoup plus facile, plus proche du systeme etc.

                      Tu peux déjà programmer en GTK sous une JVM...

                      et aussi QT avec kde-bindings....
    • [^] # Re: Mono 0.24

      Posté par . Évalué à 1.

      Utiliser un compatible PC, c'est encourager le monopole ms.
      • [^] # Re: Mono 0.24

        Posté par . Évalué à 1.

        Parler de .. c'est encourager le monopole de ..

        (Merde, j'ai marché dedans)
  • # Re: Mono 0.24

    Posté par . Évalué à 7.

    Mono se destine à porter la plateforme, mais pour executer un programme il manquera toujours l'Api.

    L'Api de M$ ne poura pas être porter vers GNU/Linux. Légalement ca m'etonnerait qu'ils acceptent, techniquement certaines fonctions n'ont pas d'équivelant (Manipulation de droits sur les fichiers qui dépendent du type de partition, Manipulation de la base de registre, Fonctionnement graphique comme la systray, etc... ).

    Donc les programmes ne seront (à mon avis) jamais totalement portable, ou alors on retombe dans les joies du C et de la compilation conditionnel.

    Bref, tellement peu d'interret que je retourne faire du Java !
    • [^] # Commentaire supprimé

      Posté par . Évalué à -2.

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

    • [^] # Re: Mono 0.24

      Posté par . Évalué à 3.

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

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

      techniquement certaines fonctions n'ont pas d'équivelant

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

      Je crois que le principal obstacle est surtout que la lib standard .NET est énorme. Il faudrait une très grosse équipe à temps plein pour arriver à la refaire.
      • [^] # Re: Mono 0.24

        Posté par . Évalué à 5.

        <i>> Pourquoi pas ? Il n'est pas dans l'interêt de MS d'être les seuls fournisseurs de cette API.
        Ben, si, justement ... Ya qu'à voir comment fait Sun avec Java. C'est pas un modèle d'ouverture ...
        • [^] # Re: Mono 0.24

          Posté par . Évalué à 2.

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

        Posté par . Évalué à 2.

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

    • [^] # Re: Mono 0.24

      Posté par . Évalué à 4.

      « L'Api de M$ ne poura pas être porter vers GNU/Linux. »

      Et WINE, c'est quoi? Une sucette géante?

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

      Ils ont pas vraiment leur mot à dire

      « techniquement certaines fonctions n'ont pas d'équivelant »

      Ça ne veut pas dire qu'on ne peut pas trouver une solution pour coder un équivalent

      « Manipulation de droits sur les fichiers qui dépendent du type de partition »

      WINE le fait

      « Manipulation de la base de registre »

      WINE le fait

      « Fonctionnement graphique comme la systray »

      WINE le fait

      « etc.. »

      WINE le fait aussi

      « Bref, tellement peu d'interret que je retourne faire du Java ! »

      C'est vrai, le Java a tellement peur d'intérêt... : p
      • [^] # Re: Mono 0.24

        Posté par . Évalué à 1.

        Ils ont pas vraiment leur mot à dire

        L'api .NET est breveté.
        • [^] # Re: Mono 0.24

          Posté par . Évalué à 0.

          C'est-à-dire? [url]?

          Sur ce sujet, et ailleurs, j'ai vu pas mal de personnes répéter ça, sans précision, détail ou explication supplémentaire que de dire « l'API est brevetée ». Or j'arrive mal à comprendre comment, même dans le système tordu USien (enfin, on va pas trop taper sur les USiens, à l'OEB ils valent pas mieux), on peut breveter une interface... Que certains procédés techniques accessibles par cette interface soient brevetés, je comprends que ça soit possible. Mais l'API elle-même?

          Tant qu'on m'explique pas en détail ce qui est breveté et comment, moi j'y crois pas. na.
          • [^] # Re: Mono 0.24

            Posté par . Évalué à 1.

            C'est-à-dire? [url]?

            Dans le genre boulet t'es pas mal toi. Tu peux pas prendre tes petits doigts et chercher ? Ca a fait l'objet d'une news sur Linuxfr :

            http://linuxfr.org/2003/02/12/11331.html(...)

            Or j'arrive mal à comprendre comment, même dans le système tordu USien (enfin, on va pas trop taper sur les USiens, à l'OEB ils valent pas mieux), on peut breveter une interface...

            Non mais tu débarques ou quoi ? L'achat en 1 click a été breveté par amazon, le lien hypertext a été breveté (british telecom je crois), le xor est breveté ...
            alors une API ...
      • [^] # Re: Mono 0.24

        Posté par (site web personnel) . Évalué à 2.

        Obtenir des fonctionnalites specifiques a Windows sous Linux est aussi amusant que de faire un "fork()" sous Windows (comme le fait cygwin): l'imitation sera en dessous de l'original car pas prevu pour au depart.
        • [^] # Re: Mono 0.24

          Posté par . Évalué à 2.

          Sauf que .NET a quand même été pensé dans une optique multiplateformes, ils ne sont pas totalement fous non plus chez MS. Ne serait ce que pour ne pas être emmerdés le jour où le PC disparaitra, ou le jour où l'architecture de Windows sera totalement changée.

          Le seul point vraiment Windows-centrique dans l'affaire, c'est System.Windows, et en particulier SWF (System.Windows.Forms), et là Wine peut entrer en scène.

          C'est pour moi la principale faiblesse du .NET de MS: l'absence de GUI crossplatform. Et pour ca, il y'a GTK#, alors que demande le peuple? :)
        • [^] # Re: Mono 0.24

          Posté par . Évalué à 2.

          Obtenir des fonctionnalites specifiques a Windows sous Linux est aussi amusant que de faire un "fork()" sous Windows (comme le fait cygwin): l'imitation sera en dessous de l'original car pas prevu pour au depart.

          une seule chose a dire : Samba.

          Kha
          qui peut le plus peut le moins meme si des fois ca prend du temps
      • [^] # Re: Mono 0.24

        Posté par . Évalué à 1.

        Franchement, Wine c'est bien gentil mais on est tres loin d'une compatibilite a 100%. A la rigueur ca marche avec les DLL windows mais pour du pur Wine sans morceaux de Windows c'est pas encore ca.
    • [^] # Re: Mono 0.24

      Posté par . Évalué à 2.

      L'Api de M$ ne poura pas être porter vers GNU/Linux.

      http://www.go-mono.com/class-status.html(...)

      Certaine partie pose problème, d'autre fonctionne déjà très bien... (ASP.NET est pas mal avancé parait il...).

      (Manipulation de droits sur les fichiers qui dépendent du type de partition

      Le problème se pose sous Win32: pas joué avec les droits sur du fat, etc... ensuite, faire un outil d'administration de système de fichier portable, y'a comme un truc qui m'échape ;-)

      , Manipulation de la base de registre,

      Ne fait pas partie du framework.

      Fonctionnement graphique comme la systray, etc... )

      Visiblement c'est en cours, ceci dit, dans ce genre de truc la question n'est pas si ça va fonctionner ou pas, mais comment représenter une fonctionnalité analogue (et si c'est utile), sous Win32 la systray (qui officiellement s'appelle zone de notification) est très souvent mal utilisé, en principe elle n'existe que pour prévenir d'un évenement (connexion d'un périphérique USB, connexion à internet, déconnexion, etc...), sous gnome et kde (et bcp d'autre, mais ce sont les premiers qui me viennent à l'esprit quand on parle linux et desktop) tu peux avoir une fonctionnalité équivalente... et c'est là que ça peut devenir intéressant: permettre de faire qqch en tenant compte du système utilisé...

      Enfin, avis perso, même si .NET n'est jamais compatible entre mono et microsoft, si mono fourni une implémentation performante de .NET, ça restera sympathique, même pour faire des programmes absoluement non portable (non portable sous windows s'entend!).
  • # Re: Mono 0.24

    Posté par . Évalué à -2.

    viva perl
  • # Re: Mono 0.24

    Posté par . Évalué à 1.

    Il y a aussi DotGNU http://www.dotgnu.org/(...)

    Je ne connais pas bien les différences par rapport à mono, ceci dit.
    • [^] # Re: Mono 0.24

      Posté par . Évalué à 3.

      Mono c'est une implementation de .net, alors que dotgnu c'est autre chose, un autre framework, mais reprennant l'esprit et les idees de .net.

      En gros, dotgnu veut se poser en concurrent de .net alors que mono c'est .net sous Linux.
  • # promouvoir Java plutot que C#

    Posté par (site web personnel) . Évalué à 3.

    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).
    Mais qu'en est-il de C# ? C'est logiquement mieux car ils ont beneficie des erreurs du passe (Java date de 1995), mais c'est mieux de "combien" par rapport a Java ?
    Si ce fameux combien est de "5%" es-ce que ca vaut le coup de re-apprendre, d'abandonner ces habitudes et les outils performants ? On ne peut pas se permettre d'abandonner un langage pour un nouveau sous pretexte que celui est 5% mieux, en revanche une fois tous les 15 ans ca fait pas de mal ;)

    Pour moi ca vaut pas le coup par rapport au peu d'avantages que ca procure (sans compter tous les inconvenients: faire confiance a Microsoft, peu repandu, pas encore d'outils, encore des bugs car jeune...).

    Mon avis est qu'il faut mieux promouvoir des choses comme gcj plutot que Mono:
  • Java est promu par Sun et j'ai 10x plus confiance en Sun que Microsoft
  • Java est repandu, bien connu et etudie:
    - il y a beaucoup de livres dessus
    - les etudiants apprennent tous ce langage
    - c'est tres utilise en entreprise
    - on connait les avantages et les inconvenients de ce langage

    pour avoir un ordre d'idee il y a 8661 projects en Java sur Sourceforge (10812 en C et 10490 en C++ cf http://sourceforge.net/softwaremap/trove_list.php?form_cat=160(...) )
  • Il y a deja pleins d'outils libres/proprios pour Java (Eclipse, Ant, Tomcat, Jakarta, JBoss, Xerces, gcj, JUnit, JBuilder, Together ect...)
  • beaucoup de logiciels libres ont ete developpe en Java
  • Java evolue et de nouvelles fonctionnalites sont ajoutees (templates dans jdk 1.5)

    Le seul avantage a mes yeux de C# sur Java est qu'il est standardise.
    Mais Microsoft va-t'il faire evoluer le standard comme ca se fait pour C++ ou au contraire va-t'il y avoir un decalage important entre le standard et le C# utilise tous les jours (celui de Microsoft) ?
    Un standard n'est interessant que si les gens l'utilisent, le C# standardise est probablement un coup d'annonce pour se faire de la pub de la part de Microsoft plutot qu'une reelle volonte de s'ouvrir.

    Je pense que la communaute du libre a besoin d'un langage moderne pour remplacer le C++ et encore plus le C et ce langage a plus d'avantages a etre Java que C#
    Si maintenant on pouvait avoir des bindings performants, sans bugs de GNOME et KDE pour Java avec un bon compilo derriere ca serait le pied: le developpement de logiciel libre avancerait plus vite et probablement plus de personnes joindraient l'aventure.

    --
    Tanguy qui essaye d'utiliser le binding Java de KDE
  • [^] # Re: promouvoir Java plutot que C#

    Posté par . É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 (site web personnel) . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . Évalué à -2.

        Bah, autant que Java.
      • [^] # Re: promouvoir Java plutot que C#

        Posté par (site web personnel) . É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 (site web personnel) . É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 . É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 (site web personnel) . É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 . É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 . É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 (site web personnel) . É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 . É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 (site web personnel) . É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 (site web personnel) . É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 . É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 (site web personnel) . É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 (site web personnel) . É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 (site web personnel) . É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 . É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 (site web personnel) . É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 (site web personnel) . É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 (site web personnel) . É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 . É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 (site web personnel) . É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 (site web personnel) . É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 (site web personnel) . É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 . É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 . É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 (site web personnel) . É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 . É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 . É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 . É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 . É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 (site web personnel) . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 (site web personnel) . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 (site web personnel) . É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 . É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 . É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 . É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 . É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 (site web personnel) . É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 . É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 (site web personnel) . É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 . É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 (site web personnel) . É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 . É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 (site web personnel) . É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 . É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 (site web personnel) . É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 . Évalué à 1.

      business, solution, java, workflow, e-blahblah...

      On m'appelle ?
      • [^] # Re: promouvoir Java plutot que C#

        Posté par (site web personnel) . Évalué à 1.

        Finis ton coincoin.NET toi !
        (Et passe le bonjour à Pierrot.)
        • [^] # Re: promouvoir Java plutot que C#

          Posté par . É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 . É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 (site web personnel) . É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 . É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 . É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 . É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 . É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 (site web personnel) . É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 . Évalué à 0.

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

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

          Posté par . É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.
      • [^] # Re: promouvoir Java plutot que C#

        Posté par . É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 (site web personnel) . É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 . É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 (site web personnel) . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 (site web personnel) . É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 . É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 . É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 (site web personnel) . É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 (site web personnel) . É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 (site web personnel) . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 (site web personnel) . É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 . É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 . É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 (site web personnel) . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 (site web personnel) . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 . É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 (site web personnel) . É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.