reno a écrit 3881 commentaires

> Je ne dis pas qu'il n'y a jamais de fuites de mémoire en Java mais à mon avis, c'est très rare !
> et je ne pense pas qu'il faile mettre à null une reference quand tu ne l'utilises plus

Et tu fondes ton avis sur quoi?

Moi, cela parait me plus sage de mettre a null les reference que tu ne vas plus utilisée: autrement une fuite de mémoire causée par une arborescence de reference pointée par un objet a longue durée de vie (une objet d'une classe singleton par exemple) peut arriver vite..

Et la le GC ne peut pas désallouer un nombre important d'objet d'ou la fuite de mémoire..

Je pense que les 4 (5?, plus?) types de références (weak et autres) qui ont été introduites dans Java, ce n'est pas juste pour le plaisir!
Aussi la réputation (méritée à mon avis) que Java c'est hyper-gourmand en RAM, c'est en partie a cause de developpeurs qui gere mal leur mémoire : non mise a null des references inutiles, par exemples..

> Qui ammène une opinion favorable, si tout le monde s'en sert c'est que c'est bien

Mais oui, bien sûr si tout le monde se sert de Microsoft, c'est uniquement par l'effet "Mouton de Panurge"..

Cela n'a absolument rien à voir que
1) Microsoft a joué dans le passé intelligemment la politique des prix pour se populariser.
2) la majorité des logiciels commerciaux et du matériel tournent sans se poser de question sur les OS de Microsoft, ce qui n'est pas le cas pour tous les autres OS..
3) le fait de communiquer avec les autres t'impose d'utiliser les formats les plus utiliser, c'est à dire les .doc, dans mon entreprise on vient d'acheter une trentaine de PC pour les faire fonctionner sous Linux .. avec aussi une trentaine de license d'Office 2000 (utilisation de CrossOver) ce qui donne des sous a Microsoft quand même!

Et oui, je connais Star/OpenOffice et la compatibilité est bonne mais encore insuffisante: pour pouvoir switcher il faudrait une compatibilité quasi-parfaite en import et en export..

Bah, beaucoup d'entreprises exactement la même chose, la seule différence avec Microsoft par rapport aux autres, c'est que Microsoft a réussi à avoir un monopole sur leur domaine..

Ah?
Ce n'est pas évident en lisant la news..

Si c'est le cas, c'est du second degré mal fait.

Bin ça depends des jeux..
Personellement mon jeux préféré est IL2 Sturmovick un simulateur de vol avec des avions de la seconde guerre mondiale: a jouer en réseau (coopératif ou les uns contre les autres), c'est sympa.

Et c'est pas demain qu'un simulateur de vol vaudra grand chose sur une console..

C'est vrai que 7eme, c'est pas mal quand meme, a environ 1/3 (grosso-modo) des utilisateurs de Mandrake c'est loin d'être négligeable..

>l'interet de Y par rapport a X: le rendu des widgets cote client.

Euh, coté serveur il me semble pour Y?

Pour moi l'intérét de porter Qt ou GTK pour Y ou Berlin/Fresco est juste un problème de compatibilité..

Autrement redevelopper tout KDE ou Gnome pour Y ou Fresco, ça risque de prendre un peu de temps..

Je me demande si le gros probleme de Fresco ce n'est pas Corba?

Je pense que la plupart des gens voient Corba comme un machin lourd et super-compliqué, alors c'est sûr quand on leur dit que la communication client-serveur utilise Corba avec Fresco, ça doit déja calmer pas mal..

Il y a tellement de choix dans les interfaces graphiques:
-coordonnees flottant ou entier?
Fresco est en flottant je crois: ça doit ramer pas mal sur les PDA!
-rendu vectoriel ou bitmap?
-rendu coté client ou serveur?

Je vois mal comment trouver une interface qui satisferait tout le monde..

Je confirme, j'ai fait un peu de programmation X à tres bas niveau (XLib), il y a un certain temps: une chose qui m'avait vraiment surpris c'était le nombre d'événements envoyés par le serveur X, il est vraiment tres, tres bavard.

Pour diminuer un peu le probleme, le serveur X bufférise les événements et en envoit plusieurs en même temps, ce qui a mon avis n'est pas terrible: cela provoque une (faible) augmentation du temps de latence, juste un peu, mais la latence on n'en a jamais assez!

