Guillaume Laurent a écrit 1148 commentaires

> À part les Jacky et leur bagnole, je vois pas avec quoi comparer une telle arrogance et une telle mauvaise foi...

Oh la barbe, arrête de prendre des airs de pucelle effarouchée parce que j'ai une opinion tranchée sur Gnome. Oui, développer sous Gnome n'est clairement pas un signe de compétence technique. Y a des mecs très pointus qui bossent sous Gnome, mais avec des oeillères taille XXL. Et hors des technos Gnome, ils sont aux fraises. Les autres se cassent ailleurs (pourquoi crois-tu que Miguel s'est jeté dans Mono ?).

> Mais peut-être ne t'abaisses-tu pas à regarder du "C pseudo-objet"...

'Been here, done that, long ago. Maintenant, j'ai un peu autre chose à foutre.

> Ton lien ne concerne pas du tout la problématique des lecteurs de news, mais l'indexation d'e-mails

Euh, tu le fais exprès là ? La problèmatique n'est pas juste celle du lecteur de news, elle est de savoir si il est pertinent d'employer une DB dans la plupart des softs desktop, comme tu l'affirmes. Ce lien est un bon exemple qui te prouve le contraire. J'ose espérer que tu n'aura pas la mauvaise foi de maintenir qu'il n'a rien à voir avec la discussion en cours.

> L'utilisation de SQLite ouvrirait la voie à de nouvelles fonctionnalités très utiles pour beaucoup d'utilisateurs: [...]

Absolument rien de ce que tu listes ne nécéssite une DB, ça serait prendre un marteau pour casser des oeufs. Une DB c'est quand tu veux faire très rapidement des requêtes complexes sur un très gros volume de données. En dessous de 50Mb, c'est pas un très gros volume de données, grep fait l'affaire.

Par ailleurs je ne pense pas que les "nouvelles fonctionalités" que tu cites soient d'une quelconque utilité, mais bon, c'est un autre débat.

SQLLite va surement t'aider a résoudre pleins de problèmes, il va aussi t'en créer pleins d'autres. Et parmi les pbs qu'SQLLite va résoudre, combien se posent en pratique dans une appli genre un newsreader ou un lecteur RSS, et sont vraiment si dur que ça à résoudre autrement ?

Lire et écrire un fichier n'est pas particulièrement compliqué, et pour le tri je pense qu'il est plus difficile de trouver un langage qui ne dispose pas d'un algo de tri en standard qu'un qui en a un. Même la lib standard C implémente quicksort.

Oui, SQLLite et surement un outil très utile à avoir. Mais pas aussi souvent que bobert se l'imagine, loin de là.

XML est souvent mal employé, c'est sur. Maintenant, développant une appli qui utilise précisément du XML gzippé pour ses fichiers (lesquels comprennent le plus souvent bien plus de 1000 items), je t'assure que ça scale très bien, nos temps de chargements sont tout a fait acceptables, quand on a voulu les accelerer ça n'est pas du coté de XML qu'on a regardé, mais du traitement après. Parser du XML c'est pas spécialement lent.

Dans le cas des bookmarks de konq, je présume qu'ils passent par DOM plutôt que SAX pour les lire (ça serait logique vu qu'ils sont présentés comme un arbre), donc il est évident que tu vas manger un peu coté perfs. Ceci dit, pour seulement 1000 enregistrements, je ne crois pas que cela soit très sensible, le ralentissement viens plutôt de l'infrastructure de KDE qui maintient les bookmarks de manière centralisée.

Ce que tu ne veux pas comprendre c'est que le gain de vitesse dont tu parles, dans 99% des cas d'applis end-user, on s'en fout complètement, ça fait une différence négligeable. Par contre, avoir un format de fichier robuste et qui se lit facilement, ÇA ça fait une énorme différence pour le développeur, et pour l'utilisateur au final parce qu'il perdra moins souvent ses data.

