boubou a écrit 1384 commentaires

Ecrire un jeux directement sur OGL ou D3D est non seulement tres complexe mais aussi tres lent (car tu enverras a la carte 3D plus de polygonne que necessaire).

C'est une blague, je suppose ? Pourquoi tous les jeux state of the art sont écrits en OpenGL ou en Direct3D ? Les développeurs de jeu n'ont pas attendu Java3D pour écrire leurs moteurs et le résultat est bien plus performant que celui obtenu en Java3D. L'intérêt de jogl par rapport à Java3D est de permettre de faire de la 3D en Java en utilisant toutes les subtilités des cartes graphiques modernes (même le Cg !) et donc de coder un moteur de jeu (par exemple) efficace. Java3D répond peut être à certains besoins, mais jogl est beaucoup plus utile de façon générale.

Le fait que java consomme un peu plus de mémoire n'est certainement pas faux... D'un autre coté, je ne vois pas vraiment cela comme un problème.
Si à notre époque, cela était vraiment un problème, je développerai en Assembleur et je dirais sur toutes les news PHP, Java, C++, C, Ruby, ASP, VB... que c'est nul car ca consomme beaucoup de mémoire.

Ne te fais pas plus bête que tu l'es. Je viens de te démontrer que Java consomme beaucoup plus de mémoire en gâchant des ressources (par exemple le verou qui est inutile pour de très nombreux objets). Le C++ n'a pas ce défaut, il permet une utilisation beaucoup plus raisonnée de la consommation mémoire. En Java, tu ne peux pas faire propre et efficace en mémoire dans certaines situations. Un exemple simple, une matrice de nombres complexes : en Java ça utilise 2 fois plus de mémoire qu'en C++ sans aucune raison valable.

Peut être que la personne à laquelle tu réponds en a marre de justifier ce fait : Java bouffe une quantité de mémoire délirante. Les raisons sont connues :

1) tout objet contient un lock utilisé pour la gestion des synchronized. L'implémentation de Sun bouffe un mot (4 octets en 32 bits) par objet pour ce verrou (il existe des solutions alternatives, par exemple dans SableVM)
2) tout objet contient une référence vers sa classe pour que le typage dynamique fonctionne correctement (il s'agit du .class, en gros) => encore un mot
3) je n'ai pas lu les sources, mais je soupçonne la JVM de Sun de placer une référence vers la table des méthodes virtuelles dans chaque objet pour éviter la double indirection qu'on aurait si on passait par l'objet Class pour obtenir les adresses des méthodes en question => encore un mot

Sur une machine 32 bits, chaque objet contient donc 12 octets de gestion (au minimum), alors qu'en C++, on a en général seulement 4 octets de gestion (pour la table des méthodes virtuelles). Il y a en fait deux erreurs fondamentales de conception de la JVM :

