boubou a écrit 1384 commentaires

Pour ceux qui ne connaissent pas le filtrage de spam par méthodes probabilistes (plus généralement la classification bayésienne), le prochain numéro de MISC (le 9) comportera un article de votre serviteur expliquant les méthodes mathématiques sous jacentes...

Il me semble que c'est quand tu t'adresses à une femme général que tu dis Général tout court. Ceci étant, tu ne dois rien du tout, faut quand même pas pousser.

Tu es sûr ? Il me semble que "mon" est utilisé comme abbréviation de monsieur. Donc je suppose que tu peux dire monsieur le général, mais l'usage me semble être mon général, même pour les non militaires. Par contre, tu ne salues pas. Remarque qu'on dit monseigneur pour un évèque (ou un cardinal, je ne sais plus), même quand on n'est pas croyant, c'est un usage.

Totalement d'accord avec toi, science sans conscience n'est qu'une ruine de l'âme (ou un truc du genre, je n'ai jamais lu Montaigne). Je suis scientifique et j'essaie à la fois d'avoir un minimum de culture en sciences humaines (j'aime bien la sociologie, même si mes connaissances sont limitées) et de vulgariser mon savoir (cf les cours sur mon site et mes articles dans linux mag et misc). Malheureusement, beaucoup de scientifiques n'ont rien à faire des conséquences de leurs recherches ou de la difusion du savoir.

Si j'ai bien compris, le problème n'est pas 40 go de mémoire, mais 10 go de données codées avec la même clé. Ca fait quand même beaucoup de données, tu ne trouves pas ?

Ici, je suis sauvé par le théorème de Gödel que j'interpréterai abusivement ainsi: toute théorie est soit fausse, soit incomplète.

Ah, ah, Kzer, tu n'as pas lu impostures intellectuelles ? Parce que l'une des cibles de Sokal et Bricmont, c'est Regis Debray (celui des vendeurs de pizza albanais à Belgrade) qui fait une utilisation abusive et répétée du théorème de Gödel. Le fait qu'en sciences sociales, il n'y ait pas de vérité absolue est une évidence et point n'est besoin de faire référence au théorème de Gödel pour "prouver" ça. Le théorème de Gödel (les théorèmes pour être précis, d'ailleurs) est un énoncé purement mathématique qui porte sur d'autres énoncés mathématiques. L'appliquer en dehors des mathématiques n'a aucun sens, excepté peut être comme principe philosophique de doute sur une théorie, mais on n'a pas besoin de ça pour ce genre de doute, ne serait-ce que parce qu'on procède par induction, ce qui n'est pas très mathématique (du genre, ça fait des milliards d'années que le soleil se lève tout les matins, donc le soleil se lèvera demain, ce qui est formellement faux).

De plus, les théorème ne disent pas que toute théorie est soit fausse, soit incomplète. Ils disent que dans toute théorie un peu puissante, il existe des propositions indécidables (i.e., on ne peut pas démontrer qu'elles sont vraies, ni qu'elles sont fausses sans sortir du système). Ils démontrent aussi qu'on ne peut pas démontrer la consistance d'une théorie un peu puissante (i.e., on ne peut pas démontrer que la théorie ne conduit pas à une contradiction c'est-à-dire à considérer que A et son contraire sont vrais simultanément). Donc toute théorie est à la fois inconsistante et incomplète. Les maths vivent très bien tout ça depuis des années, tout simplement parce que les énoncés non démontrables ne sont pas si fréquents que ça et que pour l'instant, on n'a pas trouvé de contradiction...

Le régime fasciste comme le régime de l'assault et de la vitesse ? Ce qui veut dire ?

Je ne sais pas. Et comment traduire Le vieux projet de la guerre froide, Open Sky (Ciel ouvert) se réalise au-delà même des objectifs prévus ! La dérégulation du transport aérien s'étend maintenant à celle de la transmission tous azimuts des images captées par satellite ! Soudain, le ciel-atmosphère se dissipe, cède sa luminosité à l'écran, en attendant que le lancement des premiers satellites de réverbération de la lumière solaire dissipe à son tour l'obscurité de la nuit... De fait, la vitesse de la lumière dans le vide n'a jamais servi à se déplacer, à avancer, mais uniquement à voir, à pré-voir. La vitesse limite de la lumière n'est donc que l'autre nom de l'illumination, ou plutôt de l'illuminisme politico-stratégique du temps présent. Ce temps réel qui domine désormais l'espace réel des continents.

Formidable, n'est ce pas (cf http://www.monde-diplomatique.fr/1999/08/VIRILIO/12332(...) ). Vraiment, il n'y a rien à dire, Virilio, c'est magique.

Comme beaucoup de sociologues, si sa pensée à été fidèlement écrite, on peut dire qu'il touche l'histoire avec une méthodologie médiocre.

Qu'est-ce que tu penses de Max Weber (l'éthique protestante) ? Personnellement, j'ai été assez convaincu, et c'est pas mal "historique", comme analyse. Mais bon, je ne suis pas historien...

