boubou a écrit 1384 commentaires

le domaine du développement logiciel

Je crois que ce que voulais dire l'auteur de l'article (pourri) de Arstechnica est que Java n'a jamais vraiment pris pour faire des applications desktop, ce qui n'est pas complètement faux, mais ce qui néglige aussi le fait que beaucoup d'applications spécifiques (du genre la gestion de l'inventaire dans une boite lambda) sont maintenant développées un modèle de client léger, domaine dans lequel Java excelle.

Ceci dit, je suis d'accord avec toi, l'article de Arstechnica est pourri et l'interview de De Icaza est grotesque. C'est encroyable combien le Java bashing fait recette dans le monde linux. Et dire que Sun ne comprend toujours pas qu'il faut open sourcer Java, ça devient pathétique.

C'est donc surtout pas du tout libre. Poubelle.

Scilab est le seul concurrent digne de ce nom de Matlab qui est totalement propriétaire et en plus cher. Donc ta proposition, méprisante pour les auteurs du logiciel, n'est pas très réaliste.

Oui, mais cet usage commercial est très limité. Tu peux effectivement vendre scilab tel que, mais si tu fabriques un programme de calcul qui utilise scilab (même en faisant des appels externes par des scripts), tu ne peux pas faire une redistribution commerciale du résultat, même si ta partie est GPL, par exemple. On est donc quand même assez loin de la LGPL ou de même de la GPL.

Si, si. Et au passage, merci pappy, tu es trop gentil.

D'où vient le terme "libre pour usage non commercial" cité dans l'article ?

Des points 4.c et 5.c, par exemple :

The INRIA and the ENPC authorize you free of charge to circulate
and distribute for no charge, for non-commercial purposes the source
and/or object code of DERIVED SOFTWARE on any present and future
support, providing...

Scilab brut de fonderie est "libre". Pour que j'enlève les guillements, il faudrait que Scilab modifié de façon importante (quand il devient un DERIVED ou un COMPOSITE SOFTWARE) soit toujours distribuable librement, ce qui n'est pas le cas.

Il est vrai que la licence de Scilab n'est pas libre. Cependant, je suggère à tout le monde de la lire (http://scilabsoft.inria.fr/license.txt(...)) car il ne s'agit pas simplement d'un "libre pour usage non commercial". C'est en fait plus complexe. En gros, il y trois utilisations du logiciel :

1) tel que (avec des patchs pour corriger des bugs ou des ajouts de fonctionnalités) : dans cette situation, Scilab est distribuable "librement" par exemple sur une distribution linux (même payante). Ce n'est pas le cas de beaucoup de logiciels propriétaires (comme la JVM de Sun, acrobat reader, etc.) qui ne peuvent pas être inclus dans une distribution linux sans un accord explicite avec les propriétaires du soft.

2) adapté ou patché de façon plus lourde : là, effectivement, la distribution est "libre" si l'utilisation n'est pas commerciale

3) interfaçé avec un produit : là encore, ce n'est pas libre.

J'ai l'impression que l'INRIA voulait faire du libre, mais en interdisant de façon explicite à d'autres développeurs de faire du fric avec le logiciel, sauf dans le cas d'une simple difussion comme dans une distribution linux. J'avoue que je ne comprends pas trop le principe car il me semble qu'avec de la bi-licence (GPL+proprio), on peut faire très proprement du libre tout en permettant une utilisation commerciale classique (i.e. propriétaire). J'espère que Scilab passera donc sous une vraie licence libre dans ses prochaines version.

A cause du coût énorme de vérification d'identité.

Parce que tu crois que verisign vérifie _vraiment_ l'identité des personnes à qui elle délivre des certificats ? J'ai comme un doute.

Personnellement, vivre dans un pays qui n'est pas capable de concevoir un avion de combat avancé, ça me plairait. Et si aucun pays n'était capable de le faire, ça me plairait encore plus. Mais bon, j'ai bien compris l'exemple.