- la gestion du parallèlisme au niveau de l'objet est loin d'être une panacée. Un système de verou externe ou un type spécial dont il faudrait hériter (dans l'esprit de Serializable) serait nettement plus adapté (cf à ce sujet les modifications qui seront intégrées dans la version 1.5, http://gee.cs.oswego.edu/dl/concurrency-interest/index.html(...))

- la manipulations des objets exclusivement par référence empêche de mettre en place des objets "lightweight" comme on en dispose en C++ (les objets sans méthodes virtuelles) et en C# (les structs). C'est d'ailleurs une source de plus de gaspillage de mémoire : si je veux un tableau de nombres complexes, j'obtiens en fait un tableau de références vers des nombres complexes, ce qui mange un mot de plus par objet, soit 16 octets sur une architecture 32 bits (contre 16 octets pour le contenu du nombre complexe !).

Bref, dire que ça consomme 4 fois plus est clairement exagéré, mais dire que ça consomme beaucoup plus est une réalité bien gênante pour Java (qui n'en reste pas moins un excellent langage).

Oui, sauf qu'appeler ça un memory leak, c'est du foutage de gueulle intégral. Oui, si on conserve une référence sur un objet, celui-ci n'est pas détruit. Grande découverte qui signifie donc qu'il faut faire attention à ce qu'on fait. Le développeur Java doit donc gérer ses objets proprement, rien de bien extraordinaire. Par contre, il ne gère pas la mémoire...

D'autant plus que Java3D est tres interessant car d'un niveau beaucoup plus haut qu'un simple bindings OpenGL.

Et c'est justement pour ça que ça rame. Java3D est sympathique, mais ne joue pas dans la même catégorie que OpenGL (et donc que Jogl, cf https://jogl.dev.java.net/(...)). En pratique, faire un moteur 3D performant, ça nécessite encore de l'assembleur ou une sorte de C (la programmation des shaders directement en assembleur ou en Cg ou un truc du genre), même avec OpenGL ou Direct3D qui sont des API pensées presque exclusivement pour les performances brutes. Si on veut faire du rapide en Java, il faut donc utiliser Jogl plutôt que Java3D.

Avec Thunderbird ou Mozilla mail, tu peux bien entendu empêcher le chargement des images distantes tout en conservant celui des images incluses dans le mail html lui-même. Ca n'enlève rien au fait que les mails HTML puent gravement, mais bon...

Pour les noms de bestiolles, l'anglais est parfois moins précis que le français. Par exemple, lobster désigne à la fois la langouste et le homard. Je crois que c'est la même chose pour manchot et pinguoin. Il me semble aussi que bien que dromadery existe, les anglophones utilisent souvent camel pour désigner à la fois le chameau et le dromadaire (deux bestiolles bien différentes, pourtant).

Bof. C'est incroyable ce que les gens restent collés versions antédiluviennes de Java alors que ça fait des années que le bytecode est compilé au vol. Les techniques mise en oeuvre dans les JVM modernes permettent des optimisations qui sont impossibles à réaliser avec une compilation statique, par exemple des suppressions de range checking, un inlining basé sur l'utilisation réelle des méthodes, etc. Le GC permet aussi des choses assez incroyables en terme d'efficacité de l'allocation et de la désallocation. Cela signifie que le passage par le bytecode et la compilation au vol permet d'avoir de meilleures performances qu'en C dans certaines applications qui tournent longtemps (du genre serveur). De plus, le volume de la JVM est très faible, contrairement à un code objet et son chargement est très souvent beaucoup plus rapide que celui du code objet correspondant. Moralité, oui, si tu lances un hello world, Java rame monstrueusement pour les raisons que tu évoques, mais on s'en fout, c'est un détail. Ce qui est important pour l'utilisation actuelle de Java (le serveur), c'est les performances sur une appli qui tourne longtemps. Et là, le
vrai problème, c'est la consommation mémoire délirante qui est du au fait qu'en Java il n'existe pas d'objets légers.

Le bytecode n'a aucun rapport avec le ralentissement et la consommation mémoire. Le premier vient essentiellement de la seconde qui est une conséquence du modèle objet de Java, pas du passage par un bytecode. Mais bon, comme de nombreuses personnes ici, tu écris sans savoir.

Tu t'auto contredis avec une grande maîtrise. Personne ne demande que le TCK devienne open source, mais bien que la RI le soit. Point final, ça empêche effectivement quelque chose qui n'est pas compatible Java de prétendre l'être. Donc, où est le problème ?

Ton histoire sur .Net est totalement inconsistante. Si la JVM de sun passe en GPL, tu crois que MS va linker .net avec cette JVM et donc passer tout .net en GPL ? Tu as forcé sur les substances illicites ou quoi ? Et MS faisait ça, ça serait la fête ! .net en GPL !

Sinon, je n'ai jamais dit que Python était mieux ou moins bien que Java, mais simplement que c'était un bon exemple d'un langage open source multiplateforme pour lequel il n'y a pas de fork.

Car mettre la "référence" en opensource, c'est augmenter fortement le risque de voir les différentes implémentation divergés. Et sur ce point aucune licenses accepté comme open source, ne permet de résoudre le problème :(

C'est du FUD de base, auquel SUN ne croit même pas puisqu'ils ont promu Tomcat au rang d'implémentation de référence pour les servlets et les JSP. SUN est propriétaire de la marque Java et peut donc empêcher son utilisation sans aucun problème. Il suffit donc de dire que seule la JVM distribuée par SUN sous licence open source s'appelle Java pour qu'on supprime toute confusion et risque d'éclatement. Comme l'indique très bien quelqu'un au dessus, de très nombreux langages open source existent et n'ont pas subi de fork (Perl, Ruby et Python, par exemple).

Oui et ils financent aussi Tomcat qui est tout de même l'implémentation de référence des JSP et des servlets, et qui est basé sur du code de Sun à l'origine.

Mon expérience personnelle avec kmail est que le mode offline ne fonctionne pas, ce qui est intolérable sur un portable ou quand tu as une énorme mailbox.

J'utilise Thunderbird+courier-imap et ça fonctionne nickel, avec filtrage sur le serveur. Je n'ai eu aucun soucis sur les dossiers et je n'ai jamais eu à faire des modifications à la main sur le serveur. Ceci étant, je n'utilise Thunderbird que depuis la version 0.5...

Il y a effectivement un petit soucis de notification, qui se règle en métant la variable use_status_for_biff à false:
user_pref("mail.imap.use_status_for_biff", false);
puis activer l'option de notification dans courier-imap.

J'ai mis du temps à trouver...

Ouai, bof. J'utilise courier-imap depuis plusieurs mois et j'avoue que je n'ai pas rencontré de bug avec thunderbird. De plus, courier-imap utilise le format maildir, ce qui facilite grandement les sauvegardes incrémentales et ce qui donne en général de biens meilleures perfs que uw-imap.

Mon expérience personnelle sous linux est que la version 0.6 démarre un peu plus rapidement que la 0.5 et semble globalement plus réactive.

A mon avis, thunderbird est de loin le meilleur client imap graphique sous linux. J'ai testé evolution, kmail et deux trois autres trucs dont je ne me rappelle même plus le nom et thunderbird les éclate en particulier en terme de qualité du support imap (en particulier le mode déconnecté qui fonctionne parfaitement, contrairement à celui d'évolution).

Alors la mise en page:

Les auteurs n'ont pas vraiment de prise sur la maquette...

L'intro, même si elle est bien faite, est un peu trop longue. Je suppose que la taille de l'article est limité, donc il vaut mieux utiliser la place pour les explications qui vont suivre..

Il n'y a pas vraiment de contraintes de places et dans l'article en question, l'intro n'a pas pris la place de la suite. Sinon, je trouve que les intros sont toujours trop courtes. Ici, nous avons voulu bien situer le problème pour que même si quelqu'un ne comprend rien à la suite, il obtienne une vague idée du but et de l'intérêt des réseaux bayésiens, pour décider de s'investir plus tard dans le domaine par exemple.

L'exemple de l'alarme : il y n'y a pas assez d'explications formelles sur les outils mahématiques utilisé, alors que celle sur l'exemple lui même (les voleurs et le camion) abondent. Peut être que beaucoup n'ont pas envie de se taper un cours de math, mais une semi-vulgarisation manque un peu d'intérêt : soit on explique les choses en détail pour pouvoir se passer d'autres doc, soit on en reste à un résumé rapide.

Je ne comprends pas de quoi tu parles. Oui, il n'y a pas de présentation formelle des probabilités, et alors ? Ca ne sert à rien pour faire les calculs et ça n'aide en rien dans la compréhension des mécanismes. Dire qu'une variable aléatoire est une fonction mesurable d'un espace probabilisé dans un espace mesurable ne me semble pas très intéressant pour les lecteurs de lm. Nous avons donc opté pour un résumé rapide et informel.

On ne comprend pas d'où sortent les résultats des tableaux (0.98, 0.05, 0.96...) il aurait fallu être plus clair sur ce qui est choisi arbitrairement et ce qui est calculé.

Autant je suis d'accord sur le fait que les valeurs numériques du premier tableau auraient dues être rappellées dans le texte pour clarifier, autant je ne comprend pas trop la fin de la remarque, étant donné qu'il est clairement indiqué que le tableau 3 est obtenu par calcul.

Les choix de ces valeurs vers la fin ne sont pas très bonnes pour l'exemple : on a pas besoin de faire de calcul pour savoir que l'alarme dans un coin avec peu de voleur et beaucoup de camion risque de faire plus de fausse alerte qu'un dans un coin avec beaucoup de voleur et peu de camion ; un exemple plus ambigu mettant en avant l'utilité d'un calcul quantitatif aurait été plus pertinant. Il aurait été plus clair d'indiquer clairement dès le début ce qu'on veux calculer et à partir de quoi on le fait, çad quelles sont les probabilités déjà connues ; c'est un peu troublant d'être dans le noir toute cette partie et de ne comprendre le sens général qu'à la fin.

Au contraire, les valeurs sont là pour montrer qu'on obtient algorithmiquement un résultat logique et intuitif, et donc qu'on peut reproduire informatiquement le raisonnement humain dans l'incertain. D'autre part, le but de l'exemple est donné dès le départ, je cite "nous allons calculer la probabilité qu'un cambriolage soit en cours dans un magasin dont l'alarme vient de se déclencher". Le fait qu'on indique pas ce qui est connu est parfaitement voulu, il s'agit de faire découvrir au fur et à mesure ce dont on a besoin. Il ne s'agit pas d'un exercice de math...

Le cas général, est très résumé et se contente de renvoyer au référence en fin d'article, alors qu'une implémentatin avec un algo et du code aurait été le bienvenu

Il n'y a rien à dire de particulier sur le cas général, d'ou une présentation très rapide. D'autre part, l'algorithme de base est décrit, donc je ne vois pas le problème. Il est vrai que nous n'avons pas donné d'exemple de code (franchement sans intérêt, vu la masse de code annexe qu'il faut produire pour arriver à un truc super basique résumé par un produit et donc une boucle!). L'ommission du junction tree est délibérée : cet algorithme est extrêmement complexe et demande un article entier de description. De plus, le but de l'article n'est pas de faire programmer un réseau bayésien mais de faire comprendre les concepts.

- enfin, on reprend encore le cas du début en le complexifiant, ce qui aurait plus eu sa place à la suite de la première partie.

Et bien non, justement. Le but est d'illustrer l'intérêt de réseaux plus complexes, pas de compliquer pour le plaisir.

- Il est de plus assez embrouillant de vouloir sortir le nom de tous les algos et techniques en les résumant en une ligne.

Le but de la phrase en question est de donner des pistes à des lecteurs qui connaîtraient un des algorithmes cités, c'est tout.

Bon tout ça en fait, ça fait pas mal de critiques qui sont un peu confuses, et d'autres lecteurs pourraient en fait faire des critiques exactement inverses. Pour résumer je dirais que l'article est trop long pour une introduction, et sans véritable exemple (code, algo...) pour une implémentation, même simple. Il aurait fallu faire un choix clair et s'y tenir.

Le choix était très clair : une introduction qui présente les concepts et les techniques de base sans enfumer le lecteur (i.e. sans lui faire croire qu'il peut tout comprendre en évitant certains concepts mathématiques difficiles). L'algo de base est présent (c'est la section "inférence dans un réseau") et le code ne présente aucun intérêt. De plus, c'est un leurre de croire qu'on peut programmer des réseaux bayésiens sans maîtriser le sujet et l'absence de code est là pour dissuader les lecteurs de le faire.

Voilà, je critique, mais j'espère avoir été constructif, et il y a un peu de mauvaise foi car j'ai quand même trouvé l'article intéressant! :-)

Merci pour ces critiques.

-Découvrez les réseaux Bayésiens
C'etait un sujet qui m'interessait enorment, mais contrairement aux autres articles sur l'ia, je le trouve pas tres abordable.

J'ai fait de mon mieux, mais j'avoue que le niveau de maths est largement au dessus de celui des articles précédents. Je ne savais vraiment pas comment faire.

La première partie de l'explication est assez confuse et on ne comprend pas trop où l'auteur veut en venir

Est-ce que tu pourrais préciser tes critiques, que je fasse mieux la prochaine fois ? Par exemple, quelle partie désignes-tu par première partie ? L'exemple de l'alarme dans son ensemble, ou simplement le début de cet exemple ?

Dans Big Fish, elle se débrouille très bien. C'est sur que dans Taxi 1 et 2 (j'ai échappé au 3), c'était pas la joi. Mais bon que faire dans des merdes pareilles ?

Parce qu'en C++ on n'a pas pour objectif d'être un intégriste de l'objet

J'adore ce genre de chose. Tu pourrais aussi me traiter d'autre chose, je laisse ton imagination débridée choisir parmi les nombreuses possibilités.

Faire des contrats de cette manière c'est utile, et pas forcément parce qu'il y a un besoin objet derrière. Un point de vue obtus ne concevant qu'objet ne peut pas le comprendre.

De retraite en retraite, la défaite s'approche. Tu es formidable. Depuis quelques posts, tu refuses de donner un exemple pertinent. Alors que j'ai accepté de reconnaître mes erreurs (par exemple sur l'héritage multiple dont tu as donné un excellent exemple d'application), tu t'enfonces, tellement lamentable que tu passes aux "insultes". C'est affligeant. Je supposes que tu ne viens pas ici pour débatre, enrichir ta connaissance et celle des autres, mais lancer des affirmations gratuites puis terminer en attaques personnelles...

Ce n'est pas une hérésie parce que C++ n'a pas la prétention (contrairement à Java) d'être exclusivement orienté objet. Ça ne te plait pas dans une approche objet, ne l'utilise pas dans une approche objet. Je ne m'en sers pas dans une approche purement objet, ce n'est pas pour ça que je compte m'en passer ailleurs.

Tu peux toujours qualifier mes propos de conneries ou d'intégrisme de l'objet, ça ne change rien au fond du problème (et ça ne te grandit pas, d'ailleurs). Tout le monde, praticien comme théoricien, reconnaît le grand intérêt des langages typés. Le système de type du C++ est bancal car la sémantique d'un objet diffère selon le mode de passage, ce qui pertube les possibilités de prédiction du comportement d'un programme. Le reconnaître n'a aucun rapport avec un quelconque intégrisme, il s'agit simplement d'une reflexion critique sur le design d'un langage. C++ a été conçu par quelqu'un qui ne connaissait pas bien les langages objets et surtout qui confondait les concepts (héritage par exemple) avec leur implémentation (table de méthodes virtuelles). Le résultat est utile en pratique car C++ permet une énorme abstraction par rapport au C, mais il est aussi très criticable. La mauvaise conception du C++ le rend par exemple beaucoup plus difficile à apprendre que des langages nettement plus riches comme Eiffel et Sather. Mais comme ces derniers ont une syntaxe à la Pascal, ils n'ont pas le succès mérité. Heureusement que Java et C# sont arrivés.

Merci pour cet exposé extrémiste « Seul l'objet existe ».

Où est-ce que tu as lu ça ?

il n'est pas possible de déposer un brevet sur un principe sans pour autant dévoiler comment ca fonctionne derriere?

Ba non, c'est le principe même du brevet : tu révèles ton invention et l'état la protège.

Eh bien si pour toi l'approximation final = non-virtual te convient, ne prend pas cet argument comme inconvénient, que veux-tu que je te dise.

Serait-ce une retraite honteuse ? Tu ne réponds toujours pas sur le fond : pourquoi final ne permettrait il pas de faire proprement cette histoire de contrat ? Qu'est-ce qui n'est pas propre dans ma construction (oui, je sais, elle est limitée par l'absence d'héritage multiple) ?

Je donnais un exemple à une personne, au cours de la discussion on a parlé de 2 autres aspects encore plus genants dans le meme idiome, si ce sont les seuls qui te paraissent pertinents ne tient compte que de ceux là.

Ce sont surtout les seuls réels. Tu as trouvé un argument très pertinent pour justifier l'héritage multiple : bravo, ce ne pas si évident et je trouve ton exemple très convainquant (et je retire donc mon ". C'est sûr, quand on ne comprend rien à la conception objet, c'est très utile." qui visait l'héritage multiple). Mais pourquoi t'obstiner sur une interprétation foireuse de ton propre exemple ? Donne moi un seul exemple dans lequel l'hérésie du C++ (je peux redéfinir une méthode qui n'est pas virtuelle) permet de faire plus propre que Java. Je suis sûr que tu n'en trouveras pas car c'est une des conneries fondamentale du C++, dont le principal vrai défaut est d'avoir un système de types objets plus que bancal (et pas de GC).

final n'est pas acceptable quand on veut du non-virtual uniquement

Mais donne le ton exemple ! C'est quoi ton problème, tu n'as pas d'exemple, c'est ça ? Par ce que franchement, je ne vois pas de problème lié à final/virtual (éventuellement aux différences de sémantique entre les privates et bien entendu en raison de l'absence d'héritage multiple).

Tu as bien dit au départ : "les fonctions automatiquement virtuelles : impossible de faire de la vérif de pré/post condition derrière l'interface, qui est l'endroit où les faire (ça ne doit pas être laissé à la classe qui implémente)."

Voici donc un exemple en Java. Bidule est une "interface" dans laquelle on implémente les pré/post condition.

public abstract class Bidule {

  protected abstract void versionInterne();

  public final void versionExterne() {

    // précondition

    versionInterne();

    // postcondition

  }

}

Truc est une implémentation de l'interface.

public class Truc extends Bidule {

  protected void versionInterne() {

    System.out.println("Et hop");

  }

}

Quelles sont les différences avec un design pattern équivalent en C++ :

1) pas d'héritage multiple, donc des limitations pratiques du schéma en Java : je suis d'accord, l'héritage multiple apporte beaucoup sur ce genre d'exemple

2) il est impossible de mettre versionInterne en private en Java : soit, c'est une limitation, mais personnellement elle ne me choque pas plus que ça.

Tu en trouveras sûrement d'autres, mais je ne vois toujours pas en quoi avoir des fonctions virtuelles par défaut pose un problème sur cet exemple. Et je maintiens qu'il n'y pas de différences importantes entre final/virtual. Ce que tu as mentionné plus haut (le fait qu'on puisse redéfinir une fonction même si elle n'est pas marquée virtual en C++) est une différence factuelle, mais elle permet de telles horreurs sémantiques en C++ que tout programmeur qui se respecte devrait l'oublier.

Juste le fait que final n'est pas l'exact opposé de virtual. C++ n'empêche pas de "redéfinir" une fonction non virtuelle dans une sous-classe. Elle ne sera pas prise dans une recherche dynamique, mais elle peut exister.

Effectivement, j'avais oublié cette horreur. Avoue que parler ensuite de choses pas très propres au sujet du Object de Java, est un peu unilatéral, comme point de vue. Parce que franchement, le modèle objet du C++ qui permet ce que tu viens de rappeler ainsi que la perte du type de l'objet lors du passage par valeur, est vraiment immonde (ou pas propre, comme tu veux).