Guillaume Laurent a écrit 1148 commentaires

C'est vrai, mais sa popularité augmente (avec raison). En attendant, il est sur Mandrake, je suppose qu'il est sur RedHat aussi.

Par ailleurs tu ne trouvera pas Perl sur n'importe quel Unix, loin de là, et encore moins Python.

> * AUCUNE possibilité de déclarer des variables! (comme en Python, d'ailleurs)

C'est commun à absolument tous les langages de scripts, et même tous les langages faiblement typés je crois.

> Mais franchement c'est un peu dommage: Ruby et Python sont meilleurs (a mon avis) que Perl pour écrire des gros programmes mais ils leur manque tous les deux la déclaration de variable et l'équivalent de "use strict"..

Je ne crois pas que ça soit un si gros problème. Un mode "warning" à la Perl serait sans doute utile, mais la propreté de Ruby par rapport à Perl fait que la balance penche toujours largement de son coté, surtout lorsque le nombre de lignes augmente.

Contrairement à Perl, en Ruby tu aura moins tendance à avoir des variables avec un scope très large (genre variables globales), plutôt uniquement des variables membres ayant le scope d'une classe, donc ça facilite beaucoup le debug.

> bon, je vais préciser mon propos [...]
> [... propos précisé ...]

OK, là par contre, sans avoir de preuves formelles, je suis à peu près sur que tu as raison sur ces points.

> quand je dis (de façon un peu provoquante, je l'avoue)

Pas provocante, ignorante. Tu n'as jamais fait de développement sérieux pour croire ça.

> que le dev se résume à "coller" des bouts de codes rachetés ici et là (exemple le noyau de NT) je me trompe ?

Totalement. Réutiliser du code, quand il ne s'agit pas d'un code fait exprès pour (e.g. pas une librairie) c'est en général très difficile, très compliqué, et au final rarement rentable.

Un article très interessant à ce sujet :

http://www.joelonsoftware.com/stories/storyReader$402(...)

De quelle couleur est le ciel sur ta planète ?

> D'ailleurs, contrairement à une idée répandue, le fait de très peu réutiliser de code en C par exemple a plutôt tendance à plomber les perfs.

T'es sur de ta phrase là ? :-)

> (à mon avis, si tu implémentes une table de hashage en C toi même, elle sera sans doute bien moins rapide qu'en java où elle a été bien optimisée).

Non, ta hashtable sera plus rapide qu'en Java, à moins vraiment d'être un gros mauvais mais :

- faut vraiment avoir que ça à foutre pour implémenter une hash-table en C, pourquoi pas des listes chainées aussi ?

- appelée d'un programme Java, le gain de perf sera quasi-nul voire négatif (un pote à moi avait essayé), parce que le goulot d'étranglement c'est JNI :-).

> Typiquement c'est un bug du noyau

Non, il suffit que ton process soit en attente d'une socket qui se ferme ou d'un fichier sur un filesystem un peu lent (NFS, cdrom bloqué)... C'est assez courant.

$ kill -SIGCHLD 41


Non, SIGCHLD est le signal qui prévient un process qu'un de ses fils est mort. Ça ne "demande" rien. Par contre ça active normalement (si le père est correctement codé) le sigchld handler qui effectue un wait() et ainsi "accuse reception" de la mort du fils.

> Un process zombie est un process qui ne sait plus qui est son process père

Non, c'est un process dont le père n'a pas fait wait(). cf. Unix Programming FAQ (c'est même la plus FA des FAQ, avec celle sur les sockets en TIME_WAIT).

Et si vous savez fournir, ils rémunèrent aussi ?

> Le clavier est la pire interface de communication qu'on ait jamais inventé, un truc pour les nabots de la pensée.

Tu devrais aller discuter avec le jdeneux qui se tate sur la réutilisabilité un peu plus bas. Ça donnerait surement quelque chose d'interessant :-).

J'ai un exemple vaguement approchant. Pour tester plus facilement l'import de fichier dans Rosegarden, j'ai rendu la fonction accessible par DCOP (2mn chrono). Du coup au lieu d'avoir à dérouler un menu, choisir la fonction, choisir le fichier dans le dialogue, cliquer sur 'ok', j'avais juste qu'a rappeller une commande shell : dcop Rosegarden importFile /home/glaurent/mon_fichier_de_test.

Ceci dit non, pour l'instant de tels scripts n'existent pas encore sous KDE, mais tout est en place pour que ce soit possible.

Joli score, bravo :-).

> Des 10nens ca fait combien ?

Dans les 50 ou 60 Mo pour une démo Swing, JDK 1.3 de chez Sun, si je me souviens bien.

> Et Qt il en prend combien pour une appli utilisable ;-)

Toujours difficile à dire vu qu'il s'agit d'une lib partagée. Pour Konqueror : vers les 20Mo. 5Mo pour Konsole, 15Mo pour KWord. Et encore, là on ajoute les libs KDE.

Merci pour ton appréciation :-).
> il manque de plus d'autres choses en Java, comme :

> - la surcharge d'opérateur
> - l'héritage multiple (si tu viens me chercher avec les interfaces, tu te prends une claque)
> - les classes à sémantique valeur (en plus des classes à sémantique référence)

Oui mais parti comme ça on refait C++ :-).

