smc a écrit 208 commentaires

You keep using that word, I do not think it means what you think it means.

Oui, le cloud public de Google c'est le Google App Engine. Ils font même tourner certaines de leurs propres applications (récentes) dessus (le reste, genre le moteur de recherche, tourne sur une instance spécifique, mais c'est le même bousin derrière, ça leur évite juste de pas planter quand un utilisateur fait une requête foireuse comme c'est arrivé il y a deux semaines :p). Donc quand tu utilises GAE pour faire ton application, tu disposes de l'infrastructure de Google, c'est non-négligeable en terme de latence, redondance etc :) (et en plus c'est moins cher que de mettre en place la même solution in-house). Chez Amazon, tu disposes de serveurs virtuels (donc c'est beaucoup plus bas niveau, tu es plus libre mais certains trucs sont moins évidents, puisque Google te fournit des services de parallélisation sympa, style BigTable + MapReduce). Enfin, IBM et Microsoft proposent aussi des solutions (quoi qu'un cloud sous Windows j'aurais du mal à y faire confiance :).

Donc l'OS qui fait tourner véritablement les applications Web, c'est, chez Google, le Google App Engine, mais pas forcément bien entendu (n'importe quel site web).

A priori, Google Chrome OS est uniquement Google Chrome packagé dans un OS basé sur Linux avec un support offline (Gears) et un meilleur niveau d'intégration entre les applications et l'environnement graphique.

Chrome permet déjà d'utiliser les applications de façon offline avec Google Gears. En gros, les applications distantes enverront un agent pour continuer à fournir le service possible sans l'accès au réseau.

Windows, GNOME/KDE, OS X sont partis d'un OS offline avec des clients lourds et les transforment progressivement en clients riches. Google part d'un client léger et ce sont les applications distantes qui fournissent la logique pour en faire des clients riches. Pour l'utilisateur final, pas de grosse différence (outre que tout est immédiat, car il télécharge l'application en background, pendant qu'il l'utilise normalement), mais c'est probablement plus pratique pour la maintenance et la mise-à-jour des applications (le mode "online" est le mode par défaut).

Et puis, le niveau d'intégration de ces applications "Web" au système local sera sans doute tel qu'on ne fera pas la différence avec n'importe quelle application habituelle.

Entièrement d'accord avec toi, néanmoins il faut reconnaître que .NET ou pas, maintenant Java a été libéré et il y a une licence non révocable pour tous les brevets liés à Java détenus par Sun pour toute la communauté, ce que Microsoft n'a pas fait et qui est la raison de l'appel de Stallman (surtout quand on connaît les pratiques de Microsoft).

Donc Sun a foiré son coup pour différentes raisons (peur de forks non compatibles après le coup de Microsoft avec leur "JVM" "embrace, extend and extinguish" , code tiers dans le JRE qu'ils n'avaient pas le droit de libérer, etc), mais ils se sont repris.

Il ne tient qu'aux développeurs de faire en sorte que Java reste la plateforme pertinente. RMS adresse son message à ceux qui veulent bien l'écouter, c'est-à-dire les libristes de toutes façons. Je comprends qu'un développeur Windows utilise .NET et qu'on utilise Mono (si par chance le code n'utilise pas WPF ou Ado qui ne sont pas portés à ma connaissance, et pour lesquels ils y a encore plus d'insécurité juridique). Mais si un développeur libriste utilise Mono (comme les développeurs de Tomboy et la clique de Miguel de Icaza), je comprends pas pourquoi ne pas faire l'effort similaire sur Java qui, même s'il a des différences (retards et avantages) avec .NET, reste tout de même semblable (et plus abouti que Mono) et ne présente pas les mêmes risques juridiques.

J'ai hâte de voir quelle politique Oracle suivra, ils ont déjà dit qu'ils continueraient avec le JCP et les implémentations libres de Java, mais je suis sceptique. Le seul point d'espoir, c'est qu'Ellison hait vraiment Microsoft donc ils devraient leur offrir un match honnête, s'ils ne sont pas trop cons pour se mettre contre IBM qui est un énorme soutien de Java.

Oui et non, la release intègre désormais, dans un update site par défaut, le support SVN "subversive" pour le plug-in "Team" de travail en équipe, mais le connecteur lui-même (l'implémentation SVN) n'a pas pu être intégré pour des raisons de licensing. Sous GNU/Linux il faut utiliser SVNKit, une implémentation 100% Java de SVN, et il est disponible sur l'update site de Polarion.

Bref, c'est toujours la merde :).

Il y a eu une dépêche détaillée il y a 3 jours dessus... d'où mon commentaire. Je suis le premier à trouver que certains journaux manquent d'introduction ou d'un lien de référence, mais bon là c'est encore en première page, donc c'est un peu gros de critiquer.

Pour info, Galileo n'est pas ni future version d'Eclipse, ni Eclipse 3.5. C'est la release groupée annuelle du projet Eclipse, et ça ne s'explique pas en deux mots. Et Galileo est sorti mercredi dernier.

Ou bien tu pourrais lire les dépêches.

Non, je ne l'élude pas.

Le gars devra coder en Jakouski s'il veut *modifier* la partie spécifique écrite en Jakouski, mais avec de la programmation par composants qui se fait de nos jours (pour la JVM, c'est OSGi), quelqu'un qui voudra utiliser les fonctionnalités de Jakouski dans son programme ou même l'étendre pourra le faire en Java ou un autre langage de la JVM.

Je n'ai jamais prétendu que la VM résolvait tous les problèmes et la fin de de la guerre dans le monde, si c'est ce que tu as tiré de mes commentaires je suis désolé :).