Je viens de faire un test tout con : grep sur un fichier de 600 000 lignes (six cent mille, plus d'un demi-million). Le fichier fait 33Mb au total. grep bouffe ça en 0.04 secondes, sur mon P4 2.4GHz, une machine vieille de 2 ans. 4 centièmes de secondes pour scanner une regexp sur 33Mb. Tu es sur d'avoir si souvent besoin d'une DB ?

Donc pour ce qui est d'aller reflechir et des commentaires méprisants, pour l'instant c'est plutôt toi qui croit avoir compris un truc ("SQLLite c'est bon, mangez-en") et qui pense que les autres sont des truffes de ne pas l'avoir compris, alors que dès que tu as 2 sous d'expérience, le truc que tu apprends (souvent douloureusement), c'est "les DBs c'est sympa mais faut pas en abuser".

Si ta seule caution pour l'utilisation de SQLLite, ce sont deux mecs qui, en 2004, continuent de développer un N-ieme lecteur de news en C pseudo-objet, franchement...

Bon, pour être clair :
- c'est toi qui dit que Pan est le meilleur newsreader sous Linux, y en aura plein pour pas être d'accord (à lire la feature-list y a pleins de choses que gnus sait faire et pas lui, par exemple).

- passer des lustres à développer du code sous Linux, même du code très utilisé, ne garanti rien quant à tes capacités réelles de codeur et designer. Développer du code open source, c'est une forme de dév très protégée du réel : tu fais ce que tu veux, y a très peu de conséquences parce que le plus souvent il n'y a pas grand chose en jeu (c'est pas le cas d'un truc comme Apache ou le kernel linux, mais pour Pan ça l'est clairement).

- il arrive très fréquemment qu'un développeur découvre un "nouveau jouet" et veuille absolument l'utiliser, même si ça n'est pas justifié, et même si ça oblige à "tout re-écrire". Surtout si ça oblige à tout re-écrire, en fait :-). Ça arrive même chez les gars expérimentés, c'est un piège archi-classique.

En plus dans cet exemple précis, la probabilité que leur code C soit devenu tellement spaghetti qu'ils n'arrrivent plus à l'etendre ou le maintenir et non-negligeable.

Après, y a pas que moi qui trouve que c'est de l'over-engineering, y a lui aussi :

http://www.jwz.org/doc/mailsum.html(...)

<<Mon discours s'adressait aux développeurs de logiciels de tous les jours, de clients RSS, de lecteurs de news, de générateurs d'albums photo, de montage vidéo, de tableurs, etc. Pour tous ces usages l'emploi de SQLite pour la gestion de la persistance de ses données est très pertinent, je le maintiens.>>

Faut pas pousser non plus, pour tous les exemples que tu cites, des formats de fichiers textes tout simple suffisent largement. L'utilisation d'une DB, quelle qu'elle soit, ne se justifie que si tu as vraiment un gros tas de données à acceder rapidement. Pour un truc comme spamprobe par exemple, ça se justifie. Pour un lecteur news, un client RSS, ou un gestionaire d'album photo, c'est de l'over-engineering de débutant.

Ah, pareil chez moi, 2-3mn de temps de compil en moyenne, presque 20 pour le total, et c'est vrai, ca gave. Malheureusement les langages de scripts ne sont pas une option pour ce que je fais, en attendant je garde un bouquin a cote du clavier pour lire pendant les compils :-).

Tu sais combien coute l'entrée dans ce genre de meeting en général ? Un truc comme Java One par exemple :

http://javaone.medialiveinternational.com/sf2004/registration.html(...)

> Comparé au temps d'accés à ton fichier de conf, le parsing xml est probablement pas très couteux.

"Famous last words". Pour un fichier de config tu vas très probablement vouloir parser ça en DOM plutôt qu'en SAX, et ça c'est pas gratuit du tout. Ou alors tu vas te faire chier a coder un parser SAX qui ne sera pas beaucoup plus simple qu'un parser pour un format custom, et forcément moins rapide.

Ah ouais, plus d'1mn de temps de compil, c'est vraiment enorme. :-)

Y a aussi Rosegarden : http://rosegardenmusic.com(...) :-)

Il manque un seul chose a arts, c'est de pouvoir utiliser le hardware mixing quand il est present.

Il lui manque aussi d'etre un minimum stable. La derniere version (avec KDE 3.2.1) plante des que tu lui envoies 2 requetes un peu trop rapprochees (si tu as une notif audio sur le changement de desktop par exemple, et que tu passes vite d'un desktop a un autre, arts plante aussi sec).

Il y a eu recemment un thread la dessus sur kde-devel (ou kde-core-devel, je ne sais plus), ou plusieurs personnes se sont plaint de arts et discutaient de solutions alternatives, Stefan n'a meme pas participe.

arts est un fiasco complet. La base est trop fragile et le peu d'UI qu'il y a (pour les plugins) est moche (genre "proto vite fait"), principalement parce que beaucoup trop de temps a ete passe sur des features "sexy" mais que personne n'utilise (genre avoir une reverbe sur le beep qui te previent de la reception d'un mail).

Parce que virer arts == recoder toutes les applis multimedia de kde.

Non, il suffit de recoder une lib avec la meme API mais qui marche. 99% des applis multimedia de KDE font juste "play()".

- La license Qt coute des nefles comparé au cout de dev d'une appli (moins d'1 mois de salaire d'un ingé).

- Les boites préfèrent payer une license d'utilisation et être tranquille sur le plan légal que se poser des questions pour savoir si la LGPL leur convient ou pas.

Donc, une bonne fois pour toute :

LA LICENSE DE Qt N'EST PAS UN PROBLEME.

Tu es sur que vous savez coder en C++ dans ta boite ? :-)

Et tu es sur que le programme en C que tu trouves si simple a fixer est vraiment aussi complexe que les programmes en C++ ?

