Donc tu es train de me dire que si la bibliothèque utilisée est mal programmée, les performances du langage qui appellent la bibliothèque sont plus importantes que si la bibliothèque est bien écrite (en toute logique, c'est l'inverse puisqu'il y a moins d'overhead) ? Tu n'as pas l'impression de raconter n'importe quoi ?
Quand tu sous-traites quelque chose (par exemple l'affichage) à un ebibliothèque implémentée en C et en assembleur, celle-ci est destinée à te faire gagner du temps (ça va, tu as compris jusqu'ici ?). Plus la bibliothèque est bien faite, plus elle te fait gagner du temps (exemple, en SDL tu peux demander à la bibliothèque de bouger un sprite, le tout implémenté en C et en assembleur) (tu suis toujours ?). De ce fait, avec une très bonne bibliothèque, il te reste plus de temps pour les autres traitements, ceux qui sont implémentés directement dans ton langage (pas de problème ? Je peux répéter, si tu veux). Donc, meilleure est la bibliothèque (en C), moins les performances de l'autre langage influent sur les performances globales. Normalement, tu devrais comprendre, maintenant.
Du reste les bibliothèques ont bon dos dans ton argumentation : si une GUI en Java rame c'est à cause de Swing ; si un jeu en Java tourne correctement c'est d'autant mieux car la bibliothèque sous-jacente est pourrie.
Ca me semble cohérent, quel est le problème ? Je vais préciser, parce que tu sembles en mauvaise forme ce soir. Swing est une couche 100% Java ajoutée par dessus le toolkit de la plateforme cible. Il ne bénéficie que très peu du dit toolkit (sous linux en tout cas) car presque tout est ré-implémenté (ascenceur, gestion du focus, etc.). De plus, il y a des problèmes dans la gestion des pipelines graphiques, quelques erreurs de conception (reconnues par Sun et en cours de correction) etc. Bref, ça rame, tout le monde est d'accord. Le concurrent SWT d'IBM ne rame pas. Il n'est pas aussi réactif qu'une interface en C, je suis d'accord, mais il est tout à fait utilisable, même sous linux. Ca prouve qu'on peut faire un toolkit Java correct. Qu'il soit basé sur du C ne pose aucun problème, c'est le cas de tous les langages. Enfin, AWT n'est pas génial pour faire des jeux, car même s'il rame moins que swing (il y a une couche en moins), il est très loin d'offrir les fonctionnalités évoluées de la SDL. Il est donc remarquable (au sens de notable, pas au sens de formidable) que Frozen Bubble fonctionne bien malgré l'utilisation de l'AWT.
Je ne comprends pas : il faut une bibliothèque pour faire de l'objet performant en Java ? En C++, en Ada 95, c'est livré d'origine.
Fais un effort, je pense que c'est à ton niveau.
Je ne veux pas t'imiter dans l'insulte
Quelques exemples (c'est moi qui souligne) :
C'est une incapacité à comprendre la relativité d'un argument ?
Tu reconnais finalement avoir dit des âneries, c'est bien ;)
tu persistes avec cet argument idiot
Quant à ton memo, il est amusant. Evaluer l'empreinte mémoire avec HelloWorld, c'est sur puissant. Comparer un langage comme Sather dont le support du parallelisme très limité (par rapport à Java) et dont l'aspect dynamique est inexistant à Java est aussi tout à fait fair play et de bonne foi (pareil pour Eiffel sur l'aspect dynamique). Pour la comparaison avec Python, je ne me prononce pas, je ne connais pas assez bien trois choses : la part des bibliothèques qui sont écrites en C (ce qui limite toujours l'occupation mémoire), l'aspect multi-thread et le niveau de reflexivité/introspection.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou . En réponse à la dépêche 1ère mouture du collecticiel client de OpenOffice.org : Glow. Évalué à -1.
Quand tu sous-traites quelque chose (par exemple l'affichage) à un ebibliothèque implémentée en C et en assembleur, celle-ci est destinée à te faire gagner du temps (ça va, tu as compris jusqu'ici ?). Plus la bibliothèque est bien faite, plus elle te fait gagner du temps (exemple, en SDL tu peux demander à la bibliothèque de bouger un sprite, le tout implémenté en C et en assembleur) (tu suis toujours ?). De ce fait, avec une très bonne bibliothèque, il te reste plus de temps pour les autres traitements, ceux qui sont implémentés directement dans ton langage (pas de problème ? Je peux répéter, si tu veux). Donc, meilleure est la bibliothèque (en C), moins les performances de l'autre langage influent sur les performances globales. Normalement, tu devrais comprendre, maintenant.
Du reste les bibliothèques ont bon dos dans ton argumentation : si une GUI en Java rame c'est à cause de Swing ; si un jeu en Java tourne correctement c'est d'autant mieux car la bibliothèque sous-jacente est pourrie.
Ca me semble cohérent, quel est le problème ? Je vais préciser, parce que tu sembles en mauvaise forme ce soir. Swing est une couche 100% Java ajoutée par dessus le toolkit de la plateforme cible. Il ne bénéficie que très peu du dit toolkit (sous linux en tout cas) car presque tout est ré-implémenté (ascenceur, gestion du focus, etc.). De plus, il y a des problèmes dans la gestion des pipelines graphiques, quelques erreurs de conception (reconnues par Sun et en cours de correction) etc. Bref, ça rame, tout le monde est d'accord. Le concurrent SWT d'IBM ne rame pas. Il n'est pas aussi réactif qu'une interface en C, je suis d'accord, mais il est tout à fait utilisable, même sous linux. Ca prouve qu'on peut faire un toolkit Java correct. Qu'il soit basé sur du C ne pose aucun problème, c'est le cas de tous les langages. Enfin, AWT n'est pas génial pour faire des jeux, car même s'il rame moins que swing (il y a une couche en moins), il est très loin d'offrir les fonctionnalités évoluées de la SDL. Il est donc remarquable (au sens de notable, pas au sens de formidable) que Frozen Bubble fonctionne bien malgré l'utilisation de l'AWT.
Je ne comprends pas : il faut une bibliothèque pour faire de l'objet performant en Java ? En C++, en Ada 95, c'est livré d'origine.
Fais un effort, je pense que c'est à ton niveau.
Je ne veux pas t'imiter dans l'insulte
Quelques exemples (c'est moi qui souligne) :
C'est une incapacité à comprendre la relativité d'un argument ?
Tu reconnais finalement avoir dit des âneries, c'est bien ;)
tu persistes avec cet argument idiot
Quant à ton memo, il est amusant. Evaluer l'empreinte mémoire avec HelloWorld, c'est sur puissant. Comparer un langage comme Sather dont le support du parallelisme très limité (par rapport à Java) et dont l'aspect dynamique est inexistant à Java est aussi tout à fait fair play et de bonne foi (pareil pour Eiffel sur l'aspect dynamique). Pour la comparaison avec Python, je ne me prononce pas, je ne connais pas assez bien trois choses : la part des bibliothèques qui sont écrites en C (ce qui limite toujours l'occupation mémoire), l'aspect multi-thread et le niveau de reflexivité/introspection.