L'avantage est bien sûr d'avoir un serveur X le plus simple possible..

Franchement un peu plus de traitement coté serveur pour traiter les cas simples (bouton, tooltips, menu déroulant, etc..) me parait plus élégant..

Bin pour les magazines "génériques" je suis d'accord mais comme dit Fanf, MISC pour trouver l'équivalent sur le web...

C'est probablement possible mais l'effort nécéssaire et le tri me paraisse beaucoup trop grand.

Soit dit en passant la qualité des articles est quand même en général meilleur dans un magazine que sur le web, je me souviens d'une série d'article sur le Perl dans LMF qui était tres bien fait: alors que je n'aime pas ce language et que j'aurais même tendance à le détester franchement: trop de debugging de code pourri en Perl, la clareté des articles faisait paraitre le language comme simple!

Moui, sauf qu'autant je vois l'interet d'avoir KDE et Gnome: les deux sont en concurrence et essaye chacun de s'amméliorer en reprenant les bonnes idées de l'autre.

Autant avoir les format rpm et dpkg, c'est vraiment une perte de temps inutile, qui n'apporte rien du tout!

Mais bon, le syndrome "Not Invented Here", ça fait souvent des dégats..

PS:
Non, ce n'est pas un troll. Enfin moi je ne le vois pas comme ça..

>> Sinon, pouvez-vous me dire ce qu'apporte le amd64 pour une utilisation intensive ?
> Ça apporte rien. L'intérêt du 64 bits c'est l'espace d'adressage mémoire qui est plus grand

Tu exagère un peu, l'amd64 n'apporte pas que le 64 bits, mais aussi 16 registres au lieu de 8, ce qui peut amméliorer les perf: le compilateur voit plus de registres: il peut mieux les utiliser.

Alors pour les perf, ça depend bien sûr du code, ça peut aller de 0 à 20%.

Il y a aussi un mode pour rendre les pages executables non-inscriptible ce qui complique la vie pour les pirates voulant exploiter les buffer overflow.

En theorie tu as raison d'ailleurs nous avons des regles de codage en perl bien sur, en pratique, il est parfois difficile d'imposer des regles de codages pour plusieurs raisons: pas le temps de relire ce qu'a fait l'autre, c'était un proto qui aurait du mourir mais qui est gardé, il est difficile d'engueuler un chef, etc..

En Java ou en Python, il est quand même un peu plus difficile de produire du code illisible, en Perl, c'est plus que facile et malgrés mon expérience moyenne en Perl, j'ai eu a jouer le pompier plusieurs fois, ce qui me fait apprécier le language de moins en moins..