Ces capacités d'interopérabilité entre langages n'existent que dans les VMs récentes (et en pratique, dans le monde logiciel industriel, que .NET et JVM)... Comme je l'ai déjà dit, l'avantage de cette interop est qu'elle est automatique, transparente et bi-directionnelle, à la différence de bindings C vers Python (qui va faire un programme écrit en C qui tourne sur Zope ?).

Bien évidemment, si quelqu'un veut modifier du code écrit dans un langage donné, il lui faut apprendre ce langage. Comme je l'ai déjà dit (ça aussi), mon problème c'est de passer trop de temps à écrire en Jakouski, pas de modifier légèrement le code. Pour des raisons de séparation des concerns, je ne vais pas faire faire au programme Jakouski des conneries qui dépassent le cadre de son activité ; pour ça j'écrirai une extension qui peut être dans un autre langage.

Il y a aussi le fait qu'en entreprise les langages doivent être validés, donc évidemment on va éviter de coder dans n'importe quel langage sous prétexte qu'il tourne sur la JVM, il faut de bonnes raisons (je me répète).

Enfin inutile de passer encore 3 semaines à discuter de ça, on a chacun nos points de vue issues d'expériences différentes et peut être que tu changeras d'avis, peut-être pas. Je partageais ton opinion donc c'est possible d'en changer... par contre je ne vais pas retourner en arrière. Y'a rien qu'à voir la merde qu'est le classloading avec des dépendances en C++ ou dlopen en C ; les bindings pour chaque langage c'est mieux que rien, mais des bindings on peut aussi en faire pour la JVM (et c'est tout aussi chiant).

La différence c'est que la JVM c'est pas un langage, c'est une plateforme, et que ça rend les langages qui la ciblent compatibles de façon transparente et automatique. Je peux créer un paquet sous forme de JAR et le déposer dans un conteneur et le langage que j'aurai utilisé n'imposera aucun choix sur le reste des applications qu'elles utilisent mon propre code ou non, excepté d'utiliser la dite plateforme. Maintenant, si tu veux pas comprendre l'intérêt, je vais pas te forcer.

C'est toujours plus facile que de maintenir une distribution GNU/Linux avec 20 langages facile avec des versions parfois différentes.

Encore une fois, je ne parle pas d'une petite application. Les grosses applications d'entreprise (du moins depuis Java) sont gérés par des frameworks qui s'assurent du découplage des parts. Chaque partie constitue un projet différent (et donc susceptible d'avoir un langage différent).

Euh, mais tu as suivi ou pas ? :)

Clojure et Scala tournent sur la JVM. Le langage que j'utilise nécessite que les autres développeurs qui veulent ajouter des fonctionnalités (si c'est conçu de façon modulaire comme il faut) doivent programmer pour la JVM. Parmi les choix sérieux bien sur y'a Java, Scala, Clojure, Ruby (JRuby), Python (Jython) et JavaScript (Rhino).

Alors que le toto qui m'impose D, bien j'ai pas le choix, je dois faire du D.