Même si sur le principe je suis d'accord, je ne suis pas du tout sur que le prix à payer en ajout de complexité du langage vale le coup (et dans le genre tu as vraiment cité les pires :-).

Et puis sur un plan purement pratique, rajouter de telles fonctionalités vu l'étendue du code existant serait extrèmement difficile.

Je crois qu'il serait préférable de creer un nouveau langage. De ce point de vue là, C# est une bonne nouvelle.

> alors que Java et la GPL on exactement la meme cible : faire un monde plus ouvert :(

Non, la cible de Java c'est Microsoft et rien d'autre.

> Ca m'atriste de voir tant d'articles incomplets et peu precis sur java

Oui mais là c'est une interview d'un mec qui s'occupe d'une toolkit C++. Donc il est assez normal que ça ne parle pas de Java in extenso.

> tout ce qui trouve comme argument sur java c'est que c'est pas du C !! (cf. pas du natif !)

Et alors ? On lui demande les avantages de Qt par rapport à Java, et c'en est clairement un. Qt tourne en natif sur les plateformes où il est porté, pas Java.

> Puisque tu connais java tu es conscient que la notion de natif est relatif ...

Non, les dizaines de megas bouffés par une JVM et le cut'n paste qui ne marche pas, pour moi ou pour un utilisateur de base, c'est pas relatif. C'est du concret.

> alors faire appel a ce point comme argument premier et principal est plutot surprenant voire derisoire.

Pour toi oui, pour beaucoup d'autres non.

> tu parle de desktop, mais Swing n'as pas la pretention de remplacer les windowmanagers [...] Le desktop etant lui meme une application Qt

Oui, c'est exactement ce que je dis, et c'est bien pour ça que Qt n'est pas archaïque comme tu le prétends. Cette toolkit a encore son utilité.

> Ca c'est faux, meme si on manque d'implémentations de Java compilé.

Donc, même si en théorie c'est faux, en pratique, c'est vrai.

> Juste d'un P4 ou d'un ATHLON ;-)

Non, P90 avec 32Mb de RAM, sous Win98 en plus. C'est du vécu, j'ai fait tourner une GUI au dessus d'une DB Oracle qui se constituait à partir d'un fichier de description en XML. Il est actuellement impossible d'en faire autant en Java, même si j'aurai préféré utiliser JDBC pour développer ce truc.

> je sais pas si t'es au courrant mais le langage on s'en fout un peu

Ah, bon, excuse-moi, tu sembles être beaucoup plus au courant que moi de la chose.

> c'est la plateforme qui est importante

Oh, me voilà renseigné alors.

> sache que tout de meme en Java on peut ecrire avec une floppé de langages divers et qui produisent tous de bytecode

Bien. J'ai un pote qui travaille chez BEA, un autre chez IBM, un au W3C, un qui s'occupe de SVG, et je bosse pour une boite qui fait des composants Java depuis 97. C'est curieux, mais à part jython dont on a vaguement parlé mais qu'ils n'ont jamais utilisé dans le cadre professionel, ils programment tous en Java, et ils surveillent de prêt l'évolution du langage lui-même.

La "plateforme Java", c'est tout ce qui s'est construit au dessus : JDBC, JEE, etc... (je m'y perds dans tout ces acronymes). Les langages qui compilent vers du byte-code Java n'ont pour le moment aucune existence dans l'industrie.

> Je t'en veux pas car 50% des personnes qui sont "contre java"

Mais qu'est-ce qui te fais croire que je suis "contre Java" ?? Je suis pour, vivement que ça marche sur le desktop. J'ai juste un peu plus que toi la tête sur les épaules.


> >prédilection de Java est plutôt du coté serveur :-).