[ Anedocte amusante: on m'a envoyé un fichier de Perl en attachement, la fille qui avait fait cela l'avait recopié par un copier/coller, donc les lignes étaient tronquées.. Je fais passer la suite de moulinettes et j'obtiens bien sur n'importe quoi en sortie mais l'interpréteur perl ne s"était même pas arrété en erreur a cause des lignes tronquée! ]

>Bah pourquoi ???
>Vous ne voulez pas risquer de faire un truc propre en Perl ?

Le but de Perl est pour nous de lier des applications, donc les programmes sont sensé garder une petite taille..

Or le Perl, c'est comme le shell, si tu laisses les gourous utiliser tous les "raccourcis" du language, ça devient illisible et inmaintenable pour tous sauf pour des gourous.

jigso trouve que faire du "php/C/C++/java, c'est chiant, c'est toujours pareil, c'est carré", alors qu'en Perl tout est possible, le truc justement quand tu programmes en équipe, c'est qu'il faut que ce soit aussi carré que possible!

Pour se faire plaisir chez soi, le Perl c'est sympa, mais pour programmer au boulot ou les gars sont en général moyen en Perl, eh bien il faut faire attention a ce que tout le monde utilise des constructions comprehensible par tous, meme si ça rallonge un peu le code.

Un exemple, un prestataire s'est amusé a faire du code Perl objet en utilisant pas mal de perlismes, résultat on a été obligé de réécrire son code.. Je ne travallais pas sur le sujet, mais connaissant (un peu) mieux le Perl que les autres, j'ai du aider a nettoyer le bordel et il y avait du boulot, certaines bout de code de 2 lignes necessitaient 1/2h et un bouquin de Perl à coté pour comprendre (pas tellement pour comprendre, pour être sûr qu'il n'y a pas d'effet de bord voulu) alors que recoder ça de telle manière qu'un débutant en Perl puisse comprendre, ça prenait 4-5 lignes, pas plus..

Tu peux bien sûr faire plus ou moins avoir le meme probleme dans n'importe quel language, mais pour faire du Java aussi touffu a comprendre que du Perl, ça me parait bien difficile..

Moui, enfin c'est surtout parce parmi les langages de script c'est un des plus anciens --> plus répandu --> plus connu donc on le garde.

Perl ne parait pas illisible, c'est illisible..

Personellement, je prefere de loin ruby ou python comme langage, dans un nouveau projet au boulot on a gardé perl car ruby n'est pas considéré comme sufisamment répandu (ou connu) et mon chef fait une allergie a la syntaxe de python (blanc significatif).

Cependant, peut-etre qu'avec Perl "There Is More Than One Way To Do It", mais je peux t'assurer que le premier qui fait du Perl objet dans l'équipe, c'est la porte, la vrai..

Un exemple comment Perl pousse a programmer de façon crade: la syntaxe de Perl est tellement peu naturelle pour faire un tableau de tableau que la plupart du temps on se simplifie la vie en faisant un tableau de chaine puis un split, beurk..

>Une license ça se respecte. POINT

Certes mais ils respectent les licenses: ils n'utilisent pas les appels supplémentaires que tu n'as le droit d'utiliser que si tu déclare ton module GPL..

Ceci dit, je suis d'accord que leur solution pose probleme: cela peut induire des rapports de bug aux developpeur du kernel alors que ces rapports auraient été rejeté si le kernel est tainted.

D'apres la mailing list, ce n'est pas le message declarant que le kernel est tainted qui pose probleme, mais la frequence des message: il suffit de le mettre une fois par module, hors apparemment ces messages apparaissent plusieurs fois:
"Actually, we also have no desire nor purpose to prevent tainting. The purpose of the workaround is to avoid repetitive warning messages generated when multiple modules belonging to a single logical "driver" are loaded (even when a module is only probed but not used due to the hardware not being present). Although the issue may sound trivial/harmless to people on the lkml, it was a frequent cause of confusion for the average person.

Other Linuxant drivers (like DriverLoader and Riptide) do not need nor use this workaround because they are not composed of multiple modules and one set of warning messages is usually bearable. "

Rusty et toi êtes trop severes je pense.

Quel est la raison pour laquelle ils ont fait ça?
Trop de messages d'erreurs faisaient peur a leur utilisateur, et ça leur faisait perdre de l'argent en rajoutant des appels à leur support technique.
Apparemment le kernel est un peu trop verbeux pour les messages tainted: il suffit de le marquer une fois par module..

Je dirais que leur faute est de ne pas avoir remonté le probleme aux developpeurs du kernel, mais ceci dit même si les dev du kernel corrigent les messages, cela ne change rien pour les gens qui ne mettent pas a jour leur kernel..

Certes mentir n'est pas du tout correct, mais faire perdre du temps au support d'un fabriquant en mettant trop de message d'"erreur", c'est a mon avis un bug du kernel: les torts sont partagés..

> a était

Whoua, une petite sieste après le repas serait la bienvenue?

Je suis globalement d'accord avec les raisons que tu avances mis à part avec le point 5 (peu de bibliothèques) et bien, c'est le même problème pour tous les langages au début, non?

Pour le point 6, je ne sais pas: en C et en C++ aussi il n'y a pas de gestion dans le language des processus/thread, mais je ne suis pas sur que ça soit un gros handicap.

Cependant je me souviens encore que la prochaine version d'Eiffel allait avoir un support de la concurrence super, j'ai du entendre ça en 93 ;-)

>Warning, troll in progress : l'héritage multiple, c'est MAL (tm).

Bah, ça dépend comment tu l'utilise: au boulot on a utilisé l'héritage multiple en C++ pour hériter de classe permettant de stocker/lire les objets dans une base de donnée (ObjectStore), c'est un peu complexe certes, mais utile.

Je n'ai pas entendu de critique de la part des utilisateurs d'Eiffel sur l'héritage multiple, qui a l'air "plus simple" a utiliser sous Eiffel qu'en C++, maintenant je n'ai peut-etre pas assez tendu l'oreille (non la covariance ça ne compte pas, c'est un autre probleme).