C'est pourtant simple, je pense à moi ! Si un nouveau langage (comme D) commence à être utilisé mais n'apporte aucun confort de programmation ou n'est que la redite d'un truc fait 50x, je vais pas avoir envie de l'utiliser. D, c'est ce qu'aurait pu être Java sans VM, avec quelques trucs mieux faits (fort heureusement). J'aime pas Java, j'ai aimé C++ pour tout ce qui n'est pas dans D (tous les petits détails de merde que j'abhorre désormais parce que j'ai plus que ça à foutre me faisaient triper comme un malade)... Alors vraiment il n'y a aucune raison que j'aime D (pour être honnête, j'aime le design par contrat mais ça a déjà été fait dans Eiffel, et ça peut être fait avec des annotations Java). Comme d'ailleurs tout le monde, parce que malgré les efforts acharnés (et presque pathétiques) de son auteur, il n'a percé nulle part.

J'aime pas les langages strictement impératifs, même si des traits impératifs sont toujours pratiques, tout simplement parce qu'ils imposent un design trop simple et j'ai l'impression d'avoir des menottes quand je les utilise. Dans le panier "fonctionnel" on met tout et n'importe quoi, mais au moins avec les fonctions comme citoyens de première classe et donc pouvoir faire des designs de second ordre, c'est le minimum ! En pratique pour faire des applications solides et parallèles, les données immutables et l'absence d'effets de bord non explicites sont aussi super pratiques. Après, des fois ça va loin et c'est pas non plus pratique ou ça impose une gymnastique mentale qui n'est pas à la portée de tous, et en tant que feignasse (je suis pas informaticien pour rien), je suis bien content que des singes se tapent le boulot qui m'intéresse pas dans un langage débile (par exemple : Java). Evidemment j'hyperbolise, mais il y a beaucoup de professionnels qui ne s'intéressent pas à l'informatique et qui codent néanmoins ; il faut des langages simples pour eux.

Le problème avec cette fragmentation des langages, c'est qu'elle me retombe dessus. Imagine une grosse entreprise où un hurluberlu décide d'utiliser D ou je ne sais quel langage qui sort de nulle part, qui ne fait que réinventer la roue avec des avantages minimes, et n'est pas compatible de façon transparente avec une plateforme existante. Imagine que je travaille ou sous-traite pour cette entreprise et je me retrouve à bosser sur ce projet.

Et bien non seulement je suis forcé d'apprendre ce langage (pas très gênant), mais surtout je suis forcé de *bosser* dans ce langage limitatif qui emprisonne mes belles idées (et en plus je dois apprendre à utiliser le tooling, c'est pas le cas de D qui se branche sur le frontend gcc si je me souviens bien, mais certains langages vont jusqu'à utiliser leur compilo avec des options débiles, leur chaine de build autiste qu'ils ont refait dans leur langage alors qu'il en existe 5000, etc).

En revanche, un langage qui ne fragmente pas, et qui fait que, sans émerveillement pour la plateforme JVM, je la reconnais comme un choix logique et intéressant, il ne va pas me poser de problème. Imagine la grosse boite, le gars fait son projet en Groovy ou pire, en Fan. J'aime ni Groovy, ni Fan, mais c'est la vie.

Quand j'arrive sur ce projet, si c'est pour des contributions notables et que ça va me prendre du temps, je vais pouvoir utiliser des langages qui me bottent pour bosser ! Clojure si je suis d'humeur à faire du Lisp, et Scala si je suis d'humeur... à faire du Scala (pour moi, c'est OCaml avec un coding style Java et plein de features très funky qui me plaisent et qui pour le coup innovent pas mal dans la manière de faire même s'il reste du travail à faire).

Je suis pour la création de langages ! On peut difficilement l'être plus que moi, je suis fan de DSLs, de langages, etc. Mais réinventer un n-ième langage généraliste qui n'apporte rien, et qui en plus nécessite de tout refaire ? Non merci.

J'aime les langages de programmation, et il y a plein d'idées dans le monde des langages, dont certaines qui ne sont pas intéressantes à intégrer à une plateforme style VM (en Haskell on va pas coder chaque appel de méthode Java avec une monade quand même, ça n'a pas de sens de l'intégrer à la JVM dans l'état actuel de la JVM). Mais dans ce cas, il faut le justifier avec de bonnes raisons : des concepts non compatibles, le ciblage à l'embarqué dans des conditions particulières, etc. Pour moi D n'a rien de tout ça. Je sais même pas pourquoi on en parle.

Pour moi, les VMs c'est super pratique. Et D a du réaliser ça, puisque maintenant ils ont D.NET ! Et si je suis pragmatique j'ai le choix entre .NET et la JVM. J'ai fait mon choix.

Je connais D et les seuls concepts qu'il apporte existent déjà dans de nombreux langages industriels next-gen (et depuis des décennies dans les langages de recherche). Oui D c'est C++ sans les horreurs de C++ (donc mieux que C++, avec beaucoup moins de compatibilité et de visibilité avec l'existant), mais à mon avis c'est peine perdue de se lancer dans un autre langage sur le modèle de C++/Objective-C qui est sont perte de vitesse. Tu me diras sans doute qu'Objective-C marche grâce à Apple et à l'iPhone, mais ce qui marche c'est le lock-in, si les développeurs avaient le choix à mon avis peu utiliseraient Objective-C.

Pourquoi se faire chier avec encore un autre langage impératif...

Il y a une différence entre écrire un nouveau langage qui s'inscrit dans une logique de réutilisabilité dans le cadre d'une tâche spécifique, et écrire un nouveau langage à part qui répond à un besoin inexistant.

C'est compréhensible quand il s'agit d'un langage de recherche qui apporte des concepts nouveaux, ou quand il s'agit d'un langage industriel qui fait ces apports ; dans le cas d'un langage comme D ça n'a aucun sens car il est déjà dépassé avant même d'avoir connu la moindre heure de gloire.

Mais je suppose qu'il était plus facile pour toi de ne pas faire le moindre effort de compréhension du point que je soulevais et d'attaquer mon message inutilement.

C'est : "personne n'a jamais été viré pour avoir choisi IBM". Ce qui ne risque pas d'arriver à un fonctionnaire :).

Oui en fait j'ai dit une connerie plus tôt car j'étais resté sur des benchs d'il y a plusieurs années, mais Jython a beaucoup de retard côté perf. C'est con qu'ils n'aient pas mutualisé avec JRuby qui lui est plutôt performant (plus que Groovy, mais moins que Clojure ou Scala).

Oui je m'en suis rendu compte après, c'est l'horreur :(. La balise cite ne me convient pas non plus. En plus là elle gère mal les quotes imbriquées.

C'est rigolo, je croyais que le java était un langage facile est efficace.


Je pense qu'aucun langage de programmation n'est "facile". Java est conçu pour être simple (et pas facile), ça n'empêche pas que chaque langage a ses propres idiomes et qu'il est insensé de transcrire naïvement le code sans tenir compte des propriétés du système (en l'occurrence la JVM).

Il faudrait que tu montres le code pour qu'on puisse te dire ce que tu fais mal, car c'est clair qu'il y a un problème vu les différences que tu trouves entre Java et C. Mais en réalité, c'est pas très important, comme il a été dit plusieurs fois, il y a plein de benchmarks bien faits sur le Web qui montrent que Java n'a pas à rougir niveau perfs.

C'est une question de compromis entre le niveau d'abstraction et la performance du code. Dans le monde réel, le compromis proposé par la JVM est intéressant et c'est pour ça que tout le monde, en dehors de Microsoft, utilise Java.

Java est présent dans des applications où il devrait à avoir du C (ou équivalent). Python et ruby non.

Non. Java a remplacé C++ qui est un enfer à maintenir et à programmer, et je dis ça en tant qu'ancien fan de C++ qui a vu la lumière et qui s'est reconverti. C++ c'est un jouet fun mais ça fait plus de mal que de bien.

Non, j'avoue, je n'ai rien codé d'aussi complexe. Et tant mieux, je n'ai pas la prétention de pouvoir le faire.

Donc, si je suis bien ton discours, tu dis "les applications complexes devraient être programmées sans GC", à quoi je réponds "ça va pas, c'est justement là qu'il est le plus utile" et tu me dis qu'en fait tu ne sais pas de quoi tu parles ;). Et bien je te dis, prenons par exemple le cas d'Eclipse vu que tu l'as utilisé comme IDE. Eclipse c'est des millions de ligne de code si tu prends que les projets de l'Eclipse Foundation (sur eclipse.org), sans compter les très nombreux projets extérieurs. Et dans un langage bien plus expressif que C.

Dans un tel système, s'assurer qu'il n'y a pas de memory leak, c'est difficile. Le garbage collector aide énormément.

Mais pas seulement pour ça. Au niveau des propriétés même du langage, c'est pratique d'avoir un garbage collector car ça te permet de savoir que si tu as une référence sur un objet, il existe. Dans un contexte de mémoire partagée (en multithread), et même si c'est bien d'éviter ça en général parfois on n'a pas le choix, c'est hyper pratique.

En C ou en C++, tu peux te retrouver avec la main sur un pointeur qui pointe dans le vide. T'es donc obligé, dès que t'as un pool de mémoire partagée, de créer toi même une abstraction sur tes pointeurs (en l'occurence, on utilise boost). Le garbage collector simplifie la vie de tous les programmeurs et l'overhead est minime comparé aux avantages. Encore une fois, c'est un compromis qu'on fait parce qu'il est impossible d'avoir uniquement des développeurs qui maîtrisent non seulement le langage, mais aussi la façon précise dont fonctionne l'application : en C/C++, une bonne partie du code, c'est pas du métier, c'est juste comment tu vas utiliser ton application. Heureusement y'a des frameworks / libs mais ils vont moins loin que ce qui existe en Java ou en .NET.

Uniquement ? Par certain ça… J'essayerais bien de tout virer (et de comparer avec la vitesse de lancement de nano, pour faire du comparatif de qualité).

Donc cette fois, tu veux comparer la durée de lancement d'un programme ncurse avec le lancement d'un programme graphique ?

Encore une fois, et j'ai l'impression que tu refuses d'entendre ça... je ne dis pas que Java ou la JVM est plus rapide ou aussi rapide qu'une application C/C++. Je dis qu'elle est *suffisamment* rapide (et à vrai dire, pas loin de C++), et que si tu as un PC antique c'est le PC qu'il faut changer, pas la JVM !

Car ils ont plus de contributeurs qui aiment le java ?

Personne n'aime Java. J'aime pas Java. Il y juste des gens pragmatiques qui reconnaissent une solution efficace ou pas. Apache utilise Java parce qu'il s'agit du langage d'entreprise ouvert.

C'est le problème quand on troll. Mais si java devient correcte un jour, je l'utiliserais. Dans l'état actuel, cette alternative ne me semble pas intéressante.

Il me semble que tu n'as pas regardé d'assez prêt ce qu'est "Java" aujourd'hui.


Clairement, tu n'as jamais utilisé un framework Java style OSGi ou Spring, car les équivalents n'existent pas en C++ .

Ouais, j'ai du faire autre chose en cours et en TP de java.

C'est pas avec quelques cours et TP de Java dans un IUT que tu risques de réaliser des avantages du langage. C'est probablement le langage avec le plus de bibliothèques, de frameworks, etc pour tout et n'importe quoi aujourd'hui. C'est le langage qui tourne sur le plus d'ordinateurs (je compte les téléphones portables).


Tu bases tous tes arguments sur Java, le langage, alors que je parlais explicitement de Java, la plateforme.

Oui, c'est la java que j'aime pas. Je n'ai rien contre les multiples librairies java à part leur lenteur due au langage.

Je ne parle pas particulièrement des bibliothèques mais surtout de la JVM et des langages alternatifs comme Scala ou Clojure, qui offrent clairement un confort à des années lumières de C ou de C++.

Bah un garbage collector a une utilité pour les applications d'entreprise mal codées, une machine virtuelle pour maintenir une stabilité au détriment des performances, et les langages interéprétés sont mieux fait que le java.

Après tu dit que ces langages interprétés sont plus performants avec la jvm. Tant mieux, au moins elle sert à quelque chose cette machine virtuelle.

Le garbage collector n'a rien à voir avec coder mal ! Ca fait partie du paradigme, comme les exceptions ! Une application complexe, il y a plein de développeurs qui vont travailler dessus, et pendant des années, voire dizaines d'années ! Il faut que quelqu'un qui se ramène dessus puisse la maintenir, la modifier sans tout casser. Les applications C ou C++ ont souvent leur pseudo framework maison bordélique qui change tous les ans qui rend la maintenance compliquée. En Java, tout ça, c'est standardisé ! Même la façon de nommer les classes, méthodes, tout est standardisé. On obtient un code bien plus uniforme mais surtout plus facile à maintenir.

Enfin, trouves-tu vraiment inutile qu'un développeur qui crée une application sous Windows sans penser à Linux ou à Mac produise du code compatible ? Trouves-tu que la situation d'avoir trois systèmes avec des frameworks qui se limitent à chaque système (et même parfois plusieurs frameworks comme GNOME et KDE sous Linux) est acceptable ?

Et si t'allais voir le site et la tronche du code au lieu de troller :).

Depuis quand la syntaxe fait-elle partie des concepts ?

Effectivement, les comparaisons de performance dépendent de beaucoup de facteurs. Si une fonctionnalité est appelée plus souvent dans un programme particulier qu'une autre, l'optimisation sur cette fonctionnalité est plus importante. La façon dont Jython va traduire le code Python importe donc, et les optimisations de Jython en plus de celles de la JVM.

Pour Jython les cas plus rapides sont moins clairs qu'avec JRuby à cause de l'arrêt dans le développement de Jython pendant plusieurs années, alors que la performance de CPython s'est améliorée. J'ai été un peu vite donc, je parlais plus de JRuby niveau perf.

Non, non et non.

PIL est une bibliothèque C bindée en Python, et wxPython est un bind pour wxWidgets (C++). Il faudrait porter les bindings avec JNI (Java Native Interface).

C'est le cas pour wxWidgets avec le projet jwx!. Tu peux donc l'appeler depuis Jython, mais l'API ne sera pas celle de wxPython à moins de faire un wrapper toi même. En revanche, le résultat sera strictement identique.

Pour ce qui est de NumPy, il y a eu un projet pour le faire marcher avec Jython, je ne sais pas où ça en est.

Néanmoins il existe des alternatives pour toutes ces bibliothèques dans le monde Java (ou la possibilité de les porter).

Notamment pour le calcul scientifique, il y a Fortress qui est basé sur les concepts de Fortran et qui tourne sur la JVM.


En gros, pour qu'un logiciel tourne aujourd'hui dans Jython, il faut que le code soit entièrement écrit en Python, et compatible 2.5. Tout ce qui est intense en calcul est habituellement écrit en C ou en C++ et bindé en Python.

Je connais D, mais il s'inscrit encore une fois dans une logique de fragmentation des langages. D'ailleurs, il y a eu une discussion sur Slashdot il y a quelques mois, où l'auteur à participé, et le consensus général était "oui mais non".

Génial, la CSS par défaut de LinuxFr connaît plus les blockquotes.

Juste pour rigoler, je viens de m'amuser à faire un tout petit test de mauvaise qualité.

C'est une fonction qui s'appelle récursivement 5000 fois (je voulais faire plus, mais java part très vite en stackoverflow). Pour bien voir la différence (et gommer le lancement de la jvm que tu dis négligeable mais qui fait que c'est 80 fois plus lent dans l'état), c'est appelé 655536 (oui il y a un 5 de trop) dans une boucle for.

En c, je trouve avec la magnifique et aléatoire commande time un temps de 25 secondes.

En java je trouve 1 minute 46. Et je pense que des boucles for et des appels de fonction, c'est un peu la base.

Donc là je vois que sur mon pc java est plus de 4 fois plus lent que du bon vieux C. Et encore, j'ai un x86, je sais pas si t'as déjà touché du java sur les macs power pc, mais c'est vraiment l'horreur (on dirait un facteur 10).

Ton test n'a aucune valeur. Tu testes quelque chose qui va contre le paradigme de Java. La JVM n'a pas la TCO (Tail-Call Optimisation) et c'est bien connu. La seule chose que ton test montre, c'est ta propre incompétence en Java et la démonstration que tu es plus que mal placé pour faire ce test.

Ensuite, tu crois vraiment que faire un appel N fois va changer quelque chose à l'ordre de grandeur qu'il existe entre l'appel d'une fonction et le lancement d'une VM ? Et la compilation JIT si jamais tu n'as lancé ton test qu'une fois ?

Pour faire le test de manière propre, il faudrait avoir déjà lancé la JVM en mode serveur, et il faudrait utiliser l'IDIOME du langage que tu utilises.

Enfin, comparer C et Java ça n'a aucun sens. Pourquoi ne compares-tu pas C à Python ou C à Ruby pour qu'on rie ?

Va voir http://kano.net/javabench/ pour une véritable comparaison de C++ et de Java par quelqu'un qui connaît les deux langages.

Je passe ensuite sur le ramasse miettes imposé qui je pense est une abbération totale pour des grosses applications (firefox en utilise un, bonjour le résultat… J'ai deux onglets, il me consomme 300Mio de mémoire vive). En C et C++, si on veut ne pas se fatiguer et devoir tout recoder car la concurrence gère mieux la mémoire (cas de firefox et webkit), c'est notre problème. En java, chaque grosse application ressemble à eclipse.

J'ai du mal à croire que tu aies déjà programmé un véritable système d'informations et que tu puisses dire ça.

La gestion manuelle de la mémoire est un bordel au niveau de la maintenance et de tout ce qui est partage de mémoire. Ton attribution du footprint de firefox au garbage collector est encore une fois un argument fallacieux. Essaie Firefox 3.5 (Shireteko) qui a toujours un garbage collector et un footprint moindre !

Même en C++, n'importe quelle application de taille raisonnable va utiliser une forme de gestion automatique de la mémoire, que ce soit les pointeurs managed en boost ou un garbage collector posé en ad-hock. La gestion manuelle de la mémoire, c'est la cause principale des leaks qui posent beaucoup plus de problème qu'un footprint plus important. En plus, le garbage collector d'HotSpot est super efficace.

Je dis pas qu'on peut pas écrire un logiciel complexe sans garbage collection, je dis que n'importe quel langage de haut niveau en a un pour de bonnes raisons. Ocaml n'est pas réputé pour sa lenteur, au contraire, et il utilise un garbage collector. Pareil pour Python, Ruby, etc.

Le problème d'Eclipse n'a rien à voir avec le garbage collector, c'est uniquement le fait qu'il est extensible et que tous les composants / plug-ins ne sont pas de même qualité.


Alors, tu avances la facilité de coder. C'est vrai que c'est plus facile de faire une fenêtre en java qu'une fenêtre en C et gtk.

Mais prenons les utilisations courantes du java:
IHM: C'est plus que moche si on utilise swing, et awt est plus vraiment utilisé. Ça me fait byzarre d'avoir une application toute moche en bleu clair que ce soit sur n'importe qu'elle système. Surtout avec un thème sombre…
Web: C'est comment s'embêter pour pas grand chose. Quand on a goûté à Ruby on rails (qui est très lent), ou même à un framework php, on voit pas trop l'intérêt d'utiliser java qui est une énorme usine à gaz.
Les applets: À la limite, je préfère un flash proprio qu'un applet java qui me fasse ramer.

IHM: N'importe quoi pour les IHM. J'aime pas Swing non plus (qui s'est beaucoup amélioré en perf et graphiquement), mais il est autant possible d'utiliser SWT qui fait l'abstraction sur la bibliothèque graphique native, GTK sous GNU/Linux ou Solaris. Et (comme je l'avais dit, mais clairement tu ne m'as pas véritablement lu), il existe des bindings GTK/Gnome et même Qt (Jambi). Encore une fois, t'es resté sur des constatations d'il y a dix ans.


Web: Il y a des dizaines de frameworks en Java ou pour la JVM. Il y a aussi énormément d'intérets pour ces frameworks. Pourquoi Apache fait à 90% du Java selon toi?
RoR tourne plus rapidement sous JRuby.

Et il y a encore mieux, il y a Lift en Scala qui fournit la même avancée par rapport à RoR, que RoR fournissait par rapport au reste il y a quelques années.

Encore une fois ton rejet simple et direct du monde Java te fait passer à la trappe des alternatives plus intéressantes.

Enfin, les applets, personne ne les utilise plus, alors je vois même pas ce que ça vient faire ici.



Pour la rapidité de coder, je pense que tu veut parler des librairies, car «System.out.println» c'est sympa deux heures. C++ et Qt n'a rien de plus lent à coder que java. En plus la doc est mieux faite.


Clairement, tu n'as jamais utilisé un framework Java style OSGi ou Spring, car les équivalents n'existent pas en C++ (pour de bonnes raisons, vu que la réflexivité avec le RTTI est limitée en C++).

Et tu as encore moins utilisé Scala ou Clojure.

Tu bases tous tes arguments sur Java, le langage, alors que je parlais explicitement de Java, la plateforme.



Donc non, les développeurs kikoo lols qui veulent coder vite et mal en passant sur la conception, moi je veut bien qu'ils s'abandonnent à mono. Les vrais professionnels qui font des applications lourdes et utilisées, je préférerais qu'ils oublient les machines virtuelles.

Tout ce que je vois ici c'est que tu n'as aucune idée du monde de l'informatique professionnelle et des réalités des systèmes complexes. On a besoin de langages plus expressifs qui offrent des garanties sur l'exécution, la maintenabilité, etc.

On a des ordinateurs plus puissants, et même si c'est pas une raison d'oublier la performance, on ne va pas faire de l'assembleur parce que c'est "plus performant". Le C/C++ sont utiles pour la programmation système. Pour tout le reste, il y a... la JVM Mastercard.

Car les machines virtuelles pour des applications de bureau, c'est quoi l'intérêt ? Ne pas devoir compiler pour chaque architecture ? C'est tout ? C'est trop compliqué de fournir du x86, du x86_64 bits et les sources (ça suffit maintenant que apple ne vends plus des ordinateurs de qualité) ? Quand je pense aux nombreux problèmes que j'ai eu entre la jvm de sun et celle qui est libre…


L'intérêt c'est que le développeur qui fait une appli pour Windows, tu utilises son appli sous Linux. L'intérêt c'est qu'il n'utilise pas une lib specific Cocoa ou Win32.

L'intérêt c'est que ton application elle fait partie d'un écosystème et utilise des bibliothèques qui ont d'autres cas d'utilisation, par exemple elles peuvent être utilisées en cluster avec Terracotta... sans modifier leur code.


Enfin bon, voila quoi. Java c'est bien pour coder rapidement une petite application. Mais c'est un peu le chaînon inutile entre les langages interprétés pour les scripts et petites applications (quoique les GUI en python ça me gonfle), et les langages compilés.

Java est compilé 'just in time'. Tu demandes quoi de plus ?
Il existe des langages de scripts pour la JVM très performant, pourquoi ne pas utiliser la JVM comme VM générique plutôt que des interpréteurs inefficaces ?

Mon troll java n'est pas près de mourir pour moi :-)

Je vois ça ; je pense que tu devrais baser tes opinions sur des faits et sur l'expérience de l'industrie. Car à t'entendre, tout le monde doit être très con, aussi bien dans l'industrie que dans la recherche, d'utiliser des langages sur des VMs avec garbage collector. D'utiliser des langages fonctionnels plutôt que C ou C++...

Oui, faut quand même dire que c'est plus performant que la majorité des interpréteurs Python...

De même, JRuby est notablement plus performant que les interpréteurs habituels Ruby MRI ou même YARV.

Les JVMs, et notamment HotSpot, sont très performantes, même si un certain nombre d'amateurs en informatique sont restés sur l'idée que Java n'a pas changé depuis 98 et est toujours aussi lent. Il y a eu une série d'optimisations hallucinantes qui en font sans aucun doute la VM *ouverte* et dont il existe une implémentation *libre* la plus performante.

Ce qui est lent avant tout, c'est le lancement de la JVM (toujours moins lent que le lancement de Ruby MRI ou PyPy), et il est négligeable car sur n'importe quelle machine qui utilise du Java de nos jours, on la lance au démarrage du système et elle se pose en mode serveur.

Le rejet par une grande part de la communauté libre du monde Java c'est un tir dans son propre pied. Je comprends les raisons : Sun a fait l'erreur de ne pas libérer son implémentation avant ce qui a complètement tué l'engouement pour la VM. Et le langage Java n'est pas sexy du tout, donc ça ne motive pas les libristes qui codent en bonne partie pour le fun. D'un autre côté,certaines communautés n'ont pas de problème avec le monde Java (notamment Apache).

Le problème, c'est qu'il n'y a rien en face :

Le C ? Oui, il est toujours là, il est performant mais le temps de développement est décuplé comparé à un langage de haut niveau (je parle pas particulièrement de Java). Alors il y aura bien un très bon développeur C qui me lira et qui pensera qu'il peut programmer ce qu'il veut super vite, je lui affirme qu'il développerait encore plus vite dans un langage next-gen.

Le C++ ? Un monstre à 18 têtes, toujours là aussi, mais les programmeurs C++ se rendent compte de la perte de vitesse du langage : moins de libs maintenues, la nécessité d'utiliser des libs C et soit de les appeler "low-level" soit de faire leurs wrappers. Et (consultez Google si vous ne me croyez pas), C++ compilé avec gcc n'est que modérément plus rapide que du Java HotSpot. Parfois, Java est plus rapide. Mais c'est normal, avec la compilation JIT, votre code Java aussi tourne nativement.... (ceci n'est pas vrai si vous codez en C++ comme en C, avec des optimisations en assembleur, etc. Aussi, les templates sont moins couteuses en C++, mais aussi moins bien conçues).

Le Python ? Le langage est sympa, et il y a une véritable communauté de développeurs Python dans le monde libre. C pour la perf, Python pour l'UI / le développement rapide. Malheureusement, il faut écrire des bindings explicites pour lier les deux -- même si c'est fait automatiquement avec de nombreux outils qui marchent plutôt bien je dois l'avouer, mais c'est pas *pratique*. En plus l'interpréteur Python est vraiment lent. Si on fait son Python dans Jython (qui a un peu de retard malheureusement), on accède immédiatement à une immense bibliothèque standard supplémentaire, celle de Java, et des milliers de bibliothèques alternatives, notamment tout ce qui est Apache, Eclipse, Spring...

Le Ruby ? Même chose que Python, en plus lent et plus haut-niveau. Il existe JRuby.


Le problème principal, c'est que les langages haut niveau permettent d'écrire des bibliothèques/frameworks de façon plus maintenable (par exemple Plone) et plus intéressante qu'en C, mais que dans ce cas, les développeurs ne veulent pas faire des bindings high-level -> C pour ne pas avoir de dépendance sur un interpréteur (compréhensible mais pète-couille). On se retrouve donc bloqué sur un langage pour un framework.

Chez la concurrence, il y a .NET. C'est Managed C++, C# (Java, le langage, en mieux), ASP.NET (PHP en mieux), VB.NET (la première dose est gratuite), IronPython, F#.NET (OCaml)... Et l'avantage de ces environnements, immense en pratique, c'est l'intérop complète et automatique de tout ce qui est défini dans un langage, dans tous les autres. Il n'est besoin de définir une fonctionnalité qu'une fois. Il n'existe qu'une seule bibliothèque standard. Le langage utilisé dépend des goûts du développeur et de la tâche à effectuer, pas de l'existence de bindings, de la performance de la VM (même si les différents langages ont différentes performances), etc. Evidemment il existe toujours des wrappers pour rendre le style de programmation plus cohérent avec le langage host, mais c'est un problème moindre. À ça, on ajoute des environnements de développement rapide bien plus complets puisqu'ils gèrent un ensemble uniforme et compatible.

Le libriste anti-Java créée un rift entre le confort de développement GNU/Linux (multi-plateforme en fait) et Windows. Et pour faire venir de nouveaux développeurs, pour avoir des jeux par exemple, il faut un environnement de développement sexy.

À vrai dire, les distributions GNU sont plutôt sexy niveau environnement de développement, on a beaucoup d'outils libres et faciles à obtenir. Le toolchain est intéressant pour beaucoup de choses. Mais l'esprit trollesque anti-Java qui reste présent (pas que dans les communautés francophones) dessert la communauté.

Que faire ?
* Continuer comme aujourd'hui, avec des langages indépendants qui ont chacun leur ABI et qui ont besoin de bindings lourds à mettre en place ; avec des solutions pas toutes performantes et surtout, le lockin : un framework = un langage

* Passer sur un runtime/VM générique....
** Utiliser la JVM (projet JCR Da Vinci pour rendre la JVM plus générique) et profiter de nouveaux frameworks, langages, améliorer l'intégration avec les utilitaires usuels sous GNU/Linux (meilleurs bindings GNOME / GTK, etc)

** Passer à .NET avec Mono et être à la botte d'un environnement créé par une société qui, à travers ses actions passées, a montré qu'elle ne veut pas partager et qu'elle ne désire que Windows comme système, que ce soit sur les bureaux ou dans les racks.


Dans la pratique, .NET a des avantages sur Java, car il a été prévu directement pour être un environnement générique. Java essaie de rattraper le retard, et la stratégie d'Oracle/Sun est incertaine. D'un autre côté on a pas de doutes sur l'objectif final de Microsoft :)


Programmer sur la JVM, ça ne veut pas dire programmer en Java tout pourri.

Il y a Scala, un langage fonctionnel objet fortement typé très novateur qui rencontre un succès phénoménal. Il a les mêmes performances que Java (si vous suivez, ça veut dire qu'il est performant), et le feeling de Ruby !

Il y a Clojure, un autre langage fonctionnel dyamiquement typé, un Lisp-1, conçu directement pour la JVM qui rencontre aussi beaucoup de succès parmi les fans de Lisp, et les autres. Très performant pour un langage dynamique.

Il y a Groovy, plutôt lent, un langage objet dynamiquement typé, inspiré de Ruby mais directement conçu pour la JVM.

Et enfin il y a Jython et JRuby, les ports, plus performants que les originaux de Python et Ruby. Pas de risque d'être dépaysé.



Il est temps d'euthanasier le troll Java qui sommeille en vous.