Sympa comme page

• [+] [^]Re: Sympa comme page

  Posté par zeDek () le 23/05/2002 à 13:10. (lien). Évalué à -3.

  Ah toutafé : Prolog et Lisp ROX grave !!

Précisions et compliments

• [^]Un peu falot mais...

  Posté par Moby-Dik () le 23/05/2002 à 18:46. (lien). Évalué à 0.

  En effet, si vous souhaitez faire du prototypage sur un protocole réseau, il pourra être intéressant de le faire en java, alors que l'implémentation finale en C, python (?) ou autre pourra peut-être plus performante...
  
  Excelllllent comme troll :)
  Surtout, on se demande en quoi faire un prototype en Java est plus facile qu'en C (sauf si bien sûr on ne maîtrise pas ce dernier) ! Franchement si tu veux faire un prototype vite fait de bidule réseau, prends un langage de scriptage offrant l'API désirée, après le choix dépend de tes goûts perso (Perl, Python... ou je ne sais quoi d'autre).

Sympa ce comparatif

• [^]Re: Sympa ce comparatif

  Posté par Benoît Sibaud (Jabber id, page perso, ) le 23/05/2002 à 13:20. (lien). Évalué à 12.

  Il serait surtout bon que la communauté s'investisse plus dans le Java libre :
  - JVM libres : ORP, kissme, Kaffe, Japhar
  - bibliothèques standards : Classpath, Classpathx
  - GCJ, Jikes
  - Mauve pour tester tout ça
  - et des bibliothèques sympas : JSX (GPL) pour la sérialisation <-> XML, Piccolo (LGPL) pour l'XML, Lumberjack (LGPL) pour loguer, etc.
  
  http://www.debian.org/doc/manuals/debian-java-faq/(...)
  « the SCSL is "about as free as the former Soviet Union" »

• [^]Re: Sympa ce comparatif

  Posté par Nelis (page perso, ) le 23/05/2002 à 13:34. (lien). Évalué à 10.

  Java a beau etre un des languages interpretes les plus rapides du comparatif (par contre cote occupation memoire c'est beaucoup moins bien).
  Tant qu'il aura des problemes comme ca: www-106.ibm.com/developerworks/java/libr
  je ne suis pas pres de me remettre a Java: beaucoup trop de bugs dans les librairies standards!
  
  
  Je ne vois pas le rapport entre l'article vers lequel tu pointes et les bugs dans les librairies standards ... Je ne dis pas que Java n'a pas de bugs dans ses librairies, il y en a des tonnes comme sans doute dans QT ou la libc ... Mais rien qui ne rende Java inutilisable, loin de là, je ne programme qu'en Java depuis deux ans et aucuns bugs ne m'a jamais empêché de faire quelquechose ... Quant au problème du double-checked locking, comme il est dit dans l'article ce n'est pas un bug, mais un comportement dû au modèle de mémoire utilisé dans Java. Et la solution est toute simple tu n'as qu'à déclarer toute ta méthode getInstance() synchronized ...

  --
  Vache qui rit, à moitié dans son lit

  • [^]Re: Sympa ce comparatif

    Posté par François BOTTIN () le 23/05/2002 à 14:15. (lien). Évalué à 9.

    C'est vrai qu'aujourd'hui, avec les dernières JVM, il n'est plus utile d'avoir recours au double-checked locking étant donné que le coût des blocs synchronized a fortement baissé.
    
    Lorsque j'ai entendu parler de ce problème, j'ai voulu voir si devoir faire deux tests ne faisait pas perdre le temps gagné en ne passant pas dans un bloc synchronized. Résultat des courses avec la JVM 1.4, que ça soit en interprété ou avec hotspot (client et serveur) : laisse tomber, c'est quasiment la même chose. Donc autant déclarer toute la méthode synchronized.
    
    De plus, une petite recherche dans la base de données de bugs chez SUN montre qu'il n'existe aucun bug ouvert ressemblant à ça ... Il a probablement été résolu (du moins pour la JVM de SUN) : http://search.java.sun.com/Search/java?qt=+%2Bstate%3Aopen+%2B%22do(...) (il faut être enregistré (gratuit) sur le JDC pour accéder à cette page)

  • [^]Re: Sympa ce comparatif

    Posté par reno () le 23/05/2002 à 15:18. (lien). Évalué à 4.

    >Je ne vois pas le rapport entre l'article vers lequel tu pointes et les bugs dans les librairies standards.
    
    Exact, l'article parle de bug de JVM, mais en plus il y a des bugs de la librairie standard.
    En 98 j'ai essaye d'utiliser Java (surtout Swing)
    --> degoute.
    En plus Sun met un temps dingue pour les corriger ses bugs: il faut compter 2-3 ans pour des bugs pour lesquels des milliers de personnes ont vote dans la BugParade..
    
    > Mais rien qui ne rende Java inutilisable, loin de là,
    Ca depend des domaines: essaye de faire des IHM ou d'imprimer des trucs non-triviaux et on en reparle.
    
    > Quant au problème du double-checked locking, comme il est dit dans l'article ce n'est pas un bug, mais un comportement dû au modèle de mémoire utilisé dans Java.
    
    Mouais c'est une drole de feature quand meme!
    Ca, plus le fait que l'affectation d'un long est non-atomique suivant les JVM.
    Il peut tres bien affecter les 32-bits de la partie haute puis etre interrompu et ensuite seulement affecter la partie basse.
    Cf le meme site.
    
    > Et la solution est toute simple tu n'as qu'à déclarer toute ta méthode getInstance() synchronized ...
    
    Certes dans tout les cas, un bon synchronised au bon endroit resout le probleme, mais avant encore faut-il trouver ou se situe le probleme!
    Le deboguage d'application multi-threadee avec des comportements aussi bizarre des JVM doit etre coton..

    • [^]Re: Sympa ce comparatif

      Posté par Sébastien Koechlin () le 23/05/2002 à 15:55. (lien). Évalué à 9.

      Certes dans tout les cas, un bon synchronised au bon endroit resout le probleme, mais avant encore faut-il trouver ou se situe le probleme!
      
      C'est ridicule, si on n'est pas capable de voir qu'il va y avoir un problème d'accès concurrent dans ce cas trivial, il ne faut pas espérer produire des applications multi-threads, ça n'a rien de propre à Java.
      
      En 98 j'ai essaye d'utiliser Java (surtout Swing) --> degoute.
      
      Je suis tout à fait d'accords avec toi, Swing est une horreur, en 2002, ce n'est toujours pas résolu. Les machines ne sont toujours pas suffisement puissantes pour faire tourner ces usines à gaz de manière aussi fluide qu'une appli gtk ou qt. IBM a fait du beau boulot avec un truc bien plus léger écrit pour Eclipse.

    • [^]Re: Sympa ce comparatif

      Posté par Luc Bourlier () le 23/05/2002 à 16:35. (lien). Évalué à 2.

      > En 98 j'ai essaye d'utiliser Java (surtout Swing)
      ca fait 4 ans maintenant, ce qui est une duree relativement longue en infomatique, Swing c'est beaucoup ameliore depuis, surtout avec la version 1.4.
      
      > Ca depend des domaines: essaye de faire des IHM ou d'imprimer des trucs non-triviaux et on en reparle.
      Pour ce qui est de l'impression des trucs non-triviaux, je ne pense pas que tu puisse faire beaucoup plus de chose avec la seulement la libc. Si tu veux imprimer des trucs complexe en C, tu utiliseras une librairie specifique, c'est la meme chose en Java.
      IHM, cf plus haut. Et sinon, AWT/Swing n'est plus la seule lib graphique dispo pour Java. IBM developpe SWT, une librairie graphique Java pour win32/motif/gtk/... qui utilise au maximun les widgets natif de la platforme, par opposition a Swing qui en emule la plus grande partie.
      
      En ce qui concerne la correction des bugs par Sun, je ne pense que ca prennent 2 a 3 ans en generale, meme si c vrai qu'ils ont l'air moins reactifs que la plupart des projets OSS.
      D'un aute cote, Il me semble que Sun propose son implementation comme une implementation de reference, pas comme la 'super-VM-Java-rapide-sans-bugs-de-la-mort-qui-tue', d'autre societes proposent des implemtations de la JVM, notament IBM avec deux version : une version de la 1.3.1 Sun modifie (corrige ?) et J9 qui est une implementation 'from scratch'. Il ya surement d'autre JVM disponible sur le marche, mais je ne les connais pas.
      
      
      Ceci dit, j'ai comme l'impression bizarre ce que tu ecris vient de 'on-dit', que tu n'as jamais reelement fait de developpement en Java (ou, pas depuis au moins 4 ans).

      • [^]Re: Sympa ce comparatif

        Posté par reno () le 23/05/2002 à 18:55. (lien). Évalué à 3.

        > Ceci dit, j'ai comme l'impression bizarre ce
        > que tu ecris vient de 'on-dit', que tu n'as
        > jamais reelement fait de developpement en Java
        > (ou, pas depuis au moins 4 ans).
        
        Faux, j'ai réellement développé en Java en 98 comme je l'ai dit.
        Une preuve? Dans le JDK1.1.7, il y avait un bug du ramasse-miette: quand un objet n'était référencé que par des références statiques il était détruit (cas classique lors de classe singleton).
        J'ai mis pas mal de temps à comprendre pourquoi mon programme se plantait aléatoirement à différent endroits!
        
        J'ai eu encore plus de problème avec les librairies standard (Swing surtout, mais pas uniquement).
        Je ne l'ai pas utilisé depuis 98, mais je surveille quand même les évolutions depuis et je maitiens: la correction de bug pour lesquels des milliers de gens ont votés prend reellement des années..
        :-(
        
        Sun est beaucoup plus intéréssé à rajouter des interfaces pour tout et n'importe quoi plutot que de rendre fiable ses librairies..
        
        Ceci dit apparemment le JDK 1.4 a apporté un mieux de ce coté la.
        
        J'ai vu l'annonce d'IBM pour SWT, je n'ai pas encore eu l'occasion d'essayer, mais cela me parait TRES interressant.

    • [^]Re: Sympa ce comparatif

      Posté par Nelis (page perso, ) le 23/05/2002 à 19:07. (lien). Évalué à 3.

      Exact, l'article parle de bug de JVM, mais en plus il y a des bugs de la librairie standard.
      
      Trouve moi une librairie / machine virtuelle avec un minimum de code sans aucuns bug et fais moi signe ...
      
      En plus Sun met un temps dingue pour les corriger ses bugs: il faut compter 2-3 ans pour des bugs pour lesquels des milliers de personnes ont vote dans la BugParade..
      
      C'est clair que certains bugs trainent depuis longtemps mais on ne peut pas dire que Sun ne corrige pas les bugs, il y en a énormément de corrigés très régulièrement ...
      
      Ca depend des domaines: essaye de faire des IHM ou d'imprimer des trucs non-triviaux et on en reparle.
      
      Je dois avouer que je suis plutôt côté serveur, donc tu as sans doute raison, dans ces domaines peut être que les librairies standards montrent leurs limites ... Mais il y a peut-être d'autres librairies qui te permettent de faire ce genre de chose ?
      
      Mouais c'est une drole de feature quand meme!
      
      Ils ne disent pas que c'est une feature non plus, c'est juste un comportement induit par le modèle de mémoire de Java, et encore le problème ne survient que lorsque le code s'exécute sur des machines multiprocesseurs. Si ils avaient choisi un autre modèle de mémoire, peut-être un autre problème aurait surgit autrepart, tout modèle a ses avantages et ses inconvénients ...
      
      Certes dans tout les cas, un bon synchronised au bon endroit resout le probleme, mais avant encore faut-il trouver ou se situe le probleme!
      Le deboguage d'application multi-threadee avec des comportements aussi bizarre des JVM doit etre coton..
      
      La programmation multithreads n'est jamais trivial et demande une très bonne connaissance des comportements de la machine (virtuelle ou non) sur laquelle on développe ... C'est un des domaines les plus complèxes du génie logiciel ...

      --
      Vache qui rit, à moitié dans son lit

• [^]Re: Sympa ce comparatif

  Posté par Luc Bourlier () le 23/05/2002 à 14:38. (lien). Évalué à 2.

  Il y a un truc pas clair dans l'article que tu proposes.
  L'article est du genre "Attention, il y a des problemes dans le modele de java, c'est pas bien", mais l'auteur se base sur la version 1.2.1 de la JRE de Sun, qui a au moins 2 ans (et deux ans c'est long en info), et dit lui-meme que dans les version 1.3 de IBM et SUN, le deuxieme probleme est corrige.
  L'article a peut etre ete mis en ligne en mai 2002 mais les informations qui sont dedans ne m'ont pas l'air de tout premiere fraicheur (je vais d'ailleurs me fendre d'un commentaire sur leur site).
  
  Sinon, comme le dit nelis, je vois pas le rapport entre ces problemes et les bugs possible dans les librairies standards. Personnellement je programme pratiquement exclusivement en Java, et je n'ai jamais rencontre de bugs dans les librairies standards (ce qui ne veut pas dire qu'il n'y en ait pas, seulement que ce n'est pas des *gros* bugs qui empeche toute utilisation du language).

• [^]Re: Sympa ce comparatif

  Posté par outs () le 24/05/2002 à 10:35. (lien). Évalué à 4.

  >suite a lecture du comparatif, j'ai voulu apprendre Ocaml
  >Mais j'ai fait un rejet d'Ocaml: je n'ai vraiment pas l'esprit fonctionnel.
  
  Le rejet au début c'est normal la facon de penser est tellement diférente ...
  
  Mais si tu t'accroche un petit peut tu verra que les outils que te proposent les languages fonctionnels sont *tres* puissant.
  Quelques petits exemples :
  
  - L'inférence des types : on ne définis jamais le type des variables (pas de définition et pas de typage de fonction non plus).
  Le type est déterminé par le compilateur (on dit inféré) grace aux opérations qui sont effectué dessus.
  Par exemple si on fais a+b le compilateur sait que a et b sont des integer car l'opérateur + ne s'applique qu'a eux.
  Alors évidement c'est tres différent du C (la language de base pour bcp d'entre nous) mais imaginez comme c'est cool de ne pas avoir à déclarer des milliard de trucs ni a utiliser des caractères comme en perl (style $variable ou @bidule) (j'espere que je dis pas de connerire pasque ca fais des annés que j'ai pas touché au perl)
  
  -La pleine fonctionnalitée : les fonctions sont des variables (presque) comme les autres. Grace à ça on peut définir des itérateur (des for améliorés) sur toutes les structures de donnés. Exemple : vous prenez l'itérateur do_list qui applique une fonction a tout les objet d'un liste, et vous pouvez faire :
  do_list (printf "%s") ma_liste;;
  et ca imprime toute la liste
  
  Alors évidement le revers de la médaille c'est que les compilos de ce genre sont généralement assez lents. A mon avis ceux qui l'ont programmé doivent être très fiers de leurs optimisations. C'est vraiment un tour de force de faire tourner ca plus vite que du C++.
  
  Et l'auteur du comparatif dis justement que la vitesse d'éxecution n'est pas tout : le temps de développement peut être aussi déterminant, et justement grace a la puissance d'Ocaml on peut avoir le beurre et l'argent du beurre =)
  
  Et puis programmer en fonctionnel même juste pour essayer je trouve que ça ouvre l'esprit a d'autre méthode et d'autre facon de résoudre les problemes.
  
  REHM Joris
  
  Pour ceux que ca intéresse : caml.inria.fr (en plus c'est francais)

manque un langage

Manque un language

• [^]Re: Manque un language

  Posté par Moby-Dik () le 23/05/2002 à 18:54. (lien). Évalué à 8.

  Il manque le pascal nan ?
  
  en terme de perf je suis sûr que ca serait pas loin du top du classement :-)
  
  Pourquoi ? De toute façon la page teste autant les compilateurs / interpréteurs que les langages eux-mêmes (c'est pour ça qu'un langage comme ocaml, quoique logiquement peu performant - car manipulant des paradigmes assez différents de ceux compris par le processeur -, se retrouve en haut du tableau car des types se sont cassé le crane pour l'optimiser correctement).
  
  De plus, les résultats ont l'air assez peu fiables (un programme identique en C et C++ qui retourne des temps d'exécution respectifs présentant une différence importante...). Du coup si l'on observe quelques dizaines de % de différence entre deux langages, ce n'est pas significatif ; par contre quand on voit que, sur des programmes identiques et écrits rigoureusement de la même façon, PHP4 est trois fois plus lent que Perl, on se dit que Zend feraient bien d'optimiser leur p... de machine virtuelle ;(
  
  
  nan ?

  • [^]Difference C/C++ gcc/g++

    Posté par Tennis Prono (page perso, ) le 24/05/2002 à 19:27. (lien). Évalué à 1.

    Deja, les programmes ne sont pas les meme. Si celui special C est plus rapide, je prendrais celui-la avec g++, puisque le C++ est quasiment compatible avec le C.
    
    Question: le mot-clef "inline" c'est standard en C (je fais du C++, pas du C) maintenant (je ne suis pas les normes) ? Parce que l'auteur l'utilise pour les programmes gcc.

    --
    Pas de bureau 3d libre sans drivers libres!

    • [^]Re: Difference C/C++ gcc/g++

      Posté par Vivi (page perso, ) le 24/05/2002 à 22:50. (lien). Évalué à 2.

      le mot-clef "inline" c'est standard en C
      
      en C99, oui

c'est quoi cette news à 0.3EUR ?

Stats sur les langages