Ton argument sur la simplicite du C par rapport a C++ est vide. C'est comme dire qu'une bicyclette est plus simple qu'une voiture, et que les conducteur perdent du temps a reparer des pannes qu'un cycliste n'aurait pas. C'est vrai, mais les deux ne rendent pas le meme service, si un cycliste cherche a faire la meme chose avec son velo qu'un conducteur avec sa voiture (genre aller de Paris a Nice ou depasser les 50 km/h), il va comprendre pourquoi le conducteur a choisi la voiture.

Il semble que tu ais encore la naivete des programmeurs debutants qui n'ont pas encore vraiment ete confrontes a des problemes reels. Ou alors tu es completement coince dans tes certitudes, ce qui est plus grave.

Comme on dit dans ces cas là : "si tu poses la question, c'est qu'il ne sert à rien de te répondre".

Non. j'affirme juste qu'il y a un tas de langages qui ne pourront pas être portés efficacement dans cet environnement et qui par ricochet souffriront de la comparaison avec c# (ou même java).

C'est sans importance. Le but des langages autres que C# sous .NET n'est pas de permettre de developper avec mais de recuperer sans trop de pbs du code existant. Personne ne va developper en Managed C++, par contre faire un wrapper avec autour d'une grosse appli C++ que tu n'as pas envie de re-ecrire en C#, oui.

Mais pour developper une appli neuve, tu vas evidemment prendre C# sans te poser de questions.

je me suis servi de Ruby pour decouper en morceaux et appliquer quelques operations a un dico japonais->francais qui etait sous forme d'un ficher texte, en unicode.

Et ca a tres bien marche.

Ben oui, tu manipules toujours des bytes, ca ne veut pas dire que Ruby supporte l'unicode :-). Tu as essaye d'appliquer des regexp dessus, ou de faire des regexps en unicode ?

(et pour info, non, les strings Ruby ne sont pas en Unicode, et y a rien dans Ruby pour gerer l'Unicode. Ca m'a surpris aussi mais c'est pourtant vrai).

Quel rapport ? C'est Pango qui gere l'unicode, pas Ruby.

Ruby est fait par un japonais, par consequent au niveau des encodages il est nickel. Il gere bien sur l'unicode.

Tu es sur ? :-) Verifie bien. Si tu as une URL qui prouve que Ruby supporte l'Unicode, je suis interessé.

C'est tout le contraire. J'ai discuté avec des inges du stand MS lors de la dernière Linux Expo à Paris, et ils parlent de Mono très ouvertement. Demande-leur si il y va y avoir une implementation Linux de .NET, ils te répondent : "oui, Mono". La raison est simple, ça légitimise .NET qui n'est plus ainsi un truc MS-only dont tout le monde se méfie.

Ah, enfin un qui sait compter. :-)

> développe une appli avec des librairies graphique QT et ensuite recompile sous windows : ha ben zut, ça marche pas...

Mais si ca marche (sauf si tu appelles des API specifiques Linux en plus de Qt).

Passe mon nom dans Google, et reviens me dire si j'ai l'air de quelqu'un qui cherche à "discréditer le libre" :-).

Par ailleurs, je suis surpris de lire que tu contestes l'évolution mondiale malthusienne que l'on peut qualifier de surpopulation.

Je ne sais pas ce qu'est "l'évolution mondiale malthusienne". Le fait est qu'une partie de la planète consomme trop, ça ne signifie pas qu'il y ait surpopulation, et tenter de réduire la population chez ceux qui consomment trop (ce qui est déjà en train de se produire) n'y changera pas grand chose.

Ceci dit, je ne suis pas lui, je peux me tromper, lui seul peut dire ce qu'il en est.

Ben la prochaine fois qu'il passe près de chez toi, heberge-le, tu verra bien :-)

J'y lis des propos d'opposition au logiciel libre que j'ai déjà vu ailleurs, sans grand intérêt. Je n'y souscris pas.

Il ne s'agit pas évidemment des propos de l'auteur de l'article mais de ceux de RMS qui y sont rapportés (et qui sont grosso-modo les mêmes que ceux que j'ai entendu jeudi).

Surconsommation n'implique pas surpopulation, les problèmes que tu évoques sont bien plus complexes que ça.

Le point de vue exprimé est très rationnel.

Non seulement il n'est pas rationnel parce qu'il nie une pulsion fondamentale de l'être humain (avoir des enfants), mais il est faux (la planète n'est pas surpeuplée).

Je ne pense pas que les réponses aux deux questions que tu as citées étaient si sérieuses que cela.

J'y étais, je t'assure qu'il était tout à fait sérieux.

Il s'agit plus de mettre en avant le fait que les gens ont leur responsabilité dans leurs actes, à mon avis, sans pour autant faire leur procès.

Je pense que ton admiration pour lui t'empèche d'avoir une opinion objective. Tu peux aller voir :

http://beust.com/stallman.html(...)

pour te prouver que son délire ne date pas d'hier.