A priori non, car aucune machine virtuelle CLI n'interprète. Je pense que c'est plutôt du à la relative jeunesse du produit. Il ne faut pas oublier que les JVM sont vieilles et qu'elles s'améliorent pourtant régulièrement.

Quoi que tu en dises, cette news est quand même un modèle de mauvaise foi et de marketing baveux. Avant d'entrer dans les détails, je précise toute de suite que j'ai une bonne expérience de Java (que j'ai enseigné 6 ans) et que bien que n'ayant qu'une connaissance livresque de C# et de .NET, je trouve ces produits très intéressants et très supérieurs à Java sur certains points. De même, je trouve le projet Mono très intéressant et assez impressionnant.

Mais venons en à la news. D'abord, la comparaison avec Java est assez biaisée.

Je passe sur le FUD concernant IL auquel j'ai déjà repondu plus haut. Il est vrai par contre que certains éléments de CLI permettent d'implémenter plus efficacement certains langages que sur la JVM. Je pense en particulier au passage par référence qui n'existe pas dans la JVM. Cependant, de très nombreux langages tournent sur la JVM, donc ce n'est pas un si gros problème que ça. D'ailleurs, un JSR s'intéresse à ce problème et envisage de fournir plus de facilités pour l'implémentation d'autres langages sur la JVM.

Le passage sur les bindings est foireux. Oui, la notion de classe étant au centre de CLI, on peut appeler des classes C# en VB. Aucun problème pour faire l'équivalent en Java, cf Jython par exemple. D'autre part, il existe des outils qui construisent automatiquement les bindings JNI (un peu lourd il est vrai), cf en particulier la réalisation du binding opengl en Java (https://jogl.dev.java.net(...)).

Le versioning existe depuis longtemps en Java. Soit, il est moins évolué qu'en .NET, mais il existe. De même que les métadonnées en 1.5. Oui JNI est relativement lourd, mais cf au dessus.

Mais bien sûr, le plus scandaleux arrive ensuite, je cite :
"la plateforme Java est une solution propriétaire alors que Mono est une implémentation libre des normes de l'ECMA qui garantissent entre autres l'impossibilité de faire valoir des brevets logiciels (seuls les WinForms, spécifiques à Windows et non normalisés à l'ECMA, sont susceptibles de poser des problèmes légaux)."

Ba voyons.

Premièrement, ne sont normalisés par l'ECMA que la CLI, C# et sa bibliothèque système. On est loin des seuls WinForms. On doit par exemple ajouter ADO.NET et ASP.NET (cf http://www.mono-project.com/about/licensing.html(...)).

D'autre part dire que des normes l'ECMA qui garantissent entre autres l'impossibilité de faire valoir des brevets logiciels est un pur mensonge. Comme l'indique un des inventeurs de .NET qui est aussi un des auteurs des brevets associés (cf http://web.archive.org/web/20030609164123/http://mailserver.di.unip(...)), l'ECMA demande seulement des licences RAND, c'est-à-dire à un coût raisonnable et de type non discriminatoire. La notion même de coût raisonnable est incompatible avec l'open source et on ne parle pas ici des parties WinForms, ADO.NET et ASP.NET, mais bien de C# et de la CLI ! Microsoft s'est engagé à fournir des licences "royalty-free and otherwise RAND", ce qui ne veut pas dire grand chose. D'ailleurs, Novell n'a pas d'autorisation officielle de MS, à ma connaissance.

Je fais remarquer au passage que la plupart des organismes de normalisation demandent du RAND. Or, quand on voit qu'il faut officiellement payer pour pouvoir faire un player mp3 (qui est un standard internationnal), on peut avoir peur pour Mono.

Bref, .NET est donc au moins aussi propriétaire que Java qui est lui-même couvert par des brevets de Sun. Cependant, la communauté des détracteurs systématiques de Java semble oublier que Sun n'est pas le méchant dans cette histoire. Je tiens à rappeler que Sun a fait beaucoup pour le libre et pour les standards. Par exemple, RPC et NFS sont deux inventions de Sun. OpenOffice.org a été rendu possible par Sun qui contribue aussi au projet Gnome. Certains composants de la plate-forme Java sont officiellement open source et soutenus pas Sun. C'est le cas par exemple de Tomcat (implémentation de référence des JSP et des servlets), de l'api XML, ainsi que de ant (un projet de Sun à l'origine). Et qu'on ne vienne pas m'emmerder en me distant qu'il faut une JVM propriétaire pour les faire tourner, c'est faux, Tomcat et ant font justement partie des logiciels Java qui existent en version native grâce à GCJ et Classpath. Enfin, le JCP est un processus semi-ouvert (en tout cas beaucoup plus que ECMA) qui a voté une résolution permettant l'implémentation officielle des composants de la plate-forme Java en open source, avec même des aides financières de Sun pour passer les tests de compatibilité (cf Jonas qui est officiellement reconnu par Sun comme un projet qui vise à obtenir la certification J2EE 1.4).

Tout ça pour dire qu'avec l'histoire de Microsoft, je suis beaucoup plus soucieux pour l'avenir de Mono que pour celui des JVM open sources.

Euh à partir du moment où en Java tu es obligé de commencer en mode interprété, c'est que c'est pas terriblement optimisé pour être compilé

C'est faux. GCJ compile du java en code NATIF ! Il est de plus parfaitement possible de faire du JIT sans jamais interpréter le code. Je n'ai par regardé les sources de Kaffe, mais il me semble que sur une des anciennes versions, on pouvait avoir un JIT systématique. J'ai l'impression d'ailleurs que tu confonds la vérification du bytecode, étape présente aussi en IL, qui consiste effectivement en une interprétation abstraite du code, et l'exécution proprement dite.

Java a été conçu pour être inteprété

Ce n'est pas en répétant une chose fausse qu'on la fait devenir vraie. Je ne dit pas que la possibilité d'interprétation ne faisait pas partie du cahier des charges du bytecode JVM (alors qu'effectivement il est clair que cette possibilité ne faisait pas partie de celui de IL), mais d'autres éléments ont dirigé la conception.