> Tout a fait, mais l'une des principale raisons est tout autre : jusqu'a present installer une appli Java cliente c'etait le mal de tete assuré

Non, rien à voir. Pour un serveur les perfs sont moins importantes que sur le desktop, parce qu'il suffit de prendre une machine plus grosse pour les augmenter, ou d'en mettre en parallèle, ce que Java sait bien gérer. C'est un coup fixe, connu, alors que celui de debugger un serveur écrit en C ou C++ ne l'est pas. Mais tu ne peux pas faire ça pour une appli desktop, upgrader 1 machine ça passe, 150 non.

Ensuite l'autre raison c'est que décompiler une appli Java est trivial, et pour faire une appli commerciale avec du bon vieux code proprietaire qui va vérifier sa licence au lancement, ça craint. Tu peux toujours utiliser un offuscateur de code, mais ça complique pas mal le développement parce que ça apporte son lot de problèmes. J'en sais quelque chose, le chef d'équipe dans le bureau à coté du mien en a régulièrement.

> Parce que tu crois que patcher la lib de Qt pour corriger un bug c'est facile

Toujours plus facile qu'une JVM. C'est pas la même complexité.

> Ben si tu crois encore que java n'est qu'un langage, de plus hyper lent et qui sert à rien d'autre qu'a faire plaisir à des techos de bas etages pas capable d'ecrire une ligne de bon vieux KR-C ou d'ASMx86 alors je crois que j'ai ma reponse

Relis ce que tu as dit : si je trouve que Java a besoin d'être amélioré, y a qu'a logger une JSR. Cool. C'est comme si je te disais que si C++ ne te plait pas, tu n'as qu'a ouvrir un defect au C++ committee. Et strictement parlant c'est vrai, la spec C++ est ouverte aussi (même plus). Le pb c'est que c'est une procédure qui prend des années, et reservée à un petit nombre de gens qui ont du temps à y consacrer.
Qu'est-ce que je dois mettre dans ma JSR pour dire "je veux de meilleures perfs" ?

Et pour info, non, je ne considère pas que Java soit un language hyper-lent, etc... Sors toi de tes clichés.

> c'est clair que c'es pas si simple

Content que tu t'en rendes compte.

> mais l'avantage c'est que les elus (tu peux te presenté à l'election si tu le desirent... je sais plus quand est la prochaine ...) eux peuvent faire avancer les specs ...

Les utilisateurs font aussi avancer Qt sinon la librairie n'aurais pas la qualité qu'elle a actuellement. Qt est plein de patches de gens externes à TT, souvent revus par TT pour s'assurer de la qualité. Par exemple le support des fonts antialiasés ne vient pas d'eux au départ.

> Et enfin, la fameuse Genericité que meme le pere de Java refusait ... et bien la JSR l'a adopté et l'intégration dans le langage est en cours et la sortie est pour le 1.5

Je sais, mais il semble que l'implémentation ne soit pas si géniale :

http://www.beust.com/cedric/javaone-2001.html(...)

Ils n'ont fait que rajouter un typage plus fort mais sans supprimer la nécéssité de downcaster.

Par contre Gosling parlait d'ajouter l'overloading d'operateur il y a longtemps

http://java.sun.com/people/jag/FP.html#overloading(...)

on dirait que c'est enterré, dommage.

> Comme tu le dit toi meme, c'est le propre de java d'etre portable... donc c'est plutot stupide comme argument ;)

Faut-il vraiment t'expliquer le concept de "natif" ?

Le fait que Java tourne sur une JVM a aussi ses inconvénients, non seulement pour les perfs mais aussi pour l'intégration avec les applis natives. Par exemple si je démarre une demo Swing sur mon Linux, le cutn'paste ne marche pas dessus, ni la roulette de ma souris. Qt, ça marche.

> De qui la distro? blackdown, sun, ou IBM ?

Sun je crois. Et franchement je m'en fous, en tant que développeur, la dernière chose dont j'ai envie c'est de devoir perdre du temps à choisir une version bien specifique pour avoir des perfs correctes.

> Et bien donc Qt deja est archaique :
> [ des liens vers des applis ]

Bon, alors une fois que tu aura bien assimilé la notion de "natif" par opposition à "machine virtuelle", tu pourra passer à celle de "desktop" par opposition à celle d'"application".

Indice: un desktop lance des applications, gère leur intégration, l'environnement, etc...

> au niveau composants graphiques, swing n'a rien a envier à QT non vraiment

Je suis d'accord. Sauf pour les perfs, et l'intégration avec la plateforme native.

> il restera toujours des choses que seul le C fera

Il n'y a rien que tu puisse faire en C et que tu ne puisse pas faire en C++ :-).

> la productivité pour la realisation d'une appli Qt est vraiment limité

Quel genre d'appli as-tu fait sous Qt et combien de temps l'as-tu utilisé ?

> Qu'est ce qui rame ... donne des exemples ... avec quoi comme VM, comme comme parametre de GC (mode incremental, clean/mark/sweep)....

Avec Qt ça ne rame pas, et je n'ai pas besoin de config speciale pour obtenir ce résultat. Si pour obtenir des perfs sur un langage tu es obligé de faire ce genre d'acrobaties, c'est que le langage n'est pas encore au point pour le boulot que tu lui fais faire.

> Et d'autre part si un Jour Sun nous prend la tete, rien n'interdit de reecrire exactemet la meme biblio

Ben voyons, ça sera surement très facile, c'est tout petit Swing, et puis ils ne vont rien faire pour nous en empécher, hein.

> Java est 40% plus productif que le C++

Tout le monde sait ça, encore qu'il serait interessant de refaire la même stat par rapport à Qt et non C++ en général.

Ceci dit, c'est pas pour rien si le marché de prédilection de Java est plutôt du coté serveur :-).

> Maintenant si tu trouve que certains points dans java ont besoin d'amelioration, libre a toi de patcher le code source de la VM et d'envoyer tes patchs à Sun

Oh ben oui tiens, ça aussi ça doit être facile.

> ou de demander un JSR www.jcp.org pour demander un evolution plus majeure ...

Bon sang mais c'est bien sur, pourquoi n'y avons nous pas pensé plutôt. :-)