Et comme Babar le souligne

Pourrais-tu éviter de me confondre avec un éléphant colonialiste ;-) ?

Pour autant, relever les inexactitudes et les obscurités de thèses exposés par des intellectuels doit-il conduire à rejeter la totalité de leur travaux ?

C'est toute la question. Quand j'étais gamin, je lisais science et vie. Comme j'aimais bien les maths, j'étais disons un peu en avance sur la revue. En jour, j'ai lu un article de crypto plein de maths à mourrir de rire. Depuis, je ne lis plus science et vie. Ok, c'est caricatural, mais, pour faire court, le problème de l'utilisation de concepts scientifiques mals maîtrisés me semble symptomatique d'une certaine absence de rigueur dont je ne vois pas pourquoi elle se cantonerait à certaines parties des travaux de l'auteur incriminé.

Virilio est un sociologue,

Ah, je croyais qu'il était architecte...

lisons le sociologue et méfions-nous lorsqu'il jargonne en utilisant les concepts de sciences ou de techniques qu'il ne maîtrise pas.

Cf au dessus. De toute manière, mes compétences en sociologie sont assez faibles, donc j'ai du mal à juger sur cet aspect (je n'ai lu que quelques Bourdieu et des livres de ses élèves/disciples, ainsi que Max Weber).

Ce qu'il dit à propos des catastrophes industrielles présentent vraiment de l'intérêt.

As-tu des références sur le net ?

Maintenant, l'édition , c'estr aussi du marketing et le Monde diplomatique n'est pas une revue scientifique, on ne peut guère s'en servir comme une référence !

Oui et non. Je ne pense pas que la rédaction du Monde diplo modifie le texte de Virilio. Il parle bien de nains affligés de gigantisme, sans qu'on l'y force. Le monde diplo contient de nombreux articles écrits en français, je ne pense pas qu'ils cherchent un coup en publiant un truc imbitable de Virilio.

Paul Virilio (qu’on a trop souvent démoli sans l’avoir lu parce qu’il a osé voir des conséquences négatives à l’informatique et à Internet)

