boubou a écrit 1384 commentaires

  • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 2.

    le C# a introduit les événements beaucoup plus facile à utiliser qu'en Java par exemple...

    Tout le monde n'est pas d'accord. Perso, je préfère les classes anonymes aux delegates. Dans les cas simples (une seule méthode), les delegates sont moinx verbeux, mais ils ne peuvent pas s'adapter aux cas évolués...
  • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.

    Toutes mes excuses, je t'ai confondu avec l'autre Nicolas, celui auquel je répondais au départ.
  • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 2.

    J'ai la désagréable sensation que tu ne comprends pas trop de quoi tu parles.

    Ce n'est pas seulement le chargement de classes qui est long,c 'est aussi le fait qu'à chaque appel de la méthode définissant la classe, on crée une nouvelle instance. Et ça, c'est long.

    Je ne vois pas en quoi les classes anonymes changent quelque chose à ça. Pour programmer une classe anonyme, il faut se baser sur une interface. Si tu n'implémentait cette interface par une classe anonyme, tu le ferais par une classe normale et tu aurais exactement le même nombre de chargement de classe et de création d'instance, sauf si tu programmes comme un porc, ce qui n'a rien à voir avec les classes anonymes.

    Quant aux pointeurs sur fonctions, ils sont disponibles beaucoup plus facilement en utilisant correctement les interfaces. On appelle çàa du design by contract ;-)

    Oui, donc tu n'as rien compris. Parce que pour faire une classe anonyme, il faut une interface...

    Et pour les vrais porcs, il y a aussi l'objet Method qui, lui, est un vrai pointeur sur fonction, ou plutôt pointeur sur méthode.

    Les pointeurs sur fonction obtenus grâce aux classes anonymes sont typés statiquement, ce qui n'est pas le cas des appels par l'objet Method. De plus, celui-ci nécesite aussi un création d'objet et, étant basé sur l'api de réflexion, il rame. Bref, tu racontes vraiment n'importe quoi.
  • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.

    un mapping de ta base de données vers des objets. Super ultra puissant. Et les Entity Bean CMP, c'est quoi, à ton avis ? Et JDO ? Si tu veux parler des EJB, je te suggère de lire d'abord un livre dessus.
  • [^] # Re: perfs de java

    Posté par  (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 2.

    Oui, la partie graphique est en général plus lente sous linux, mais bon, pour le reste, ce n'est pas si clair. Voir par exemple le volanomark (http://www.volano.com/report/index.html(...)) ou linux se défend bien. La conclusion du dernier test de volano est d'ailleurs un must...
  • [^] # Re: perfs de java

    Posté par  (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 2.

    Oups, j'ai oublié la moitié de ma réponse. Quand tu compiles ATLAS, la meilleure bibliothèque de calcul matriciel actuelle, ça prend en gros 2 heures (même sur une machine très récente), parce que le code est optimisé avec des techniques typiques des JIT (chronométrages de boucles, tests sur l'empreinte mémoire, etc.). Or, ATLAS ne fait rien, en terme de fonctionnalités : ça se limite à des produits de matrices. Imagines le temps de compilation pour une grosse appli.
  • [^] # Re: perfs de java

    Posté par  (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 2.

    Nous nous sommes mal compris. Le code natif obtenu par le JIT peut être meilleur qu'un code compilé statiquement, par exemple en inlinant certaines méthodes alors qu'a priori (en analyse statique) on pouvait croire que ça ne valait pas le coup, en supprimant au vol certains tests (sur les bornes d'un tableau par exemple), etc. Les analyses statiques sur un code sont très coûteuses et beaucoup de compilateurs ne peuvent pas se permettre de les faire. Quand tu interpètes du code, faire une analyse en même temps ne coûte pas énormément plus, ce qui permet de faire des choses difficiles à envisager en statique.
  • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.

    Tu sais que l'API de .NET est protégée par Microsoft par des brevets. Tu le sais, n'est-ce pas ? Donc tu sais que l'idée même d'avoir autre chose qu'une machine virtuelle interopérable est une vaste blague. Et que si on se limite justement à une machine virtuelle, ça fait des années que des versions open source de la JVM existent et tournent très bien.

    Tu sais aussi sûrement que ce qui compte dans une plate-forme de développement, ce n'est finalement pas la machine virtuelle, ni même le langage (oui, C# c'est pas mal, tout à fait du même niveau que Java, avec des + et des -), mais surtout les API. Alors le projet Mono me fait bien rire. Ca fait des années que classpath tente d'atteindre java 1.2 et ils n'y sont pas encore (même si eclipse peut tourner en 100% open source), alors que les api Java ne sont même pas protégées par Sun.
  • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.

    . Les EJB, c'est une espèce de merde noire où il faut, pour s'en sortir, faire appel à des vraies usines à gaz que sont les serveurs d'application.

    Mon pauvre ami. Et comment fais tu pour développer une application transactionnelle basée sur un système à échange de messages sans te faire chier comme un rat mort ? Parce qu'à part les J2EE et .Net, franchement, je ne vois pas.

    C'est bien de défendre Java. C'est mieux de le faire bien.
  • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 0.

    Réexplique moi pourquoi tu dis toujours ça ?
  • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à -2.

    Ta bien raison de ne pas être convaincu, parce que c'est une grosse connerie.
  • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 2.

    surtout si la méthode peut être "inlinée"

    Oui, enfin, les classes anonymes et internes, c'est fait pour implémenter des pointeurs sur fonction objets, alors dans ce genre de cas, l'inlining est par définition impossible. Donc ça ne change rien. D'autre part, je ne suis pas sûr du tout que le chargement des classes prennent vraiment du temps en Java et de toute manière, c'est négligeable sur un programme qui tourne plus de quelques secondes.

    Ceci étant, si le sens de ton post est de dire qu'il manque des pointeurs sur fonction en Java, c'est un point de vue qui se défend, mais un tel ajout demanderait la modification de la JVM, alors bon...
  • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 2.

    Oui, enfin, quand tu utilises une classe anonyme pour implémenter un listener, tu ne crèe qu'une seule instance, donc je ne vois pas où ça rame.

    Sinon, je suppose que tu décris un bug d'Eclipse, parce qu'une classe interne accède directement à tout le contenu de la classe englobante, même aux variables privées. C'est d'ailleurs un des intérêts des classes internes, par exemple pour implémenter des itérateurs.
  • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.

    COLT (http://hoschek.home.cern.ch/hoschek/colt/(...)), bibliothèque de calcul écrite en Java et utilisée par le CERN.
  • [^] # Re: Légende urbaine : un alligator dans le ramasse-miettes

    Posté par  (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.

    allez, une semaine pour Perl

    Quel humour ! Tu maîtrises les regexp Perl en une semaine ? Tu maîtrises la sémantique délirante de Perl en une semaine ? Tu peux relire un programme évolué en Perl en une semaine ? Quel pipo lamentable.
  • [^] # Re: perfs de java

    Posté par  (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 1.

    abandonner la JVM au profit de GCJ

    Bof. Rien ne prouve qu'un code compilé en natif soit plus efficace qu'un code compilé en JIT (tu me diras qu'on pourrait avoir du JIT dans GCJ (on est d'ailleurs obligé pour faire du vrai Java), mais bon, ça devient n'importe quoi). En "regardant" un code java tourner, on peut faire des optimisations très sioux qui ne peuvent pas être faites statiquement...
  • [^] # Re: perfs de java

    Posté par  (site web personnel) . En réponse à la dépêche Légende urbaine : un alligator dans le ramasse-miettes. Évalué à 6.

    Non, c'est simplement que les américains n'ont pas de mot pour dromadaire. Pour eux, un chameau et un dromadaire sont des camels. Comme lobster qui désigne à la fois le homard et la langouste...
  • [^] # Re: Brevets : IBM entre dans la danse ?

    Posté par  (site web personnel) . En réponse à la dépêche Brevets : IBM entre dans la danse ?. Évalué à 1.

    D'accord avec toi, mais avec un petit bémol pour l'aspect chipset. Pour faire une carte mère compatible Pentium récent, il faut l'accord d'Intel qui fournit d'ailleurs des licences à ses concurrents comme VIA par exemple. Mais bon, c'est du hardware très récent, tout ça...
  • [^] # Re: Revue de Presse - Juin 2003

    Posté par  (site web personnel) . En réponse à la dépêche Revue de Presse - Juin 2003. Évalué à 3.

    D'ailleurs si quelqu'un connait un bon magazine sur la programmation je serais heureux de le connaitre. (j'ai essayé 'Programmez' mais je trouve ca moyen, et les dossiers de logins sont encore trop concis - malgré une nette augmentation du volume récemment)

    A mon avis, le mieux est Linux Mag, mais avec deux bémols : il faut suivre les séries d'articles et les thèmes abordés sont assez spécifiques (genre programmation QT, gtk, etc.).

    Ceci étant, je ne suis pas certain que la programmation soit abordable facilement dans un magazine. Personnellement, en dehors du web, je préfère largement les bouquins, on peut aller dans les détails.
  • [^] # Re: Droit d'auteur et travailleurs

    Posté par  (site web personnel) . En réponse à la dépêche Droit d'auteur et travailleurs. Évalué à 1.

    Et la constante multiplicative, et le caractère asymptotique du O(n log n), ils sont partis où ? Ton estimation de cycles d'horloge, elle ne veut rien dire si elle se base sur la complexité théorique du problème et non sur la complexité pratique d'un algorithme...


    Attention de ne pas confondre la complexité d'une tâche qui est le coût asymptotique minimal pour cette tâche (i.e., avec le meilleur algorithme) et le coût d'un algorithme. On peut montrer que dans le cas général, le problème du tri est de complexité n log n. On peut d'autre part exhiber des algorithmes dont le coût est évaluable de façon exacte et est en n log n (je ne connais pas de tête la constante, mais on peut la calculer). On peut donner des encadrements très précis pour un algorithme donné. On a l'impression que tu n'as jamais fait ça vrai...

    Disons : procédés appliqués à un domaine précis pour obtenir des résultats précis, et mis au point par la maturation progressive d'un savoir-faire. Contrairement à la recherche scientifique où l'objectif est l'élargissement de l'horizon intellectuel et théorique, non la résolution de problèmes concrets et immédiats. Note que certaines disciplines peuvent se situer à la frontière entre les deux (exemple : des résultats mathématiques sont mis à profit pour s'assurer de certaines caractéristiques des réseaux de neurones).


    Mon pauvre ami, tu délires. L'objectif de la recherche scientifique n'est pas l'élargissement de bla bla bla par opposition à la résolution de problèmes concrets. La recherche, c'est l'ensemble de tout ça, à la fois la résolution de problèmes pratiques mais aussi l'extension du savoir en général. Pour reprendre ton exemple des réseaux de neurones (c'est mon boulot, tu sais...) tu es largement à côté de la plaque. Il n'y a pas de mise à profit de résultats de maths pour s'assurer des cractéristiques des rns (ce qui ne veut rien dire, je dirais plutôt propriétés). En fait, les problèmes d'apprentissage en général ont été placés dans un cadre théorique par des gens du domaine qui avaient une bonne formation mathématique, ça a eu pour conséquence l'obtention de résultats radicalement nouveaux pour les statisticiens (par exemple) qui ont repris les problèmes. Les personnes qui obtiennent ces résultats sont à la fois des informaticiens (qui travaillent sur l'apprentissage automatique, sur la reconnaissance de forme, etc.), des statisticiens, des physiciens, etc.

    Tu sembles ne pas savoir de quoi tu parles, ce qui est bien malheureux. Sinon tu saurais que le Data Mining n'est pas un ensemble de techniques mais bien une branche de l'informatique dans laquelle on trouve de la bidouille mais aussi des algorithmes étudiés théoriquement (convergence prouvée, complexité connue, etc.) par les membres de la communauté et pas par une sorte d'équipe de mathématiciens qu'on appellerait pour faire ça. C'est la même chose en IA en général, etc. Les mathématiques sont le langage de formalisation commun aux sciences dures. D'autre part, elles engendrent leur propres questions en plus de celles qui sont posées et résolus par les gens qui "parlent" en mathématiques dans leur domaine.
  • [^] # Re: Droit d'auteur et travailleurs

    Posté par  (site web personnel) . En réponse à la dépêche Droit d'auteur et travailleurs. Évalué à 1.

    Et comme disait Master-dik, on peut faire remonter l'arithmétique à la comptabilité. De même, on peut faire remonter les probabilités aux jeux de hasard ou à l'actuariat, etc. Tout ça ne conduit à rien de bien intéressant. Les problèmes algorithmiques modernes, essentiellement des problèmes de bornes inférieures sont des problèmes d'informatique. Il s'agit en général de trouver un nouvel algorithme qui fait mieux qu'un autre (et donc de faire avancer la résolution d'un problème en terme d'implémentation) ou de montrer que dans certaines conditions, on ne peut pas faire mieux qu'une certaine borne, ou encore d'exhiber un algorithme qui atteint une borne. Bref, c'est de l'informatique.
  • [^] # Re: Droit d'auteur et travailleurs

    Posté par  (site web personnel) . En réponse à la dépêche Droit d'auteur et travailleurs. Évalué à 1.

    Comme Boubou, tu confonds la prouvabilité d'une propriété (il existe une méthode en temps polynomial) avec l'exhibition d'une solution intéressante en pratique (je sais décrire une méthode qui convient dans les cas considérés).

    T'inquiètes, je ne confonds pas. Je constate simplement que toutes les tentatives connues pour montrer que P=NP exhibaient justement une solution polynomiale d'un problème NP (fausse jusqu'à présent). Je ne conteste pas la possibilité de trouver un moyen détourné pour montrer que P=NP, mais je n'y crois pas, c'est tout.
  • [^] # Re: Droit d'auteur et travailleurs

    Posté par  (site web personnel) . En réponse à la dépêche Droit d'auteur et travailleurs. Évalué à 1.

    Non, pas du tout. D'ailleurs, on peut faire un tri en mieux que n log n, sous certaines contraintes.

    Et ? Dans le cas général, on ne peut pas faire mieux que n log n, ce qui donne bien un temps minimal, il suffit de traduire ça en terme de cycle d'horloge.

    Je ne vois pas en quoi la complexité théorique d'un problème change le choix que tu feras entre des algorithmes de complexités pratiques connues.

    Moi non plus, je ne parle pas de ça. En effet, je fais référence à certains résultats comme par exemple le coût de n log n pour le tri qui se traduit par des bornes comparables pour le calcul d'enveloppe convexe et d'une façon détournée par des bornes pour les triangulations de delaunay. Comme on sait maintenant qu'on ne peut pas faire le calcul en mieux que n^{d/2} (d est la dimension de l'espace), on cherche des algorithmes qui calculent des approximations de la solution, alors qu'on perdrait notre temps à chercher des algos exacts si on ne connaissait pas la borne...

    Certes. Mais les gens qui travaillent sur toute une partie de l'algorithmique n'ont pas comme objectif la résolution de problèmes informatiques précis, je pense. Je suis bien d'accord qu'il y a toujours des retombées potentielles (comme avec n'importe quelle branche des maths).


    Ca prouve juste que tu te trompes. Je connais pas mal de gens qui bossent en algorithmique et c'est très souvent avec des motivations pratiques, parfois lointaines, il est vrai.

    Ce sont des (ensembles de) techniques informatiques.

    Ouarf ! Je ne comprends pas ce que tu veux dire par technique.
  • [^] # Re: Droit d'auteur et travailleurs

    Posté par  (site web personnel) . En réponse à la dépêche Droit d'auteur et travailleurs. Évalué à 1.

    Pas du tout. Si quelqu'un prouve que P=NP, tout le travail de réduction qui a été fait (rapporter un problème NP à un autre) permet de résoudre tous les problèmes NP en temps polynomial, par combinaison de l'algorithme exhibé pour résoudre P=NP et de l'algorithme de réduction.

    D'autre part, les bornes inférieures (du genre P!=NP ou des choses plus spécifiques) sont extrêmement utiles pour la pratique. Par exemple, le fait de savoir qu'on ne peut pas faire un tri en mieux que n log n permet de donner des temps minimaux d'exécution, de se diriger vers un algo ou un autre, etc. Il ne faut pas non plus négliger l'effet "j'évite de perdre mon temps". Par exemple, il est salutaire qu'on sache qu'on ne peut pas faire de mouvement perpétuel !

    Encore une fois, l'implémentation n'est qu'un aspect de l'informatique. L'informatique, c'est la science du traitement et de la manipulation de l'information. Quand on fait du data mining, on fait de l'informatique, de même que pour l'IA, etc. Les maths ne sont ici qu'un langage de formalisation d'un domaine scientifique. Je ne fais pas de l'anglais parce que j'écris mes articles scientifiques en anglais...
  • [^] # Re: Droit d'auteur et travailleurs

    Posté par  (site web personnel) . En réponse à la dépêche Droit d'auteur et travailleurs. Évalué à 1.

    Dans ce cas, l'arithmétique ayant été créée pour satisfaire aux besoins des marchands de l'Antiquité, on peut dire que l'arithmétique est une branche du commerce.

    Et alors ? C'est effectivement le cas à l'origine. Par contre, l'arithmétique a pris son essort en dehors de l'aspect économique pour donner une branche des maths indépendante. Je ne vois pas de contradiction là dedans. On peut en dire de même pour les probabilités, plus ou moins issue de motivation en assurance. Au départ, les probas étaient une sorte de branche de l'assurance, mais l'évolution a fait qu'elles sont devenues un outil tellement utile partout qu'on peut les considérer comme une branche des maths. Elles ont d'ailleurs conduit à des questions qu'on peut qualifier de purement probabiliste, sans autre intérêt que l'avancement de la théorie des probabilités.

    Au contraire, l'algorithmique n'a rien d'indépendant. Le but était et reste l'analyse de la résolution de problèmes par ordinateurs ou plus généralement par des dispositifs "théoriques" comme les machines de Turing.