bah vi dès le départ on peut compiler le code IL contrairement au bytecode qui n'est pas conçu et donc optimisé pour

Vu que tu affirmes avec beaucoup de force ce genre d'argument, j'aimerais que tu détailles. Ne te fais pas soucis, j'ai lu la spec de la machine virtuelle Java et la spec de LI, donc je connais un peu. Oui, IL a été conçu pour ne pas être interprété, donc quand on l'inteprete, ça rame. Maintenant donne moi un seul exemple, du même genre que celui que je donne plus haut, qui montre que le code obtenu après JIT est moins performant pour le bytecode de la JVM que pour le LI. Ou un exmple où le JIT du bytecode prendra significativement plus de temps que le JIT du LI...

C'est un FUD classique concernant IL. Le bytecode Java n'a pas été conçu spécifiquement pour être interprété mais plutôt pour proposer une sorte d'assembleur de haut niveau portable. D'ailleurs il n'est pratiquement pas interprété dans les machines virtuelles modernes où il presque systématiquement compilé au vol. La différence fondamentale entre IL et le bytecode de la JVM est que certaines instructions IL ne peuvent pas être interprétées efficacement. Par exemple, il n'y a pas une variante de l'instruction add pour chaque type fondamental (contrairement au bytecode de la JVM) ce qui fait que l'intepréteur devrait accéder à des informations globales à la méthode en cours d'exécution pour savoir quelle instruction native appeler. Au contraire, le bytecode de la JVM contient des variantes qui permettent une interprétation plus efficace que dans le cas de IL. Il est donc plus simple mais en déduire (comme le fait MS dans son marketing éhonté) que IL est optimisé pour le JIT est une vaste blague. En fait IL est d'encore plus haut niveau que le bytecode de la JVM et constitue en ce sens un vrai langage intermédiaire. C'est d'ailleurs un des éléments très positifs de .NET, mais bon, ce n'est pas une raison pour se faire l'écho du pipo de MS.

Oui c'est en gros ça, sauf que les solutions proposées sont dans l'esprit "on ne touche pas à la sacro sainte JVM". Le problème, c'est qu'il faudra un jour y toucher à cette JVM, sinon C# restera meilleur...