Personnellement, j'ai plutôt tendance à démolir Virilio parce qu'il raconte n'importe quoi. Je n'ai jamais eu le courage de lire autre chose que ses articles dans le Monde diplomatique, mais c'est déjà édifiant. Pour mémoire, Virilio faisait partie des pseudo-philosophes attaqués (à juste titre) dans l'édifiant livre de Sokal et Bricmont, Impostures intellectuelles (cf http://www.physics.nyu.edu/faculty/sokal/index.html(...) et http://dogma.free.fr/txt/JB_Impostures-intellectuelles.htm(...) , par exemple).

Le titre était très bien choisi, tant les auteurs attaqués pratiquaient (et pratiquent toujours pour Virilio et Debray, par exemple) un sabir incompréhensible dans lequel une très faible compétence technique (en mathématiques pour Debray et en informatique pour Virilio) est compensée par un étalage indécent de mots complexes mals compris (comme dit l'adage populaire, la culture, c'est comme la confiture, moins on en a, plus on l'étale).

J'engage les personnes intéressées par la prose de Virilio d'aller se faire une idée par elles-mêmes sur le site du monde diplo (http://www.monde-diplomatique.fr/(...)). L'article Progrès à grand spectacle (cf http://www.monde-diplomatique.fr/2001/08/VIRILIO/15446(...) ) est par exemple assez amusant. Rien que dans le premier paragraphe, on trouve Le paradoxe du développement scientifique, à l'exemple de l'illusionnisme, auquel il doit beaucoup, n'a-t-il pas été d'amener une dangereuse bande de nains affligés de gigantisme à prendre pour vrai ce qui n'était que manipulations des apparences, supercheries et, dans certains cas, tissu d'absurdités ?. Du grand n'importe quoi. En quoi par exemple le progrès scientifique doit il quelque chose à l'illusionnisme ? Virilio veut-il dire que le progrès est parfois illusion ? Mais pourquoi ne pas dire ça en Français (d'après Sokal et Bricmont, cela aura nettement moins de "classe", par ce que c'est une evidence) ? Qu'est qu'un nain affligé de gigantisme ? Etc.

Ceci étant, cher Kzer, on peut trouver partout de l'inspiration et il est impressionnant de rencontrer sur linuxfr une mention de Virilio. Donc, ne te méprends pas en considérant mon post comme une attaque contre toi.

Je crois plutôt qu'il a mis longtemps à acquérir une certaine liberté de parole.

Très certainement. Le dévoir de réserve n'est pas une plaisanterie pour les militaires. Ils n'ont pas le droit de faire et de dire ce qu'ils veulent, même en dehors de leurs fonctions, sinon ils risquent des poursuites...

On peut voir le problème d'une autre manière : pourquoi ne pas faire en sorte que les formulaires d'institutions concernants TOUT les citoyens, au moins théoriquement, nécessite l'usage d'outils qui ne sont pas à portée de tout les citoyens ?

Nous sommes bien d'accord, mais le jour ou les officiels de la CE prendront en compte les intérêts des citoyens, on en rediscutera. Le coup de Office n'est qu'un exemple (tu verais les tableaux excel bourrés de macro développées avec notre fric), édifiant mais marginal (à mon avis). Quand tu penses à l'exemple le plus dingue, la PAC, tu vois que l'intérêt de citoyens ne pèse pas lourd (et je n'évoque même pas la servilité face aux USA).

C'est vrai. Mais j'ai un peu peur de voir que les gens qui abandonnent le 100 % libre ont tendance à ensuite n'utiliser quasiment plus que le libre là où il est au mieux de sa forme, et ne plus vraiment y contribuer. Et je trouve ça un peu dommage pour le libre.

N'es tu pas un peu pessimiste ? Il est vrai que certains de mes collègues font du windows (ou du Mac Os, ce qui n'est pas beaucoup mieux, je trouve) pour pouvoir utiliser Office. Mais ces personnes ne sont pas vraiment des contributeurs potentiels...

MSOffice ou Photoshop sous linux

Pourquoi pire ? Ok, Office utilise pour l'instant un format proprio très mal documenté qui est à la source de fuites d'informations (cf les articles de misc à ce sujet par exemple), mais il rend beaucoup de service. Si j'avais Office sous linux, je serais très content, par exemple pour remplir certains formulaires envoyés par la communauté européenne, ou pour bosser avec certaines boites. Je suis d'accord qu'il faut se battre contre la CE et les boites en question, mais entre temps, il faut bien vivre. Alors comme je paye une licence Office, autant ne pas payer une licence windows en plus.

Quant à Photoshop, sa gestion de l'aspect pré-presse (flashage et compagnie) est totalement inégalée, alors quant tu bosses dans le domaine, tu es obligé de passer par Photoshop, c'est la vie (de plus, l'aspect pré-presse (genre couleurs des encres, etc.) est protégé par des brevets industriels et faire ça en libre pour gimp est très dur).

Bref, c'est dur de faire du 100% libre dans certains métiers alors il faudrait éviter les caricatures...

Tu es très fort, tu arrives à me faire aller à l'encontre de mes bonnes résolutions.

D'où vient cette manie de se restreindre à un domaine réduit quand on répond à une affirmation générale ? Ah oui, c'est vrai : tu comprends que ton argument est foireux, donc tu déplaces la discussion. Comme si personne n'avait rien vu ;)

Mais bien sûr. J'ai dit :

La relative lenteur de Java pour l'aspect interface graphique prouve simplement que swing est mal conçu

mais voir qu'on peut faire aussi bien en Java sans passer par une optimisation de très bas niveau, prouve effectivement que Java fonctionne correctement.

SDL est une super bibliothèque très optimisée qui est interfacée correctement avec Perl, d'où de bonnes performances. Mais on peut faire aussi jouable en Java sans assembleur, sans accès direct à la mémoire vidéo, etc. De même, OpenGL est super optimisé et remarquablement bien interfacée avec Java, ce qui permet de programmer objet tout en obtenant d'excellentes performances.

De très nombreux langages ont choisis de se baser sur gtk avec des performances excellentes. De même, les performances de swt en Java sont très bonnes. J'en déduis donc que le probème de swing n'est pas Java, mais swing. Si tu ne comprends pas, je n'y peux rien.

si tu utilises une bibliothèque ultra optimisée (SDL) pour faire un jeu, tu peux même l'écrire en tcl, ça ne ramera pas. Alors que faire un jeu dont l'affichage est ultimement géré par motif, ça demande un langage qui tourne correctement.

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

etc., je ne vais pas recopier intégralement des posts que tu ne lis pas. Maintenant, cherche bien là dedans (et dans le reste) et dis moi à quel moment j'ai nié ton histoire d'importance relative du langage. C'est toi qui a écrit que je pensais le contraire.

Et puis : si ton jeu tourne à 150 fps, ça te permet de descendre à 50 fps avec un jeu trois plus complexe (en affichage, en IA, en moteur physique...). Pas trop dur à comprendre.

Oui, ou encore de descendre à 50 fps si le reste du jeu est implémenté dans un langage qui rame. Bravo, tu as compris ce que je me tue à t'expliquer depuis plusieurs posts (cf 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).

la soi-disant stagnation des performances des compilateurs C

Ton super exemple est gcc (très utilisé pour compiler les jeux commerciaux), pour lequel je veux bien croire que les performances ont augmenté, heureusement, malgré ses nombreuses qualités gcc a toujours été très en retard sur les compilateurs commerciaux (par exemple sur alpha, c'était une catastrophe). J'aimerais savoir quelle a été la progression des compilateurs C commerciaux sur les 10 dernières années (pour le C++, la progression est énorme). Ton autre super argument est la prise compte d'un hardware moderne. Formidable. C'est aussi le cas dans tous les autres langages. De toute manière, je suis persuadé que les compilateurs C ont très peu progressé par rapport aux compilateurs C++ et à la JVM.

Ceci étant, pour te faire plaisir, je veux bien dire que j'ai dit une connerie.

le soi-disant peu d'importance des performances CPU dans les jeux modernes

J'ai dit De plus, le discours sur les performances me fait bien rire.. C'est bizarre mais j'ai l'impression que ce n'est pas exactement la même chose. Et je maintiens que Carmack a été très réticent pendant des années à passer au C++ pour des raisons de performances et de bugs des compilateurs. Or, aujourd'hui, plus personne ne critique le choix du C++ pour programmer l'essentiel d'un jeu. Mon argument était juste de dire que je pense que dans quelques années (disons j'espère), l'argument "Java ça rame" sera devenu aussi pertinent que celui "C++ ça rame".

le soi-disant fossé de performances de C et C++ par rapport à l'assembleur codé à la main

Alors la, bravo. Trouve moi la citation qu'on rigole. Et ensuite, va lire les articles sur ATLAS pour voir ce qu'on peut gagner en passant à l'assembleur (par rapport au C). Les programmeurs codent les jeux en C++ parce que la perte de performance est largement compensée par le hardware actuel et les économies en temps de développement, pas parce qu'ils sont sur que l'assembleur engendré est aussi bon que ce qu'ils pourraient faire à la main. Et je ne connais pas de bench significatif concernant la qualité du code engendré (les parties d'ATLAS concernées sont très spécifiques).

la soi-disant utilisation courante de Java dans les jeux actuels alors que le seul exemple que tu as trouvé ne concerne que l'utilisation en tant que langage de script.

Aller, trouve moi la citation qu'on rigole de nouveau.

Non, c'est vrai, si tu lis Gamasutra, c'est forcément que tu as raison !

Je suppose que tu travailles dans un grand studio de développement de jeux (et tu ne connais pas Vampire The masquerade ?). Parce que sinon, tu fais comment pour savoir ce qui est utilisé comme techno dans les logiciels propriétaires que sont les jeux ? Personnellement, je lis gamasutra. Mais c'est vrai que je suis incompétent.

Et si tu as codé des bouts de Freecraft en C, c'est bien la preuve que Java ownz les jeux video, hein ;)

Ba oui, c'est d'ailleurs exactement ce que j'ai dit (tu dois pouvoir trouver la citation quelque part). D'ailleurs, c'est sûrement pour rien que j'ai dit mais ça voulait dire que je ne prétends pas que Java est adapté à la programmation de jeu.

Tu peux toujours faire de l'ironie à deux centimes. J'ai juste voulu indiquer que j'avais quelques compétences en jeux vidéo, contrairement à ce que tu affirmes. Quelles sont les tiennes, à part une grande bouche ?

Si tu penses que relever un manque de compétences est une insulte, tu dois être assez susceptible dans la vie quotidienne non ? (tu es libre d'y voir une insulte polie :-))

D'après le grand robert, crétin signifie "personne sotte, stupide". Je te suggère donc de remplacer dans mes phrases "tu es un crétin" par "tes arguments sont stupides". C'est plus long et moins direct, et éventuellement un peu moins une généralisation hâtive (c'est vrai que tu utilises peut être des arguments intelligents dans d'autres contextes). Au final, tu obtiendras ce que j'appelles une insulte polie, mais ça ne semble pas te gêner, alors allons pour l'insulte polie.

Merci pour tes réponses précises.

C'est sur qu'avec -ms150m -mx150m, ça ne risque pas de bien marcher sur ta machine (comme tu le dis toi même), puisque ça signifie que la JVM alloue 150 mo pour tourner. Je pense qu'une partie des mauvaises performances vient de ça. Je vais essayer de faire les tests sur ma machine (j'ai 256 mo), mais je n'ai pas un XFree récent (ni même décent), donc ça risque de merdouiller à la fois en C et en Java.

Je veux bien que les développeurs ne soient pas au niveau de ceux d'id Software

Tu es trop généreux avec Java. Je pense qu'ils ont du étudier le source pour ne pas faire trop d'erreur et que l'essentiel du problème vient de Java, essentiellement pour des raisons de mémoire. Mais cela n'est qu'une hypothèse. Comme il s'agit d'une démonstration technologique, elle me semble cependant plausible, au sens où les programmeurs ont quand même du faire pas mal d'effort pour obtenir quelque chose de potable.

Dernière remarque, il est probable que cela marche beaucoup mieux sous windows, c'est malheureux à dire, mais les JVM fonctionnent en général mieux sous l'os de ms...

Sur ma machine (K6/350,TNT2,132Mo), la version Java tourne à 5 fps et met plusieurs minutes à se charger, la version C tourne à 70 fps et se charge instantanément.

En effet, c'est une catastrophe. Combien de ram utilise la version Java (un pauvre top devrait suffire) ? Quelle JVM et quelle option de démarrage ? Quel système ? Les différences sont étonnantes parce que l'implémentation est normalement basée sur un pont opengl (pas le même que arkanae) et pourtant, c'est vraiment tout pourri... Dernière remarque, les auteurs de la version Java disent que leur rendu est meilleur. Qu'en penses-tu ?

Non, n'importe quoi. Si l'overhead apporté par la bibliothèque est moins important, alors l'influence du reste est plus importante relativement au total (c'est des maths, tu sais).

Tu confonds évaluation théorique et réalité pratique, ce qui est très génant pour un jeu. Ce que l'utilisateur voit, c'est la fluidité du jeu, en gros le nombre de frame par seconde. Quand ça tombe en dessous d'un certain niveau, c'est injouable. A partir d'un autre niveau, on ne voit plus la différence. Entre 150 fps et 50 fps (en valeur minimale), pour un jeu comme frozen bubble, il est impossible de faire la différence. Si ta bibliothèque C est bien faite, comme c'est le cas de SDL, tu peux facilement dépasser très largement le minimum syndical. Que le reste de l'application rame un peu ne change pas grand chose car cela représente une part infime des performances de la dite appli. Tu as parfaitement raison de dire que l'influence relative du langage est plus importante quand la bibliothèque est bien faite, mais on s'en fout. L'importance relative n'est pas directement perçu par l'utilisateur, c'est la réactivité de l'ensemble qui compte. Quand tu programmes avec une bibliothèque comme SDL ou OpenGL qui te permets de garantir (ou presque) de bonnes performances, le reste importe peu. A contrario, quand tu utilises une bibliothèque mal faite, il te reste une part très faible du temps CPU disponible entre deux frames et les performances du code utilisé à ce moment sont cruciales pour l'interactivité du jeu. C'est le même problème pour swing. L'utilisateur qui doit attendre une demi-seconde la première fois qu'il clique sur un menu parce qu'il faut byte-compiler la sur-couche swing d'une vague fenêtre motif va être assez ennervé, même si les fonctions complexes déclenchées par le GUI sont exécutées très rapidement.

il suffit de savoir lire

Oui, oui, en particulier We do not believe these flaws are inherent in the Java platform but that they relate to difficulties in our Solaris implementation., mais ça, tu ne risques pas de le citer, n'est-ce pas...

Mais bon, tout ça, c'est trop compliqué, d'ailleurs "Java rulez dans l'embarqué" et "la mémoire a un coût dérisoire, quelle importance si ça en bouffe beaucoup" (sic) n'est-ce pas :-))

Tu ne sembles pas savoir que la J2ME a une occupation mémoire très faible (beaucoup plus faible que celle de la J2SE dont il est question dans ton mémo). L'adoption de Java sur les téléphones portables me semble assez symptomatique. J'ai comme l'impression que les fabriquants connaissent mieux le problème que toi. D'autre part, je maintiens que la mémoire ne coûte rien sur un PC et donc que les problèmes de la J2SE ne sont pas si graves que ça.

Enfin, bon, ton gros problème est que tu t'es engouffré bille en tête dans une discussion à laquelle tu n'as rien compris mais où il te semblait scandaleux qu'on critiquât Java, n'est-ce pas ? Ayant dû abdiquer le débat sur les jeux video où tu t'es fait ramasser par plusieurs personnes à cause de ton manque chronique de connaissances en la matière, tu es maintenant réduit à lancer des attaques personnelles et à ressasser quelques arguments déjà plusieurs fois réfutés ;)


Oui oui, bien sûr. C'est marrant, mais ayant développé (en C) la gestion du son et la version 2 du pathfinding de freecraft (pas la version 3, je l'avoue), j'avais l'impression d'avoir une vague idée de ce qu'est un jeu. Je pensais aussi que la lecture régulière de gamasutra m'aidait un peu dans cette compréhension. Mais apparamment non, j'ai un manque chronique de connaissances en la matière (j'aime bien les insultes polies, ça m'a toujours fait beaucoup rire. Je suis plus direct, en général, mais bon, je respecte l'art de l'insulte polie). D'autre part, tu devrais relire https://linuxfr.org/comments/221368.html(...) Peut être que tu ne comprends pas ma première phrase, mais ça voulait dire que je ne prétends pas que Java est adapté à la programmation de jeu.

Allez, va, c'est ma dernière réponse, je ne peux pas lutter contre un grand réfutateur d'argument qui connaît si bien le jeu vidéo.

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.

La RAM, en embarqué, trop facile d'en ajouter ;)

Déjà entendu parler de J2ME ? Non. Laisse tomber.

Alors ça veut dire quoi "100% pur Java" dans ta phrase d'origine ?

Ca veut dire que le programme est écrit entièrement en Java et utilise un toolkit écrit en C. Tu es stupide ou tu le fais exprès ? Tu ne vois pas la différence avec SDL qui propose une api pour les jeux, avec gestion des sprites, etc ? Et donc qu'il y a beaucoup plus de C dans Frozen Bubble Perl que dans la version Java ?

Que vient faire la méthode d'implémentation des bibliothèques natives dans une discussion sur les langages compilés en bytecode ?

Ca commence a devenir clair dans ma tête, tu le fais exprès... Mais comme je suis charitable, je t'explique : si tu utilises une bibliothèque ultra optimisée (SDL) pour faire un jeu, tu peux même l'écrire en tcl, ça ne ramera pas. Alors que faire un jeu dont l'affichage est ultimement géré par motif, ça demande un langage qui tourne correctement.

Oui. Et trouver dans Arkanae une preuve des performances de Java est ridicule. Tu comprends l'analogie ou il te manque encore un bout d'objectivité pour accepter l'évidence ?

Je ne dis pas le contraire, je réponds à l'affirmation stupide que Java ça rame. Il existe des bibliothèques Java qui permettent de faire de la programmation orientée objet en pur Java (pour l'utilisateur de la bibliothèque) tout en obtenant d'excellentes performances. Mais visiblement, tu ne veux pas comprendre, alors bon...

après avoir convenu toi-même que le rendu ne faisait pas partie du langage hôte (puisque réalisé par des bibliothèques natives), tu persistes avec cet argument idiot

Mais tu es vraiment crétin, c'est ça ? Aucun langage autre que le C (et encore), n'utilise le hardware moderne de façon native. Tu es trop bête pour comprendre ça, c'est ça ton problème ? Les drivers sont programmés en C et en assembleur, puis on ajoute une couche du langage cible. C'est la vie.

Actuellement, l'impression de lenteur associée à Java est presque exclusivement liée à trois choses : l'occupation mémoire (vrai problème mais intimement lié à l'aspect très dynamique du langage) qui donne l'impression que ça rame sur une machine avec une mémoire sous dimensionnée, le temps de chargement (lié au fait que Sun n'a toujours par prévu la sauvegarde du code byte compilé pour les bibliothèques de base) et surtout swing. Nous sommes plusieurs a essayer de t'expliquer que swing pose problème, pas Java, avec des exemples de couches d'abstraction mieux conçues comme SWT ou comme Open GL for Java. Mais comme tu te comportes comme un crétin, tu ne veux pas comprendre. J'abandonne.

"Quelques années" = 10 ans au moins.

Oui, et alors ? Les performances des compilateurs C ont augmenté ?

Le C et le C++ sont bien installés dans les studios de jeux depuis des années.

Pour le C, c'est vrai au moins depuis doom (qui n'avait presque pas d'assembleur). Pour le C++, c'est beaucoup moins vrai. Quake III est programmé en C.

La différence, c'est que la plupart du code généré en C ou C++ est meilleur que le code qu'aurait programmé un humain en assembleur.

C'est marrant, quand le projet gnome a débuté, l'argument principal était que le C++ c'est horrible, ça rame à mort, les compilateurs ne marchent pas et le code généré est vachement moins bien que ce qu'on peut faire avec du C. Et maintenant, plus personne ne dit ça. Amusant, non ?

On retourne donc la question : tu connais des jeux commerciaux qui sont programmés en Java ?

C'est quoi le rapport ? T'es idiot ou quoi ? L'argument sur la qualité d'un jeu évoqué par mon interlocuteur de départ n'a rien à voir avec Java mais avec le fait que les jeux open source sont ou bien moches ou bien avec des dessins très mignons (comme frozen bubble), mais très en retard sur les jeux actuels.

D'autre part, java a été utilisé depuis des années dans des jeux commerciaux, comme par exemple Vampire the masquerade qui a remplacé son langage de script proprio par du Java. De plus, Java est très utilisé en embarqué pour les jeux sur téléphone et certains PDA. L'un des premiers middleware pour les jeux de roles online est écrit en Java, etc. Mais en fait, tu t'en moques, n'est-ce pas ?

il est adapté à la programmation de jeux vidéo ?

Tu es mal comprenant ?

C'est une bonne idée de citer un jeu vidéo comme exemple, vu que c'est un domaine où le besoin en performance est élevé, mais là il faudrait trouver un peu mieux pour convaincre.

Tu connais des jeux open sources qui sont au niveau des jeux commerciaux ? Franchement ? De plus, le discours sur les performances me fait bien rire. Il y a quelques années, tout le monde disait qu'il fallait faire les jeux en assembleur. Ensuite on est passé au C et maitenant tous les moteurs sont en C++ (Doom III par exemple). Alors franchement...

Ah, les sprites FB sont affichés pixel par pixel en "100% pur Java", peut-être ? Il n'y a pas la moindre bibliothèque en-dessous ? Je suis scié.

Tu es vraiment d'une mauvaise foi consternante. Tu sais très bien que seul le C affiche les pixels de façon directe, et encore, la plupart des drivers contiennent de l'assembleur. D'autre part, tu sembles oublier (ou ne pas connaître) plusieurs choses.

D'abord, Frozen Bubble version Java est écrit en AWT pour être compatible avec java 1.1. Les sprites sont gérés avec drawImage, qui était l'api de plus bas niveau en Java (ce n'est plus cas avec les versions récentes). L'appel Java est traduit en un appel natif de la bibliothèque graphique sur laquelle AWT est construit (par exemple Motif sous Unix). Il n'y a donc pas de différence notoire entre un programme Java et un programme C utilisant motif. Et les performances de FB en Java prouvent qu'on peut très bien faire de l'utilisable avec la version 1.1 en Java pur, tout aussi pur que n'importe quel programme dont l'affichage est géré par X11 (ou d'ailleurs par windows, ça revient au même). Il existe très peu de toolkits qui parlent directement le protocole X, par exemple. Ils utilisent en général la XLib.

D'autre part, il existe depuis la version 1.4 de Java une api d'accès direct à la mémoire vidéo qui permet d'être encore plus pur Java, puisqu'on court-circuite le toolkit.

Enfin, SDL, la bibliothèque C sur laquelle est basée FrozenBubble en Perl est destinée à la programmation de jeu. Le blitting des sprites est écrit en assembleur, par exemple. Trouver là dedans une preuve des performances de Perl est bien sur ridicule (ce que tu ne sembles pas nier), mais voir qu'on peut faire aussi bien en Java sans passer par une optimisation de très bas niveau, prouve effectivement que Java fonctionne correctement.

On s'en fout, puisque le rendu graphique est effectué par une lib en natif. Ce qui compte, c'est le moteur de jeu.

Absolument pas, cf supra. SDL est une super bibliothèque très optimisée qui est interfacée correctement avec Perl, d'où de bonnes performances. Mais on peut faire aussi jouable en Java sans assembleur, sans accès direct à la mémoire vidéo, etc. De même, OpenGL est super optimisé et remarquablement bien interfacée avec Java, ce qui permet de programmer objet tout en obtenant d'excellentes performances. Peut-on faire ça en Perl avec un rendu aussi complexe que celui d'arkanae ?

Du reste au vu des screenshots l'environnement 3D d'Arkanae est extrêmement pauvre vis-à-vis de ce qui se fait dans le genre dans le domaine commercial.

Et alors ? C'est quoi le rapport avec la choucroute à par dénigrer gratuitement le travail des autres ? Le rendu d'arkanae est plus complexe que celui de Frozen Bubble, qu'il soit inférieur à celui de Doom III ne change rien à ça.

C'est sûr qu'en posant comme hypothèse la conclusion à laquelle on veut arriver, y a pas trop de mal à la démontrer :-))
C'est amusant qu'apparemment tu ne penses pas à faire le même raisonnement pour les autres langages. C'est une incapacité à comprendre la relativité d'un argument ?

Où est-ce que tu vois que je ne fais pas le raisonnement pour les autres langages ? De très nombreux langages ont choisis de se baser sur gtk avec des performances excellentes. De même, les performances de swt en Java sont très bonnes. J'en déduis donc que le probème de swing n'est pas Java, mais swing. Si tu ne comprends pas, je n'y peux rien.

Pourquoi Java au lieu de Perl ou C++ ? Il ne me semble pas que Java ait des qualités qui en fassent le langage idéal pour la programmation d'interfaces graphiques.

Je n'ai jamais dit ça, bien que une non relecture de ma phrase ait provoqué l'apparition d'un mot inutile (implémenter). Je voulais dire "il est logique d'interfacer un langage de haut niveau comme Java avec un langage de bas niveau comme le C pour attaquer des bibliothèques très efficaces.", ce qui n'a aucun rapport avec les interfaces graphiques, mais la réutilisation de ce qui se fait de bien. Sinon, je ne considère pas Perl comme un langage de haut niveau.

Il n'y a rien de "logique" là-dedans, c'est simplement que tu aimes Java. Un amateur de Python ou Ocaml te sortira la même phrase au mot près, mais avec Python ou Ocaml à la place de Java. Et il aura aussi raison que toi.

Pour l'aspect logique, cf plus haut. Sinon, oui, Python et Ocaml sont d'excellents langages qui sont interfacés avec des bibliothèques efficaces en C. Et alors ?

Là pour le coup question pertinence tu fais très fort :)

En tout cas, je n'atteinds pas ton niveau de mauvaise foi.

C'est sûr que Frozen Bubble est un super exemple. Il marche très bien en 100% pur Java alors que pour Perl, c'est basé sur SDL (programmé en C). Et c'est sûr que le rendu graphique de Frozen Bubble est comparable à celui de Arkanae.

Ceci étant, par dela le ridicule total de cette comparaison, je ne vois pas le problème. Il est logique d'implémenter d'interfacer un langage de haut niveau comme Java avec un langage de bas niveau comme le C pour attaquer des bibliothèques très efficaces. La relative lenteur de Java pour l'aspect interface graphique prouve simplement que swing est mal conçu, contrairement à OpenGL for Java. SWT d'IBM est déjà beaucoup mieux.

C'est amusant comme quand tu parles de Java tu perds toute crédibilité et pertinence.

Oh oui, quel horreur cete consommation de méga octet. C'est sur que ça vaut très cher la mémoire...