D supporte les interfaces ok mais une interface étant juste une classe abstraite virtuelle, tu peux faire de la "programmation par interface" si tu veux avec l'héritage multiple, c'est juste un cas particulier, comme j'ai dit plus haut tout dépend comment tu utilise l'héritage multiple, c'est puissant il faut juste ne pas en abuser, mais bon c'est comme tout!

Mis a part la syntaxe assez proche du C, franchement Eiffel apporte deja ces atouts depuis des années: le GC, les tableaux a taille variable, les propriétés d'objets (enfin si je me souviens bien), rien d'original! Et la définition d'Eiffel n'est pas en béta version..

Mais bon si D peut réussir, la ou Eiffel a échoué, j'applaudirais!
Tu me permets juste d'être plutot sceptique..

Moi le probleme majeur que j'ai avec D, c'est que je ne vois pas pourquoi D réussirait la ou Eiffel a échoué: D comme Eiffel sont tous les deux des langages compilés, avec GC.

Donc je les voit remplir plus ou moins la même niche, mis à part que D est plus "systeme", exemple: D définit comment le code assembleur embarqué est définit, ce qui permet d'avoir du code assembleur "portable" de compilateur à compilateur.
Et Eiffel est plus haut niveau: Eiffel a l'héritage multiple tandis que D simplifie l'implémentation du compilateur en utilisant juste l'héritage simple et les interfaces (à la Java).

Eiffel est quasiment inconnu: Pourquoi D aurait plus de succes?

Mis a part l'attrait de la nouveauté, je ne vois pas ce qu'apporte vraiment D de si interressant par rapport a Eiffel..

[ Pour info, si Eiffel est mort, c'est probablement qu'au départ les environements de développement d'Eiffel étaient tres cher, maintenant il y a SmartEiffel qui est sous licence GPL. ]

Je pense que les deux sont liés d'ailleurs : Objective C peu connu --> GnuStep qui ne se développe que lentement..

Et vice versa d'ailleurs :-)

Bof, tu est sur de toi?
Si je me rappelle bien il y avait un débat sur cette 'clause d'exception' du temps ou Qt n'était pas GPL sur Linux et les developpeurs de KDE ne pensaient pas que cette clause d'exception était nécéssaire.

Je suis plutot de leur avis: je ne vois pas quelle clause de la GPL impose ce que tu dis..

Que je sache il existe des tas de soft GPL pour Windows, ils ont tous cette exception?

> OpenOffice c pas que Sun

Certes, mais à partir du moment ou OpenOffice a été crée par Sun en ouvrant une bonne partie des sources de StarOffice..

Donc sans Sun pas de OOo.

J'ai deux hypotheses:
1) tu considères qu'OpenOffice, c'est "pas grand chose"??
2) tu es trop tétu pour admettre que tu as dit une bétises..

Je penche pour 2 moi.

>> surtout si tu as un affichage déporté. (=>réseau)
> Bien au contraire si tu compares aux techniques comme VNC ou PC Anywhere qui sont utilisées sous Windows .

C'est peut-etre un probleme d'implementation? Difficile de savoir..

Si pour certaines widgets, le client envoit juste une description de haut niveau de la widget et le serveur ne retourne qu'un seul évenement au moment ou l'utilisateur selectionne pour de bon un élément (je pense à un menu déroulant par exemple), il y aura quand même beaucoup moins de traffic circulant sur le réseau: en nombre de paquets émis (X est incroyablement bavard!) et en taille aussi: une description de haut niveau est plus courte..

En local ou sur un LAN, la différence est négligeable, je suis d'accord. Maintenant par Internet, la solution d'avoir une partie des widget coté serveur me parait fort interessante!

Interressant, je ne suis pas un fana du SQL, mais quand on compare le SQL et le XPath, je prends le SQL tous les jours.

Franchement je trouve XSLT/XPath mal fichu.. et les schemas XML aussi d'ailleurs..