Ton exemple est intéressant, mais c'est un FPS, par un STR. En pratique, si tu veux gérer un terrain de jeu de taille nxn, tu va bien entendu utiliser kxnxn octets, où k designe le nombre d'octets nécessaires au stockage des informations nécessaires dans chaque case du tableau. Le problème est Java est que tu te tapes :

1) un overhead d'au moins 12 octets par objet
2) une référence bouffant 4 octets par objet
3) une non localité en mémoire et donc une indirection pour chaque accès à une case du tableau

Exemple concret, j'ai une carte warcraft III de taille 128x128. Si je veux stocker une information par case en Java, je consomme 256 ko d'overhead. Bien entendu, ce n'est pas grand chose, mais c'est symptomatique des problèmes de Java. La même chose en C# ne consomme aucun overhead, n'a pas de problème de localité en mémoire et ne nécessite pas d'indirection, donc c'est strictement mieux.

Concernant les templates, le problème va beaucoup plus loin que les simples types fondamentaux. En Java, les templates sont gérés par effacement du type, ce qui pose plein de problèmes sémantiques (en particulier de sombres histoires avec les tableaux). Des choses logiques sont impossibles, ce qui gêne l'apprentissage. De plus, aucune optimisation du code des templates n'est possible car il est commun à toutes les instanciations. En C#, la machine virtuelle peut décider de spécialiser un code pour profiter de divers éléments, par exemple le fait que certaines méthodes ne sont pas virtuelles ce qui permet des inlining. De plus, j'ai des exemples concrets en C++ en calcul numérique de codes entièrement templates sur le type réel. En pratique, T=double pour les applications classiques, mais on peut écrire T=Complex dans certaines situations, voire T=Interval quand on souhaite utiliser l'analyse par intervalle pour mesurer la stabilité de l'algorithme.

Ta dernière remarque me fait penser à un point important : ça fait des années que certaines possiblités qui sont absentes en Java (les énumérés, les templates, les structs, le passage par référence, etc.) existent dans des langages très utilisés (comme C++) ou réputés pour leur qualité en terme de génie logiciel (comme Eiffel ou Ada). Ta remarque donne l'impression qu'utiliser ces possibilités est dangeureux, alors qu'on maîtrise parfaitement ces choses. Avoir deux paramètres de sortie pour une fonction est plus qu'élémentaire, n'a rien de casse-gueule et fait partie du bagage de l'informaticien classique. Ce n'est pas parce que Java a privilégié une certaine simplicité à ses débuts (bien loin de nous avec les versions récentes), qu'il faut oublier les fondamentaux !

Je ne suis pas certain que le unsafe serve à grand chose dans C# (je n'ai aucun doute sur le fait que les gens l'utilisent, mais c'est un autre problème). L'intérêt est l'interfaçage avec du code existant, mais bon, on peut faire autrement. Je doute que cela soit particulièrement important pour les performances.

Ca apporte du code numérique lisible, du genre x=A*y+b où A est une matrice, x, y et b sont des vecteurs. C'est un gadget, mais un bon gadget. Et ce n'est pas prévu en Java, alors que ça existe en C#. Quelle misère.

Bref, le struct présente des avantages mais également des inconvénients, et donc n'est malheureusement pas encore la panacée.

Je ne dis pas le contraire, je déplore simplement l'impossibilité d'avoir ce genre d'objets (je revendique le lightweight qui correspond justement à l'absence d'héritage et de polymorphisme) en Java. Les exemples concrets ne manquent pas : comment représenter efficacement des nombres complexes en Java ? Comment représenter le terrain de jeu de stratégie temps réel ?

plutôt judiceux lorsque la base installée est faible... Mais en définitive, les limitations des templates Java impacte peu le développeur (uniquement dans la cas de la réflexion).