> Oui, les swings sont bien multi-plateforme

Il ne dit pas le contraire. Il dit que Java ne peut pas tourner en natif sur toutes les plateformes. Ce qui est vrai, puisque Java tourne sur une JVM, comme tu le soulignes toi-même.

> Donc la c'est clair, il ne connait de java que ce qu'il a put lire dans des articles il y a 4ans

J'ai testé récemment le JDK 1.3 sous Linux, et malgrè les immenses progrès fait depuis le 1.2 sur la vitesse d'affichage, c'est toujours très lent par rapport à Qt. Quand à l'occupation mémoire, je n'ai pas vraiment vu de progrès, c'est toujours dans les 30 ou 40Mo pour une simple appli de demo.

> et je suis attéré de voire des posts peu argumentés completement faux

Son post est parfaitement argumenté et tout à fait exact.

> tout ca pour essayer de justifier l'exitense d'une librairie graphique dépassée et un langage de prog archaique

Quand on pourra programmer l'équivalent de KDE en Java, alors oui, C++ et Qt seront archaïques. En attendant, c'est ce qu'on a de mieux.

C'est clair, tous les utilisateurs adorent choisir leur window manager, et la profusion de toolkits graphiques à permis à Unix d'avoir la place de choix qu'il occupe sur le desktop actuellement :-).

> et s'appuie sur des études réelles

Comme tous les textes parlant du port d'armes, qu'ils soient pour ou contre :-).

> Je rappelle à tous qu'il prône l'usage et la détention des armes à feu. A la lumière des derniers événements Outre-Atlantique on ne voit pas trop d'utilité à tous détenir une arme à feu.

Mais lui la voit très bien :

http://www.newsforge.com/article.pl?sid=01/09/11/2048256&mode=t(...)

Extrait :

"We have learned today that trying to keep civilian weapons out of airplanes and other areas vulnerable to terrorist attack is not the answer either -- indeed, it is arguable that the lawmakers who disarmed all the non-terrorists on those four airplanes, leaving them no chance to stop the hijackers, bear part of the moral responsibility for this catastrophe."

> "The Qt class is a namespace for miscellaneous identifiers..."

Oups, exact, je l'avais complètement oubliée. C'est bien implémenté par une classe, mais en pratique ça sert à simuler un namespace. Il n'y a pas de code dedans. Mais bon, tu as raison, c'est bien une classe.

Y a pas de classe "Qt". Le flag dont tu parles s'applique à QWidget, et plus particulièrement aux fenêtres top-level.

C'est un cas très particulier, les top-levels (typiquement, QMainWindow) n'ayant le plus souvent pas de parent, ça permet là aussi de ne pas avoir à s'occuper de les effacer. Mais ça ne s'applique pas aux QObjects en général (qui ne sont pas forcément des widgets, et encore moins des fenêtres top-level).