On y trouve bien sûr des questions générale, du type "Comment vivez-vous la présente situation économique ?" ou encore "Comment se fait-on embaucher chez vous ?", sans oublier bien sûr "le passage de QT en GPL vous fait-il perdre de l'argent ?" :-) Mais aussi un certain nombre de question techniques "QT vs Java/MFC/GTK", "qu'y aura-t-il dans QT 4 ?", etc...
Bref, ca vaut le coup d'oeil.
Aller plus loin
- L'interview (4 clics)
# COmment vous comprenez ca ?
Posté par LAurent ROUX . Évalué à 3.
Doit-on comprendre qu'ils avaient peur que quelqu'un fasse mieux qu'eux et s'approprie le produit? ET donc depuis l'interview ils ont compris l'interet du systeme ?
CA sent l'interview à moitié forcée je trouve...
---------
Un jour, Bill Gates prit son PC, et alla lire un peu les newsgroups. Et le pauvre, il constata qu'il n'avait pas trop la cote.
Alors il convoqua tous les journalistes des USA, d'Europe et d'Asie dans sa maison près du lac Machin.
Il attend que tout le monde ait préparé ses Canon EOS 1 et ses Nikon F5, et puis là, sûr de son effet, il traverse le lac en marchant sur l'eau!!!
Le lendemain, dans tous les newsgroups, on pouvait lire:
"Et en plus, il sait même pas nager"
[^] # Re: COmment vous comprenez ca ?
Posté par lorill (site web personnel) . Évalué à 2.
Je pense.
ET donc depuis l'interview ils ont compris l'interet du systeme ?
Ca par contre, je vois pas d'ou tu sors ca. Ils avaient peur d'un fork sauvage, et quand ils ont eu assez d'avance, ils l'ont mis en GPL sachant qu'un concurent le reprenant aurait trop de retard a rattraper.
Enfin, c'est comme ca que je l'ai compris.
[^] # Re: COmment vous comprenez ca ?
Posté par Emmanuel Blindauer (site web personnel) . Évalué à 2.
d'un autre coté, ils auraient pu reprendre le fork dans leur sources, puisque GPL implique de refiler les sources si motifs.
[^] # Re: COmment vous comprenez ca ?
Posté par boubou (site web personnel) . Évalué à 10.
Pour prendre un exemple dans l'autre sens, que penser de l'attitude de RedHat avec postgesql. Ils reprennent la bête et la vendent sous un autre nom. C'est quand même fort, dans le genre...
[^] # Re: COmment vous comprenez ca ?
Posté par Jean-Marc Chapuzot . Évalué à -2.
[^] # Re: COmment vous comprenez ca ?
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: COmment vous comprenez ca ?
Posté par Olivier CIRET . Évalué à 6.
La question n'est pas de savoir si c'est grâce à qt qu'il y a KDE ou vice versa. Je pense qu'ils sont maintenant très liés et indissociable. Il va de même avec GTK et Gimp. Ils font partis des couples celebres du monde GNU.
[^] # Re: COmment vous comprenez ca ?
Posté par Eric Leblond (site web personnel) . Évalué à 10.
[^] # Re: COmment vous comprenez ca ?
Posté par Anonyme . Évalué à -3.
[^] # Re: COmment vous comprenez ca ?
Posté par Anonyme . Évalué à 2.
Ce qui est trop fort, c'est que lorsque quelqu'un raconte une connerie sur internet, seule la connerie est retenue et on la retrouve dans d'autres discussions.
RedHat ne vend pas postgreSQL sous un autre nom, RedHat vend une boite comprennant PostgreSQL portant un autre nom.
Les urls et le reste : ce cher boubou recherchera dans les archives la discussion de laquelle il a tiré son propos.
[^] # Re: COmment vous comprenez ca ?
Posté par boubou (site web personnel) . Évalué à 1.
Pour mémoire, la press release (http://www.businesswire.com/cgi-bin/f_headline.cgi?bw.081301/212252(...) ) qui annonçait "Red Hat E-Commerce Suite" parle de "Red Hat Database, an open source database solution based on PostgreSQL 7.1 and optimized for Web applications and Red Hat Linux 7.1". Je trouve ça un peu limite. J'aimerais bien savoir combien de lignes de code RedHat a contribué à PostgreSQL. Immagine que je distribue un rpm de PostgreSQL appelé Boubou Database, based on PostgreSQL 7.1, tu dirais quoi ?
Franchement, je n'ai rien contre Red Hat. Je trouve qu'ils ont fait de bonnes choses pour Linux (oups, GNU/Linux). Je trouve simplement qu'ils sont un peu à la limite sur ce coup là.
[^] # Aucun rapport...
Posté par Jak . Évalué à -5.
et hop -> -27, mais j'ai que ça à foutre :)
[^] # Re: Aucun rapport...
Posté par kadreg . Évalué à -5.
C'est vrai, c'est sympa, mais un peu long, le premier coups, j'ai trouvé le commentaire hors sujet jusqu'au moment ou j'ai vu que je lisais la signature :)
et hop -> -27, mais j'ai que ça à foutre :)
battu, -42
[^] # Re: Aucun rapport...
Posté par LAurent ROUX . Évalué à -2.
[^] # Re: COmment vous comprenez ca ?
Posté par Philippe F (site web personnel) . Évalué à 10.
> hostile fork of Qt and, in a sense, take over our only product"
>
> Doit-on comprendre qu'ils avaient peur que quelqu'un fasse mieux qu'eux et s'approprie le
> produit?
Ils avaient peur que quelqu'un s'approprie le produit oui. Je peux meme te citer un nom: RedHat.
Mais RedHat est parti pour Gtk. Harmony n'a jamais decolle. A partir de Qt2, ils n'ont pas arrete de progresser et il est devenu clair que personne ne maitriserait Qt mieux qu'eux. Donc ils sont passes a la GPL.
En revanche, je ne pense pas qu'ils aient jamais eu peur que quelqu'un fasse un meilleur Qt que le leur. Ils sont trop forts. Quand Eirik dit qu'il prend uniquement les meilleurs, il dit vrai.
Rappelons que meme sans etre GPL, Qt respectait deja les trois libertes du logiciel que garantit par la GPL. Donc la GPL, ca n'a ete que politique. Ce n'est pas l'interview (qui date d'un mois alors que Qt est en GPL depuis plus d'un an) qui y a change qqch.
[^] # Re: COmment vous comprenez ca ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Voir par exemple http://www.fsfeurope.org/documents/freesoftware.fr.html(...)
liberté 0 : La liberté d'exécuter le logiciel, pour n'importe quel usage.
liberté 1 : La liberté d'étudier le fonctionnement d'un programme et de l'adapter à vos besoins.
liberté 2 : La liberté de redistribuer des copies.
liberté 3 : La liberté d'améliorer le programme et de rendre publiques vos modifications afin que l'ensemble de la communauté en bénéficie.
[^] # Re: COmment vous comprenez ca ?
Posté par Jiquem . Évalué à -4.
[^] # Re: COmment vous comprenez ca ?
Posté par Anonyme . Évalué à -1.
linuxfrphoto.org
# 2 news de suite
Posté par Philippe F (site web personnel) . Évalué à -10.
# N'importe quoi l'argument sur Java !!!!!! Et voici la preuve :
Posté par Anonyme . Évalué à -4.
>Java: Given the nature of Java, it can't run >natively on any given platform. There are speed >and memory issues associated with Java that Qt >does not have.
Il a vu ca ou ? dans une blague carembar ?
On prend les choses dans l'ordre:
> it can't run natively on any given platform
Non serieusement, je croit qu'il en ait encore resté à de l'AWT et encore :o)
Utilisant des application swings tout les jours ecrites avec un outil type Jext/JBuilder/Netbeans, je peux vous dire que :
Oui, les swings sont bien multi-plateforme et il fonctionnent partout ou il y a une VM Java2 (du moment qu'on a un display !!! sic.) mais surtout il sont pratique (modele MVC) super strucuturés et ultra personalisables (cf. Renderers, Editors, Views, ...)
Linux, Windows, MacOS, Solaris, HP-UX, OS/400, iPaQ ....
>There are speed and memory issues associated with Java
Donc la c'est clair, il ne connait de java que ce qu'il a put lire dans des articles il y a 4ans et que certains magazines d'info continue à copier coller ....
Pour mettre les choses à plat:
J'ai Java2SE sur mon iPaQ 32MO et non seulement ca boooooooste (en plus d'etre stable) mais surtout c'est du vrai pur swing !!! et ca pompe pas des tonnes de memoire !!!
(Ce qui bouffe des MO en swing c'est les doubles buffers d'ecrans ... mais ca peut etre totalement controlé : une propriété a desactivé dans les composants !!!)
Que celui qui a deja fait du swing et vu tourné J2SE avec des swings sur un iPAQ sous SavaJE XE ou PocketLinux+J2SE me jette la premiere pierre ;-)
Vraiment Swing est l'un des meilleurs trucs qui soit arrivé dans le monde libre ... et je suis attéré de voire des posts peu argumentés completement faux, tout ca pour essayer de justifier l'exitense d'une librairie graphique dépassée et un langage de prog archaique.
(ca c'etait un peu de demago ... mais ca fait du bien ... non mais !)
Vive Tux, Vive Duke :o)
4R34'.
[^] # Re: N'importe quoi l'argument sur Java !!!!!! Et voici la preuve :
Posté par boubou (site web personnel) . Évalué à 7.
- "run natively" ça veut dire compilé, pas interprété. Tu peux raconter tout ce que tu veux sur le JIT, etc. il n'empêche que swing ça rame (vu le nombre couches, c'est pas étonnant). Qt est compilé... Pour le reste sur swing, on est d'accord, c'est sûrement la plus belle bibliothèque de fenêtrage actuelle. Mais bon, ça rame...
- "There are speed and memory issues associated with Java"
Sur le fond, il a raison. Quand tu démarres une JVM, c'est obligatoirement gros actuellement (genre une dizaine de mo). Quand tu crèes un objet, ça prend plein de place mémoire (de l'ordre de 16 octets par objet vide avec le jdk 1.3 de sun sous linux), etc. Si tu codes comme en C, avec une bonne JVM, ça va presque aussi vite que du C, parfois plus vite. Par contre, dès que tu codes vraimebt objet, C++ reste meilleur sur de nombreux points, par exemple parce que l'overhead mémoire est plus faible et parce qu'on peut passer les objets par valeur, et qu'on peut inliner les méthodes.
- swing n'est pas libre, bordel !!!!!!!!!
[^] # Emmm qqe correctifs :
Posté par Anonyme . Évalué à -2.
Qu'est ce qui rame ... donne des exemples ...
avec quoi comme VM, comme comme parametre de GC (mode incremental, clean/mark/sweep)....
Si t'as un iPAQ sous la main, met SavaJeXE et je n'aurais pas besoins de te convaincre ....
L'un des PB de Swing etait la conso memoire mais avec la 1.4 il va directement pioché dans la memoire de la carte video et evite ainsi les Offlay Buffer qui ralentissent et bouffent de la meme pour rien.
Enfin, Swing utilise Java2D qui utilise les appels directs au systeme lorsqu'il sont dispo (par exemple DirectDraw sous WinXX), pour Linux je me souvient plus si il utilise DRI ou pas ...
>c'est obligatoirement gros actuellement
Alors explique mois comment tu fait tenir ca sur un iPaq 32Mo ????? si t'as deja 10Mo de VM et 10Mo de softs et 15 appli qui tournent en permanence (c'est mon cas!!!)...
Oui, swing a eut des PB de perfs et Oui il sont corrigés !!!
Re: N'importe quoi l'argument sur Java !!!!!! Et voici la preuve : (Score: 1/#0) - Lundi 24 Septembre à 18:29
Ajouté par boubou ( #97 / 137 XP )
Il faut apprendre à lire.
- "run natively" ça veut dire compilé, pas interprété. Tu peux raconter tout ce que tu veux sur le JIT, etc. il n'empêche que swing ça rame (vu le nombre couches, c'est pas étonnant). Qt est compilé... Pour le reste sur swing, on est d'accord, c'est sûrement la plus belle bibliothèque de fenêtrage actuelle. Mais bon, ça rame...
>- "There are speed and memory issues associated with Java"
Sur le fond, il a raison. Quand tu démarres une JVM, c'est obligatoirement gros actuellement (genre une dizaine de mo). Quand tu crèes un objet, ça prend plein de place mémoire (de l'ordre de 16 octets par objet vide avec le jdk 1.3 de sun sous linux), etc. Si tu codes comme en C, avec une bonne JVM, ça va presque aussi vite que du C, parfois plus vite. Par contre, dès que tu codes vraimebt objet, C++ reste meilleur sur de nombreux points, par exemple parce que l'overhead mémoire est plus faible et parce qu'on peut passer les objets par valeur, et qu'on peut inliner les méthodes.
>- swing n'est pas libre, bordel !!!!!!!!!
Swing est en comunity source, t'as tout le source code et tu peux deriver le code comme tu veux mais tu n'as pas le droit d'ecrire un librairie qui porte le meme nom ... je trouve ca plutot sympas car ca evite de se faire exploser la compatibilité binaire de ces appli pour un oui ou pour un non (ca te rappelle rien ...?!?)
Il existe de nombreux projets qui ecrivent des outils utilisant swing et qui sont en opensource : Jext/Jedit/Netbeans/ .... et cela ne semble gener personne sauf les puristes et autre guru de la GPL :o)
Et d'autre part si un Jour Sun nous prend la tete, rien n'interdit de reecrire exactemet la meme biblio (meme noms de package) et cela en GPL ou BSD ;-)
Comme le fait deja le projet ClassPath de la GNU pour toute les fondations de Java !
Donc no stress ...
Enfin concernant ton argument memoire, je sui d'accord que si tu veux optimizer a fond le C c'est mieux mais j'ajouterais l'assembleur est encore mieux ... c'est une question de choix !
Java est 40% plus productif que le C++ et c'est un FAIT que tout les DP qui on mené des projets C++ et Java pouront te confirmer !
C'est pas une paille tout de meme 40%...
Une derniere remarque sur la memoire, les JIT de 2eme generations sont capable d'inliner avec un niveau de profondeur illimité et conditionel dynamiquement (càd qu'il est déterminé à la phase d'optimization). Enfin, l'utilisation de references dans un prog strucurellement complexe produit un effet bennefique sur la memoire utilisée et sur l'ensemble des perfs globales (tri, recherche, comparaisons d'objets ....)
Maintenant si tu trouve que certains points dans java ont besoin d'amelioration, libre a toi de patcher le code source de la VM et d'envoyer tes patchs à Sun (regarde dans les sources de la VM de Sun tu y trouveras deja un certains nombres qui l'ont fait!!!) ou de demander un JSR http://www.jcp.org(...) pour demander un evolution plus majeure ...
Bye a toi et bon tux ;-)
[^] # Re: Emmm qqe correctifs :
Posté par Guillaume Laurent (site web personnel) . Évalué à 6.
Avec Qt ça ne rame pas, et je n'ai pas besoin de config speciale pour obtenir ce résultat. Si pour obtenir des perfs sur un langage tu es obligé de faire ce genre d'acrobaties, c'est que le langage n'est pas encore au point pour le boulot que tu lui fais faire.
> Et d'autre part si un Jour Sun nous prend la tete, rien n'interdit de reecrire exactemet la meme biblio
Ben voyons, ça sera surement très facile, c'est tout petit Swing, et puis ils ne vont rien faire pour nous en empécher, hein.
> Java est 40% plus productif que le C++
Tout le monde sait ça, encore qu'il serait interessant de refaire la même stat par rapport à Qt et non C++ en général.
Ceci dit, c'est pas pour rien si le marché de prédilection de Java est plutôt du coté serveur :-).
> Maintenant si tu trouve que certains points dans java ont besoin d'amelioration, libre a toi de patcher le code source de la VM et d'envoyer tes patchs à Sun
Oh ben oui tiens, ça aussi ça doit être facile.
> ou de demander un JSR www.jcp.org pour demander un evolution plus majeure ...
Bon sang mais c'est bien sur, pourquoi n'y avons nous pas pensé plutôt. :-)
[^] # Re: Emmm qqe correctifs :
Posté par Anonyme . Évalué à 2.
Juste d'un P4 ou d'un ATHLON ;-)
(desolé mais elle etait facile celle la ... vive GTK ! oups le troll ... aie... )
>c'est que le langage n'est pas encore au point
Et aller ... je me disait bien ... le "langage pas encore au point" .... je sais pas si t'es au courrant mais le langage on s'en fout un peu ... c'est la plateforme qui est importante.
Je t'en veux pas car 50% des personnes qui sont "contre java" n'ont en general pas depassé le niveau des concepts du langage,
sache que tout de meme en Java on peut ecrire avec une floppé de langages divers et qui produisent tous de bytecode faut arreter de lire les pipotages de bilou ...
>prédilection de Java est plutôt du coté serveur :-).
Tout a fait, mais l'une des principale raisons est tout autre : jusqu'a present installer une appli Java cliente c'etait le mal de tete assuré ...et les applets c'etait du JDK1.1 (merci à MS et Netscape pour leur manque de support ...)
Hors, 2 changement importants ont eut lieu :
#1 MS a annoncé l'arret de sa VM 1.1 et Sun le support direct des applets par ses VM 1.3. dans IE. Opera inclut Java2 en standard, Netscape6 aussi (version complete) ...
#2 JNLP (aka JavaWebStart) est sur le point de completement changer la donne (et c'est pas grace à sun qui ne communique pas sur cette spec) ... l'idée de JNLP c'est de créer un descripteur de deploiement d'applications avec des fonctionalités avancées (update automatique et incrementale, ouverture et sauvegarde de ficher en local assistée par l'utilisateur sans besoin de certificat, etc ...)
La liste des appli compatibles JNLP s'allonge assez rapidement et ceci alors meme que MacOSX 10.1 sort compatible d'office JNLP (sans le dire a personne d'ailleur) et que SavaJE XE (l'OS J2SE pour iPAQ et NetBook) est aussi compatible JNLP !!!
Imagines la scene, tu est sous netbeans, deploie ton appli en JNLP en qqe clics et tape l'URL sur ton browser iPaq et voila ! ton appli tourne :)
Mais surtout booooste ;)
Ca c'est pas du vrituel c'est ce que l'on peut faire des maintenant ... et crois moi les possibilités offertes sont vraiment interessantes !
dessus
> ...Oh ben oui tiens, ça aussi ça doit être facile.
Parce que tu crois que patcher la lib de Qt pour corriger un bug c'est facile ;-) euh ... la je crois que : joker :o)
>Bon sang mais c'est bien sur, pourquoi n'y avons nous pas pensé plutôt. :-)
Ben si tu crois encore que java n'est qu'un langage, de plus hyper lent et qui sert à rien d'autre qu'a faire plaisir à des techos de bas etages pas capable d'ecrire une ligne de bon vieux KR-C ou d'ASMx86 alors je crois que j'ai ma reponse :o)
Non je te charie ... c'est clair que c'es pas si simple, car le processus JCP est assez long (cela depend du type de modif demandé), mais l'avantage c'est que les elus (tu peux te presenté à l'election si tu le desirent... je sais plus quand est la prochaine ...) eux peuvent faire avancer les specs ...
Le dernier exemple en marche : JNLP qui n'a clairement pas été poussée par Sun mais par les membres du JSR :o)
Un autre exemple les java.nio (Non-blocking IO) qui permettent d'avoir des performances vraiment interessantes sur les IO...
Et enfin, la fameuse Genericité que meme le pere de Java refusait ... et bien la JSR l'a adopté et l'intégration dans le langage est en cours et la sortie est pour le 1.5 :)
Comme quoi ... il faut tjr tenter!!
@+
4R34'.
[^] # Re: Emmm qqe correctifs :
Posté par Guillaume Laurent (site web personnel) . Évalué à 9.
Non, P90 avec 32Mb de RAM, sous Win98 en plus. C'est du vécu, j'ai fait tourner une GUI au dessus d'une DB Oracle qui se constituait à partir d'un fichier de description en XML. Il est actuellement impossible d'en faire autant en Java, même si j'aurai préféré utiliser JDBC pour développer ce truc.
> je sais pas si t'es au courrant mais le langage on s'en fout un peu
Ah, bon, excuse-moi, tu sembles être beaucoup plus au courant que moi de la chose.
> c'est la plateforme qui est importante
Oh, me voilà renseigné alors.
> sache que tout de meme en Java on peut ecrire avec une floppé de langages divers et qui produisent tous de bytecode
Bien. J'ai un pote qui travaille chez BEA, un autre chez IBM, un au W3C, un qui s'occupe de SVG, et je bosse pour une boite qui fait des composants Java depuis 97. C'est curieux, mais à part jython dont on a vaguement parlé mais qu'ils n'ont jamais utilisé dans le cadre professionel, ils programment tous en Java, et ils surveillent de prêt l'évolution du langage lui-même.
La "plateforme Java", c'est tout ce qui s'est construit au dessus : JDBC, JEE, etc... (je m'y perds dans tout ces acronymes). Les langages qui compilent vers du byte-code Java n'ont pour le moment aucune existence dans l'industrie.
> Je t'en veux pas car 50% des personnes qui sont "contre java"
Mais qu'est-ce qui te fais croire que je suis "contre Java" ?? Je suis pour, vivement que ça marche sur le desktop. J'ai juste un peu plus que toi la tête sur les épaules.
> >prédilection de Java est plutôt du coté serveur :-).
> Tout a fait, mais l'une des principale raisons est tout autre : jusqu'a present installer une appli Java cliente c'etait le mal de tete assuré
Non, rien à voir. Pour un serveur les perfs sont moins importantes que sur le desktop, parce qu'il suffit de prendre une machine plus grosse pour les augmenter, ou d'en mettre en parallèle, ce que Java sait bien gérer. C'est un coup fixe, connu, alors que celui de debugger un serveur écrit en C ou C++ ne l'est pas. Mais tu ne peux pas faire ça pour une appli desktop, upgrader 1 machine ça passe, 150 non.
Ensuite l'autre raison c'est que décompiler une appli Java est trivial, et pour faire une appli commerciale avec du bon vieux code proprietaire qui va vérifier sa licence au lancement, ça craint. Tu peux toujours utiliser un offuscateur de code, mais ça complique pas mal le développement parce que ça apporte son lot de problèmes. J'en sais quelque chose, le chef d'équipe dans le bureau à coté du mien en a régulièrement.
> Parce que tu crois que patcher la lib de Qt pour corriger un bug c'est facile
Toujours plus facile qu'une JVM. C'est pas la même complexité.
> Ben si tu crois encore que java n'est qu'un langage, de plus hyper lent et qui sert à rien d'autre qu'a faire plaisir à des techos de bas etages pas capable d'ecrire une ligne de bon vieux KR-C ou d'ASMx86 alors je crois que j'ai ma reponse
Relis ce que tu as dit : si je trouve que Java a besoin d'être amélioré, y a qu'a logger une JSR. Cool. C'est comme si je te disais que si C++ ne te plait pas, tu n'as qu'a ouvrir un defect au C++ committee. Et strictement parlant c'est vrai, la spec C++ est ouverte aussi (même plus). Le pb c'est que c'est une procédure qui prend des années, et reservée à un petit nombre de gens qui ont du temps à y consacrer.
Qu'est-ce que je dois mettre dans ma JSR pour dire "je veux de meilleures perfs" ?
Et pour info, non, je ne considère pas que Java soit un language hyper-lent, etc... Sors toi de tes clichés.
> c'est clair que c'es pas si simple
Content que tu t'en rendes compte.
> mais l'avantage c'est que les elus (tu peux te presenté à l'election si tu le desirent... je sais plus quand est la prochaine ...) eux peuvent faire avancer les specs ...
Les utilisateurs font aussi avancer Qt sinon la librairie n'aurais pas la qualité qu'elle a actuellement. Qt est plein de patches de gens externes à TT, souvent revus par TT pour s'assurer de la qualité. Par exemple le support des fonts antialiasés ne vient pas d'eux au départ.
> Et enfin, la fameuse Genericité que meme le pere de Java refusait ... et bien la JSR l'a adopté et l'intégration dans le langage est en cours et la sortie est pour le 1.5
Je sais, mais il semble que l'implémentation ne soit pas si géniale :
http://www.beust.com/cedric/javaone-2001.html(...)
Ils n'ont fait que rajouter un typage plus fort mais sans supprimer la nécéssité de downcaster.
Par contre Gosling parlait d'ajouter l'overloading d'operateur il y a longtemps
http://java.sun.com/people/jag/FP.html#overloading(...)
on dirait que c'est enterré, dommage.
[^] # Re: Emmm qqe correctifs :
Posté par boubou (site web personnel) . Évalué à 4.
Surtout quand elles sont suivies d'une confusion totale entre la machine virtuelle Java et le langage Java. Tout le monde sait, cher posteur, que de très nombreux langages peuvent être compilés en byte-code de la JVM. Il y a même un site consacré à ça http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html(...)
Mais bon, quel rapport avec bilou et en quoi ce fait apporte-t-il quelque chose à la discussion sur les performances de Java ?
Rajoutons maintenant une couche sur le reste (le post de guillaume est pas mal du tout, mais bon).
Ton argument sur le serveur est complètement débile. Outre les avantages cités par Guillaume, il y a aussi le fait que JIT est particulièrement bien adapté à un programme serveur qui tourne des jours et des jours sans s'arrêter. L'asect très dynamique de Java (chargement au vol d'une nouvelle version d'une classe + JIT) étend encore les possibilités côté serveur. Bref, aucun rapport avec la facilité d'installation d'une JVM (un clic sous windows, un tar ou rpm sous linux).
Pour l'histoire de la généricité, effectivemment, ça fera partie de Java (dans le futur), mais malgré certains avantages par rapport au C++ (polymorphisme contraint), il reste un fait puant : on ne pourra pas utiliser le polymorphisme pour les types fondamentaux. Le plus dingue dans cette histoire, c'est que pizza (http://pizzacompiler.sourceforge.net/(...) ) implante la généricité en Java depuis des années, de même que GJ (http://lampwww.epfl.ch/pizza/gj/(...) ), qui a d'ailleurs servi de base à la proposition qui sera intégrée dans 1.5. Tu te rends compte qu'il y avait une implantation de ces concepts dès 1996 et qu'il faudra attendre 6 ans avant que ça marche ! Franchement, si tu appelles ça de la réactivité...
Comme le disais Guillaume, il manque de plus d'autres choses en Java, comme :
- la surcharge d'opérateur
- l'héritage multiple (si tu viens me chercher avec les interfaces, tu te prends une claque)
- les classes à sémantique valeur (en plus des classes à sémantique référence)
- etc, je suppose.
[^] # Re: Emmm qqe correctifs :
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
> il manque de plus d'autres choses en Java, comme :
> - la surcharge d'opérateur
> - l'héritage multiple (si tu viens me chercher avec les interfaces, tu te prends une claque)
> - les classes à sémantique valeur (en plus des classes à sémantique référence)
Oui mais parti comme ça on refait C++ :-).
Même si sur le principe je suis d'accord, je ne suis pas du tout sur que le prix à payer en ajout de complexité du langage vale le coup (et dans le genre tu as vraiment cité les pires :-).
Et puis sur un plan purement pratique, rajouter de telles fonctionalités vu l'étendue du code existant serait extrèmement difficile.
Je crois qu'il serait préférable de creer un nouveau langage. De ce point de vue là, C# est une bonne nouvelle.
[^] # Oups ... j'ai oublié des liens
Posté par Anonyme . Évalué à -1.
Un OS Java2SE 1.3 pour iPAQ et Netbook (pas gratos)
http://www.savaje.com(...)
PERC Java (une VM J2SE temps réel)
http://www.newmonics.com/(...)
PocketLinux et outils pour virer WinCE :o)
http://www.pocketlinux.com(...)
http://www.handhelds.org(...)
J2SE 1.3.1 pour iPAQ PocketLinux ARM
http://www.blackdown.org(...)
Il serait peut etre temps de refaire passer des articles sur Java pour dire STOP au post du style "Java est lent" ou "Java est un langage moyen" ... un peu d'explication claires et precises et surtout des DEMOS remettrait clairement les choses à leur places ...
Si vous avez un iPAQ je vous engage fortement à tester la beta2 de SavaJe (sortie de la 1.0 en octobre) vraiment c'est completement bluffant !!!!
(meme pour un habitué des trucs qui tuent ... alors :o) )
4R34'.
[^] # Re: N'importe quoi l'argument sur Java !!!!!! Et voici la preuve :
Posté par Tal . Évalué à 2.
Le mot important ici, c'est "natively" : Java est généralement (semi) interprété. C'est un avantage en terme de portabilité, mais ça entraîne une partie des "speed and memory issues" dont il parle.
Ceci dit, il existe des compilateurs Java qui produisent du code natif pour la plupart des systèmes (enfin je crois). Je ne les jamais testés, je ne sais pas ce qu'ils valent. J'avais cru comprendre que l'utilisation de ces compilos empêche d'utiliser la plupart des biblios de java (comme swing, mais c'est probablement temporaire, le temps qu'elle soient adaptées/compilées), quelqu'un peut confirmer?
De plus, j'ai bien peur que Swing (et java aussi d'ailleurs) ne soit pas libre du tout.
Mais c'est vrai que swing est un trés bonne biblio, et que la vitesse est largement suffisante pour la plupart des utilisations.
[^] # Effectivement ...
Posté par Anonyme . Évalué à 3.
Le principal est actuellement de ne pas offrir plus de performance qu'un JIT de derniere generation.
Le gain est par contre interessant au niveau du temps de lancement car il n'y a pas les couches d'analyse du bytecode visant à la securité de la plateforme (entre autre le class verifier).
Ainsi, meme si l'avenir reste à des JIT-like, les prochaines generations s'inspireront certainement de fonctionalités de cache persistent d'optimization locales pour eviter le repassage du class verifier sur du code deja validé qqe temps avant :(
mais ca c'est quand meme super chaud a faire ... des volontaires pour plonger dans le code de HotSpot et tenter d'y introduire un mechanisme de cache contextuel ???
Bye...
4R34'.
[^] # Re: N'importe quoi l'argument sur Java !!!!!! Et voici la preuve :
Posté par Guillaume Laurent (site web personnel) . Évalué à 5.
Il ne dit pas le contraire. Il dit que Java ne peut pas tourner en natif sur toutes les plateformes. Ce qui est vrai, puisque Java tourne sur une JVM, comme tu le soulignes toi-même.
> Donc la c'est clair, il ne connait de java que ce qu'il a put lire dans des articles il y a 4ans
J'ai testé récemment le JDK 1.3 sous Linux, et malgrè les immenses progrès fait depuis le 1.2 sur la vitesse d'affichage, c'est toujours très lent par rapport à Qt. Quand à l'occupation mémoire, je n'ai pas vraiment vu de progrès, c'est toujours dans les 30 ou 40Mo pour une simple appli de demo.
> et je suis attéré de voire des posts peu argumentés completement faux
Son post est parfaitement argumenté et tout à fait exact.
> tout ca pour essayer de justifier l'exitense d'une librairie graphique dépassée et un langage de prog archaique
Quand on pourra programmer l'équivalent de KDE en Java, alors oui, C++ et Qt seront archaïques. En attendant, c'est ce qu'on a de mieux.
[^] # Troll qui roule ...
Posté par Anonyme . Évalué à 2.
Comme tu le dit toi meme, c'est le propre de java d'etre portable... donc c'est plutot stupide comme argument ;)
<blague>Autant dire que linux n'est pas bien car il n'est pas sous Windows </blague>
Ca n'a rien a voir avec la choucroute mais c'est fait pour ;-)
>JDK 1.3 sous Linux
De qui la distro? blackdown, sun, ou IBM ?
Il faut savoir qu'il y a une ennorme différence de perf et de memoire entre les différents ...
Sous mon tux j'ai celle de IBM pour le serveur-side et pour le client-side j'ai celle de Sun ...
>Quand on pourra programmer l'équivalent de KDE en Java, ..
Et bien donc Qt deja est archaique :
http://www.limewire.com(...)
http://www.thinkfree.com(...)
http://www.netbeans.org(...)
....(si t'en veut plus va sur google ou sur des sites d'applications JNLP )
Et je passe sur les jeux en Java2D et autres applis Swings.
J'aime bien faire courrir les trolls ;)
Plus serieusement, et de façon posée, au niveau composants graphiques, swing n'a rien a envier à QT non vraiment ... par contre au niveau prog, il est evident qu'il y a des choses qui sont toujours inimaginables de faire en Java.
Meme si le JDK 1.4 reduit cet espace en ajoutant (IPv6, ICMP, Direct DataBuffer, NonBlock IO, ...) il restera toujours des choses que seul le C fera comme il reste tjr des choses que seul l'assembleur fait et fera ...
Mais clairement, à mois d'utiliser l'exxcelent Kylix, la productivité pour la realisation d'une appli Qt est vraiment limité meme si elle s'ammeliore de plus en plus ya encore une différence considerable :(
(zut j'ai encore laché un troll ...desolé ! ... revient ... et petit revient ... petit ...!! )
4R43'.
[^] # Re: Troll qui roule ...
Posté par Tal . Évalué à 1.
> portable... donc c'est plutot stupide comme argument ;)
La question étant "quels sont les avantages de qt sur java", non, ce n'est pas stupide.
Si on te demande quels sont les avantages de java sur qt, tu répondra (entre autres) que les appli java peuvent tourner sur toutes les plates-formes sans êtrent recompilées, même si qt n'a jamais eu ce but, non?
Evidement, si c'est juste pour troller, hein...
[^] # Re: Troll qui roule ...
Posté par Anonyme . Évalué à 0.
[^] # Faut voir ...
Posté par Anonyme . Évalué à 2.
ClassPath http://www.gnu.org/software/classpath/classpath.html(...)
Kaffe http://www.transvirtual.com/kaffe-files.htm(...)
Et d'autre part celui qui regne sur le monde java c'est pas sun mais IBM (ya qu'a regarder dans les codes de la VM de sun ...)
Encore une fois il faut separer les specs de l'implementation, ce qui n'est pas libre d'utilisation dans Java c'est les implementations (celle de sun est dans une license batarde mi-opensource mi-closesource).
La aussi il y a eut beaucoup de troll principalement à cause de RMS qui est partit en croisade contre Java :(
Pour finir, si la license actuelle de l'implementation de Sun n'est pas reconnue comme Opensource c'est uniquement car la restriction de la JSCL impose avant toute modification de valider que la modif ne casse rien dans la compatibilité ascendante !
Ce qui me semble plutot censé non ?
Mais les guru de la openSourceInitiative n'en demorde pas : aucune clause de compatibilité ne peut etre tolérée dans une license opensource :(
Domage pourtant je trouve que ca va dans le bon sens ... celui du developpeur : arreter de tout le temps refaire la meme chose pour les memes resultats ...
Enfin ... peut-etre qu'ils changeront d'avis un de ces 4 ... revons ...
4R34'.
[^] # Re: Faut voir ...
Posté par boubou (site web personnel) . Évalué à 1.
Quant aux specs publiques, bof, bof. Je te rappelle que la certification ISO de Java a été interrompu par Sun, pour des raisons étranges. Pour l'instant, C++ comme d'autres langages (C, Ada, etc.) est basé sur une norme ce qui le rend beaucoup plus "libre" et publique que Java qui reste contrôlé par une seule entreprise (cf les histoires aux sujets de l'API de logging au sujet de laquelle une news était passée ici).
Petite note : je ne programme presque qu'en Java et je trouve le langage parmi les plus avancés actuellement. Ce n'est pas une raison pour être aveugle.
[^] # Re: Troll qui roule ...
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Faut-il vraiment t'expliquer le concept de "natif" ?
Le fait que Java tourne sur une JVM a aussi ses inconvénients, non seulement pour les perfs mais aussi pour l'intégration avec les applis natives. Par exemple si je démarre une demo Swing sur mon Linux, le cutn'paste ne marche pas dessus, ni la roulette de ma souris. Qt, ça marche.
> De qui la distro? blackdown, sun, ou IBM ?
Sun je crois. Et franchement je m'en fous, en tant que développeur, la dernière chose dont j'ai envie c'est de devoir perdre du temps à choisir une version bien specifique pour avoir des perfs correctes.
> Et bien donc Qt deja est archaique :
> [ des liens vers des applis ]
Bon, alors une fois que tu aura bien assimilé la notion de "natif" par opposition à "machine virtuelle", tu pourra passer à celle de "desktop" par opposition à celle d'"application".
Indice: un desktop lance des applications, gère leur intégration, l'environnement, etc...
> au niveau composants graphiques, swing n'a rien a envier à QT non vraiment
Je suis d'accord. Sauf pour les perfs, et l'intégration avec la plateforme native.
> il restera toujours des choses que seul le C fera
Il n'y a rien que tu puisse faire en C et que tu ne puisse pas faire en C++ :-).
> la productivité pour la realisation d'une appli Qt est vraiment limité
Quel genre d'appli as-tu fait sous Qt et combien de temps l'as-tu utilisé ?
[^] # Re: Troll qui roule ...
Posté par Anonyme . Évalué à 0.
[^] # Re: N'importe quoi l'argument sur Java !!!!!! Et voici la preuve :
Posté par Anonyme . Évalué à 0.
Ca c'est faux, meme si on manque d'implémentations de Java compilé.
[^] # Re: N'importe quoi l'argument sur Java !!!!!! Et voici la preuve :
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Donc, même si en théorie c'est faux, en pratique, c'est vrai.
[^] # Re: N'importe quoi l'argument sur Java !!!!!! Et voici la preuve :
Posté par MetalX . Évalué à 1.
[^] # Re: N'importe quoi l'argument sur Java !!!!!! Et voici la preuve :
Posté par Romain Guy . Évalué à 5.
S'il est vrai que depuis la version 1.2 les performances de Swing ont été grandement améliorées (peut-être est-ce grandement dû aux machines surpuissantes actuelles, même si je vénérais déjà Swing sur un P200 32 Mo), il faut bien avouer que Java ne peut-être utilisé en toutes circonstances.
Pour ma part, écrire un utilitaire en Java me semble une bonne idée dans la plupart des cas. Dans d'autres non. Quand à produire un équivalent de KDE, ce n'est pas demain la veille. Certains essayent mais ne produisent que de rudimentaires "desktops" inintéressants (ou presque).
En ce qui concerne le programmeur, oui Swing est une librairie fantastique. Quoique parfois trop "complexe". Qui n'a jamais plongé à des niveaux de prodondeur ahurissant des la hiérarchie objet de la documentation Swing ? La documentation d'une simple méthode conduit facilement à lire la documentation d'une dizaine d'objets. Mais cela reste logique, intelligent et intuitif (au pire lorsqu'on ne se souvient pas d'une fonction, on essaye un nom en rapport avec l'action souhaitée... ça marche assez souvent :-)).
Enfin voilà...
[^] # Ce qui explique mon post ...
Posté par Anonyme . Évalué à 0.
Ca m'atriste de voir tant d'articles incomplets et peu precis sur java, au mieux le traitant comme un simple nieme langage (et oubliant meme les concepts de la plateforme java) au pire un langage de script (et oui vous le saviez pas mais java c'est javascript pour environ 30% des non-utilisateurs de Java ... merci netscape pour le cadeau ...)
Et effectivement je me suis emporté sur ce point tout simplement car il a repondu de mauvaise fois : tout ce qui trouve comme argument sur java c'est que c'est pas du C !! (cf. pas du natif !)
Puisque tu connais java tu es conscient que la notion de natif est relatif ...
Est-ce que le bytecode n'est pas du natif pour un processeur utilisant de base le bytecode (cf les dernieres generation de StrongARM par exemple) ?
Est-ce que le fait que le x86 ne soit plus le code assembleur utilisé en interne sur les processur Intel PIII et surtout P4, permet encore d'appeler le code x86 de l'assembleur natif ?
Ainsi la notion de "code natif" est de plus en plus relative alors faire appel a ce point comme argument premier et principal est plutot surprenant voire derisoire.
Enfin une remarque : tu parle de desktop, mais Swing n'as pas la pretention de remplacer les windowmanagers et les desktop ... ca n'a tout simplement rien a voir avec les composants de bases qui permettent de construire une application.
Le desktop etant lui meme une application Qt (ou alors j'ai raté des lignes dans la doc ...).
Pour finir,le desktop manager et window manager de SavaJeXE est ecrit en Swing alors comme quoi ;-)
@+
4R34'.
[^] # Re: Ce qui explique mon post ...
Posté par Romain Guy . Évalué à 1.
Ah ça ne m'en parle pas. Je me suis engueulé avec RMS à propos de license GPL et Java :(
Puisque tu connais java tu es conscient que la notion de natif est relatif ...
Oui. Mais sur un OS classique, Java n'est pas "natif" au sens propre du terme. Mais c'est vrai que l'argument est moyen. Il n'y a qu'à voir Python. C'est extrêmement utilisé et pourtant... ce n'est pas "natif" non plus (ça compile aussi en bytecode on dirait).
Est-ce que le fait que le x86 ne soit plus le code assembleur utilisé en interne sur les processur Intel PIII et surtout P4, permet encore d'appeler le code x86 de l'assembleur natif ?
C'est vrai ?? Je ne savais pas ça ? Tu peux m'en dire plus ?
Enfin une remarque : tu parle de desktop, mais Swing n'as pas la pretention de remplacer les windowmanagers et les desktop ... ca n'a tout simplement rien a voir avec les composants de bases qui permettent de construire une application.
Le desktop etant lui meme une application Qt (ou alors j'ai raté des lignes dans la doc ...).
C'était pour répondre à un post disant que Swing ne pourra jamais faire un KDE. Evidemment, c'est possible en théorie, mais je ne sais pas si le résultat serait très viable. Ou alors il faudrait des excellents programmeurs (comme ceux de Netbeans ou... Swing :).
Pour finir,le desktop manager et window manager de SavaJeXE est ecrit en Swing alors comme quoi ;-)
Oui. Mais ce n'est pas aussi énorme que KDE :) Dans le même genre, j'ai programmé en Java sur Palm Pilot. Ben par rapport aux autres applications Palm, Java n'a vraiment pas à rougir; De toutes façons, l'attitude de bcp de gens empêche Java de monter sur le plan du desktop. Restent les serveurs (Java est super pour ça aussi !) et les embarqués.
[^] # Re: Ce qui explique mon post ...
Posté par Anonyme . Évalué à 0.
correction:
"Mais sur un OS classique, Java n'est pas "natif" actuellement au sens propre du terme"
Car gcj et autres compilateurs de Java en natif c'est pas encore ça. Mais dire que Java n'est pas natif est faux, c'est un langage, une plateforme, tout dépend de l'implémentation. D'ailleurs un langage natif, ça ne veut rien dire, l'adjectif concerne uniquement la compilation. On pourrait par exemple faire un compilateur de scripts shells pour faire des binaires !
[^] # Re: Ce qui explique mon post ...
Posté par Marc . Évalué à 1.
les processeurs CISC Intel transforment chaque instruction à exécuter en plusieurs micro-instructions (micro-codes). Puis en interne il exécute ce micro-code avec une architecture proche des RISC, je crois.
[^] # Re: Ce qui explique mon post ...
Posté par dguihal . Évalué à 2.
[^] # Tout à fait :o)
Posté par Anonyme . Évalué à 0.
yep :(
je crois que cela pose le probleme du compromit entre liberté du developeur et liberté de l'utilisateur : comment garantir une migration en douceur et une interroperabilité des softs a tout les coups sans precision de test de compatibilités dans sans rajouter de clause dans la license ...
Ce n'est pas demain que RMS et consors integreront ce parametre indispensable à la production d'un industrie du libre vers lequel on peut se tourner à 100% sans avoir de peur pour l'avenir :(
Qui n'as pas deja eut des impossibilité d'evol sous linux à cause d'une version requise de lib ?
>>...processur Intel PIII et surtout P4, permet encore d'appeler le code x86 de l'assembleur natif ?
>C'est vrai ?? Je ne savais pas ça ? Tu peux m'en dire plus ?
Pout le P4 je suis sur de mon coup, mais des specialistes processeurs t'en diront plus que moi (ya des explications de faites dans des reponses), pour le PIII il me semble qu'il y a deja une decomposition des instructions x86 en instructions internes plus primaires (type RISC), mais c'est le P4 qui a vraiment marqué la rupture avec le x86 en interne ... le but etait je crois de pouvoir d'optimiser les sutrcutres superscalaires.
>Oui. Mais ce n'est pas aussi énorme que KDE :)
Tout à fait, car n'est present que la librairie de composant "de base" et pas d'elements de pluts haut niveau ...
Pourtant l'arrivée de la 1.4 et la preferences API + JNLP ainsi que le differents fix (memoire directe + copier/coller qui marche !!! et DND Simple qui marche enfin en WORA ...) pourrait bien sonner le depart d'une nouvelle vague Java sur le client.
Non, pas une vague qui balayerais tout sur son passage mais plutot quelque chose de plus lent et de plus profond ... les elements incontournables de ces nouveaux besoins sont : ergonomie, qualité graphique, performance visuelle,...
Je reste persuadé que par exemple le pipeline Java2D est completement sous exploité (sauf par Karsten Lentzsch auteur entre autre de jDiskReport dans ces petites anims qui font merveille niveau visuel ).
Recement j'ai pas mal passé de temps sur SavaJe car un premier test effectué il y a qqe temps m'a purement "scotché" par les performances affichées tant au niveau 2D (pourtant le iPaq n'as pas de hardware acceléré) que dans la qualité de representation des swings.
Bien sur on ne peut pas presager de l'avenir de SavaJe qui va essentiellement dependre du bon vouloir des editeurs à le proposer en option et de la plateforme d'applications JNLP disponibles et adaptées pour l'affichage sur des ecran limités.
Pourtant il s'agit la d'une revolution qui marque un pas dans les developements embarqués : finit les prises de tête avec les UI MIDP (merci au designer du kit J2ME MIDP de JB5 au passage pour son designer MIDP), finit les difficultés de design sur personal Java ... On se retrouve sur du J2SE !
L'avenir dira la part que l'on peut accorder à un nouvel OS meme prometeur dans le paysage actuel ...
A+
:o)
4R34'.
[^] # Re: Tout à fait :o)
Posté par Romain Guy . Évalué à 1.
[^] # Re: Ce qui explique mon post ...
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Non, la cible de Java c'est Microsoft et rien d'autre.
> Ca m'atriste de voir tant d'articles incomplets et peu precis sur java
Oui mais là c'est une interview d'un mec qui s'occupe d'une toolkit C++. Donc il est assez normal que ça ne parle pas de Java in extenso.
> tout ce qui trouve comme argument sur java c'est que c'est pas du C !! (cf. pas du natif !)
Et alors ? On lui demande les avantages de Qt par rapport à Java, et c'en est clairement un. Qt tourne en natif sur les plateformes où il est porté, pas Java.
> Puisque tu connais java tu es conscient que la notion de natif est relatif ...
Non, les dizaines de megas bouffés par une JVM et le cut'n paste qui ne marche pas, pour moi ou pour un utilisateur de base, c'est pas relatif. C'est du concret.
> alors faire appel a ce point comme argument premier et principal est plutot surprenant voire derisoire.
Pour toi oui, pour beaucoup d'autres non.
> tu parle de desktop, mais Swing n'as pas la pretention de remplacer les windowmanagers [...] Le desktop etant lui meme une application Qt
Oui, c'est exactement ce que je dis, et c'est bien pour ça que Qt n'est pas archaïque comme tu le prétends. Cette toolkit a encore son utilité.
[^] # Et aller une cuillère pour papa ...
Posté par Anonyme . Évalué à 0.
Des 10nens ca fait combien ?
Et Qt il en prend combien pour une appli utilisable ;-)
Emm... QT C'est pas de l'athenaWidget et une comparaison point à point me semblerait assez interessante à voir.
4R34'.
[^] # Re: Et aller une cuillère pour papa ...
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Dans les 50 ou 60 Mo pour une démo Swing, JDK 1.3 de chez Sun, si je me souviens bien.
> Et Qt il en prend combien pour une appli utilisable ;-)
Toujours difficile à dire vu qu'il s'agit d'une lib partagée. Pour Konqueror : vers les 20Mo. 5Mo pour Konsole, 15Mo pour KWord. Et encore, là on ajoute les libs KDE.
[^] # Re: Ce qui explique mon post ...
Posté par boubou (site web personnel) . Évalué à 4.
C'est marrant ça, j'étais sûr que Sun avait historiquement poussé Java pour niquer Microsoft. On m'aurait menti ? Ces braves gens de chez Sun voulaient donc le bien de l'humanité ?
Ca m'atriste de voir tant d'articles incomplets et peu precis sur java, au mieux le traitant comme un simple nieme langage (et oubliant meme les concepts de la plateforme java)
Et oui, mesdames et messieurs, car Java (tm) n'est pas un langage, c'est une révolutionnaire PLATEFORME (et oui !) !!!! Trop puissant (note : PLATEFORME est le nouveau nom de api (et oui, c'est vachement plus classe (classe, Java (tm), ah, ah, ah))). D'ailleurs personne n'avait inventé avant le concept de bytecode (ni celui de PLATEFORME, on disait stupidement api, comme des cons). Par exemple Caml (http://caml.inria.fr/(...) ) n'a jamais compilé sur une machine virtuelle avant l'extraordinaire découverte (une première galactique, il faut le rappeler) par les ingénieurs de Sun (tm) du concept sus-mentionné. D'ailleurs Caml (qui est n'est pas open source, au contraire de Java (tm)) a tellement de retard sur les génies de Sun (tm) qu'il n'existe pas de compilateur natif Caml. D'ailleurs le compilateur natif Caml (qui n'existe pas) ne fait pas de inlining. Ce qui fait que s'il existait, de toute manière le code engendré serait tout pourri. D'ailleurs le leader de Caml (Xavier Leroy) est un naze, il ne sait pas programmer et ce n'est pas lui qui a implanté les threads linux.
Et hop.
PS : Xavier tu es un dieu, je te jure que c'est une blague foireuse.
[^] # Pitié ...
Posté par Anonyme . Évalué à 0.
C'est la vie ;-)
Et meme si Sun prefere orienté son pipotage sur le langage c'est a eux de voir...
3hck.
[^] # Re: Ce qui explique mon post ...
Posté par Anonyme . Évalué à 0.
Les résultat?
C vainqueur en temps d'execution/memoire.
Caml (compilé) juste derriere.
Java était pas mal au niveau temps (loin derriere Caml quand même) mais consommait beaucoup plus de mémoire..
Je me mettrais bien au Caml mais je bloque au niveau de la syntaxe (non, ce n'est pas un troll, juste mon avis).
Vous pourriez pas remplacer la syntaxe de Caml par celle de Ruby ? :-)
En gardant les performances ;-)
reno
PS: la "plateforme" Java: ouahahahah (rire jaune), ce n'est pas le marketing qui me gène, c'est la qualité de l'implémentation..
Ils sont champions pour les bugs chez Sun!
Tu passes ton temps a utiliser des contournements (quand ils existent!) pour des bugs signalés, il y a des années!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.