Ouai. Ca fait quand même des années que tout le monde demande des templates en Java et le JSR concerné était un des premiers (le 014 pour être précis). Donc l'histoire de la base installée ne tient pas trop la route. Sun ne semble toujours pas avoir compris que la JVM contient quelques erreurs de conception (ce qui est normal) et qu'il serait temps de faire des modifications incompatibles. De plus, si tu lis l'article qui présente la conception des génériques en C# (cf http://research.microsoft.com/projects/clrgen/(...)) tu verras qu'ils sont bien supérieurs à ceux de Java, en particulier en terme d'efficacité du code. Les problèmes d'instanciation vers les types natifs en Java font qu'utiliser une List pour contenir des doubles sera toujours totalement pourri, tant en terme d'occupation mémoire que de performance, à cause du (un)boxing.

Je pense enfin au passage par référence qui évite de créer des petits objets idiots quand on veut renvoyer deux valeurs depuis une fonction
??

Si tu écris une méthode qui renvoie par exemple la moyenne et l'écart type des valeurs d'un tableau, tu dois créer un petit objet débile pour contenir ces deux valeurs. En C# tu peux avoir des paramètres out (passés par référence donc) de type double pour contenir le résultat.

Même si c'est du bytecode, le bytecode doit être interprété avant de donner quelque chose à manger au CPU. C'est un fait.

Et bien non, le bytecode de Java et celui de C# sont compilés au vol. Renseigne toi, lit des docs et ensuite reviens discuter.

Et le développeur en C peut utiliser son cerveau et voir qu'il n'y a pas de débordement et ne jamais faire de teste.

Code dans les inombrables buffer overflow qui pourissent la sécurité des applications standards ?

Ok pour C#, je te fais confiance. Pour Java, les templates étant beaucoup moins puissants que ceux de C#, le problème est réglé.

Sinon, oui, je connais Blitz++, c'est très impressionnant. Concernant ta question pour blas, je te l'accorde, le code engendré par une expression template est a priori plus efficace (j'insiste sur le a priori). Le problème c'est que quant tu regardes une implementation efficace de Blas (par exemple Atlas), tu t'apperçois que c'est du délire. Le résultat est totalement contre-intuitif. Il me semble que les benchs que j'avais regardé de Blitz++ et autres expressions templates ne comparaient ces techniques qu'à du code certe correct mais naïf, c'est à dire par exemple à celui que tu donnes en exemple au dessus. Le problème est que pour obtenir une implementation efficace du calcul matriciel et vectoriel, il faut faire beaucoup plus. Je doute que Blitz++ tienne la route face à Atlas (Atlas est tellement efficace que la plupart des logiciels propriétaires ont abandonné leur code maison pour se baser sur Atlas, comme par exemple Matlab).

Ceci dit, Blas est difficile à relire, donc...

qu'un langage interprété

Java n'est pas un langage interprété. Il est compilé au vol, comme le C# et sur une application qui ne tourne pas 5 secondes, cela permet de faire des optimisations qui ne sont pas possible à faire (ou très difficile à faire) statiquement, ce qui donne au final un code qui est parfois plus rapide. De plus, certaines contraintes sémantiques de Java (ou de C#) font que certaines optimisations sont possibles dans ces langages et pas en C/C++ (en particulier à cause des pointeurs). Par exemple, on peut déterminer si les bornes d'un tableau sont respectées dans une boucle avant de l'exécuter, ce qui permet de supprimer les tests de débordement au moment de la compilation effective en code machine.

D'autre part, je ne vois vraiment pas le problème d'avoir un mélange de C et de Java, du moment que je ne vois pas le C quand je programme en Java. En fait, cela permet de faire ce qui est critique en C (voir en assembleur) et le reste en Java. Les progrès des machines virtuelles font qu'on a de moins en moins besoin de passer en C. Il y a quelques années, un jeu était programmé en C et en assembleur. De nos jours, on a un mélange Python pour les scripts, C++ pour le moteur de haut niveau, C pour attaquer OpenGL et de l'assembleur spécifique pour les shaders. A chaque problème son outil !

Je m'excuse pour avoir été un peu rude.

Tout pareil.

Je pense aux structs qui permettent de faire des objets légers sans l'overhead mémoire dont je parle au dessus pour Java. Je pense aussi au modèle retenu pour les templates qui demande une nouvelle version de leur VM mais qui est beaucoup plus efficace au final que le truc un peu batard retenu pour Java 1.5. Je pense enfin au passage par référence qui évite de créer des petits objets idiots quand on veut renvoyer deux valeurs depuis une fonction. Je suis sûr que j'en oublie...

Non, une appli de gestion, un site web, un outil de reporting, une compta, un distributeur de billet, une CRM, une place de marché....
qui sont aussi des applications très utile.

Je n'ai aucun doute sur l'utilité, de même que je n'ai aucun doute sur le fait que Java pour ces outils gaspille de la mémoire, qui est effectivement une ressource peu coûteuse sur un serveur.

on aurait donc tort de faire des trucs en Java ???

Si tu relis bien mes commentaires, tu verras que je ne critique pas le choix de Java. J'ai enseigné Java pendant de longues années (depuis 1997) et je suis convaincu que c'est un des meilleurs langages disponibles actuellement. Mais ça ne m'empêche pas de constater qu'il a de gros défauts. Et je suis vert d'être obligé d'admettre que C# corrige un bon nombre de ces défauts...

Oui mais non. Les templates sont dans la version 1.5 de java, disponible en version beta (soit, ça ne permet pas de faire des expression templates). Pour C#, ils seront aussi dispo pour la version 2. Avec les templates du C#, on aura des performances excellentes, comparable à ce qu'on obtient en C++ pour les histoires de comparaison que tu donnes en exemple.

D'autre part, je ne suis pas super convaincu par e=u+v+w. Soit, les expressions templates permettent de faire ça de façon relativement optimale, mais j'avoue qu'utiliser BLAS me semble beaucoup plus adapté. Oui, BLAS (et Atlas) est beaucoup plus lourd à lire et à maintenir, mais mon expérience du code numérique est qu'on l'écrit une fois pour toute, ce qui est important c'est ce qui existe autour de ce code. Donc, autant écrire un noyau numérique super rapide et testé de façon très complète (de toute manière, on est obligé) avec une bibliothèque de bas niveau comme Blas (ou la GSL pour un niveau plus élevé) et l'attaquer avec un langage de haut niveau (Java, Python, etc.).

Ce genre de phrase ne sert à rien dans le débat, merci de les garder pour toi.

Ouai, ouai. Tu crois que tu fais avancer le débat quand tu caricatures le propos de tes contradicteurs ?

Je ne sais pas quel genre d'applis tu développes mais honnêtement, tes exemples ne me font meme pas poser la question de savoir si C++ est mieux...

Je ne comprends pas. Je fais du calcul numérique pour des applications d'IA, et je me pose la question pour tous mes nouveaux développement: C, C++, C# ou Java ?

Très bon exemple...

Quel est le problème ? C'est très utile une matrice de nombres complexes. Tu préfères un exemple issus des jeux vidéos, genre le terrain d'un STR ?

Au fait, tu préviendras les chercheurs du CERN ( Cenrte européen Recherche sur le nucléaire ) qui ont besoin de nombreux calculs, de puissance et de mémoire qu'ils se sont plantés :
http://hoschek.home.cern.ch/hoschek/colt/(...(...))
et ils en ont un paquet de projets comme ça, nottament leur data grid.

Très joli argument d'autorité. Alors d'abord, je suis chercheur à l'INRIA (et oui), donc j'ai raison, n'est ce pas ? D'autre part, les chercheurs en physique ne savent pas programmer (c'est normal, ce n'est pas leur métier) et ont défendu pendant des années (ils le font encore) le fortran comme super solution pour le calcul numérique, alors que les compilateurs C modernes produisent du code au moins aussi performant que celui des compilateurs fortran. Enfin, je connais COLT, c'est une superbe bibliothèque, incroyablement performante pour un truc en 100 % java. Mais c'est 2 à 4 fois plus lent qu'Atlas (http://math-atlas.sourceforge.net/(...)), alors bon, franchement, ce n'est pas un très bon exemple.