Non, pardon. Et à part çà, t'as un commentaire intelligent à formuler ou tu cherchais juste l'occasion de coller "anus" dans une phrase à la grammaire approximative?
T'es bien le genre une adresse en @gcu-squad.org. Si c'est pas déjà le cas, vas vite leur en demander une. Il paraît qu'ils bradent durant les vacances scolaires.
Tiens, une pelle, un seau et de la crème solaire. Maintenant retourne faire des pâtés de sable sur la plage.
Mais pourquoi fait-on autant de pub pour ces mecs là? Sérieusement, y'a près de la moitié des commentaires qui parlent de cette bande d'ados attardés. Faudrait songer à les laisser jouer dans leur bac a sable sur IRC.
A part foutre leur merde dans les expos et coller des news (qu'ils repompent toujours des 3 pauvres mêmes sites d'infos *BSD) avec des textes qu'ils sont seuls à trouver drôles sur leur Wordpress à deux balles, ils ne font absolument rien pour le logiciel libre.
Ils ne se rendent pas compte à quel point ils sont ridicules. Honnêtement, il faut passer sur leur canal de temps en temps. Toujours à se prendre pour les sheriffs de l'Open Source, s'auto-congratuler à chaque fois qu'une variante de BSD implémente une fonctionnalité que Linux a dejà depuis 3 ans. Ils sont juste pitoyables.
- On ne peut pas écrire du code imbitable en Python.
Faux! Quand bien même tu refuses d'accepter l'exemple de l'obfuscation, un développeur a toujours la possibilité d'écrire des fonctions ayant pour nom un ou deux caracteres. Idem pour les noms de variables. Même si le langage impose des restrictions sur la présentation pour améliorer la lisibilité, le code reste imbitable. Et cela est valable pour n'importe quel langage!
- Personne n'utilise lambda() ...
Faux! L'extrait du blog de Guido van Rossum (datant d'il y a 18 mois, pas moins) que tu donnes est ridicule. Il ne dit rien des motivations de GvR pour retirer ces fonctions. Le principal grief qu'il a contre celles-ci sont d'ordre esthétique : pour le néophyte, ces fonctions peuvent être déroutantes, et pour chacune d'elles il donne une syntaxe moins 'fonctionnelle' produisant un résultat équivalent.
Il semble cependant que la tétrachiée de commentaires à cette entrée l'ait soit convaincu, tout du moins forcé à revenir sur sa décision.
Ne t'en déplaise, il semblerait qu'une minorité (suffisament bruyante cependant) utilise lambda(), map() et consorts en Python.
- Le rejet de programmation fonctionnelle par GvR
J'avoue manquer d'information sur le processus de validation de ce qui rentre et de ce qui sort de Python à chacune des releases. Cependant, l'incorporation du PEP-309 dans Python 2.5 --qui permet de faire du currying via 'partial'-- me laisse penser que la programmation fonctionnelle en Python a encore de beaux jours devant elle.
Pour finir, le ton condescendant. C'est généralement le ton que j'utilise lorsque je lis des affirmations non fondées, non réfléchies ou emprunte d'une bêtise incommensurable comme tu as pu en écrire. Je puis t'assurer que j'aurais utlisé une formulation crue bien plus tôt si j'avais su que cela avait ta préférence.
Mon Dieu, mon Dieu. La propension qu'ont certains à être stupide et à vouloir le faire savoir reste pour moi quelque chose de fascinant.
Passons. Dans un désir d'éduquer les plus idiots, je tiens à faire partager ce petit morceau de code trouvé en une minute grâce à GrandMa' Google. Attention, Mr. gallenza, ceci pourrait ébranler les fondements même de votre conception de la réalite. Je vous conseille donc de vous accrocher fortement à un objet qui vous tient à coeur. Un nounours, une tétine ou un doudou feront très bien l'affaire.
Je m'excuse d'avance, mais perl, python ne sont pas pour moi des languages de haut niveau, plus de script. D'ailleurs je pense que l'on dira plus facilement un script perl qu'un programme perl. Je ne veux pas dire que perl, c'est de la ...., mais, moi développeur, je veux un language facile, portable, graphique inclus (GUI).
Puisque le fait de s'excuser par avance semble permettre de se dédouaner de dire n'importe quelle connerie, je souhaite donc m'excuser par avance, mais tiens à vous signaler que vous êtes au mieux un troll velu, au pire un idiot et un incompétent dont je ne recommanderai le CV à personne.
La première phrase à elle seule démontre clairement votre totale ignorance en matière de théorie des langages. Un langage de script EST un langage de haut niveau. Un langage de haut niveau est un langage qui donne un plus haut niveau d'abstraction que le langage machine. Cela permet de ne pas avoir à se soucier de certains détails dépendants du matériel tels que par exemple, l'allocation de mémoire, les registres, la pile d'exécution, etc. En général, plus le niveau est haut, plus le langage est spécialisé dans une tâche particulière.
Le terme "langage de script" est plus difficile à définir. Initialement, un langage de script était un langage permettant de joindre des composants déjà existants ou d'automatiser certaines tâches manuelles. Souvent dotés d'une syntaxe plus compacte, ils sont de-facto des langages de haut niveau. Le consensus actuel (et la bêtise ambiante qui plombe l'industrie informatique en général) tend à faire l'amalgame entre langage de script et langage interprété.
À lire votre commentaire, on peut légitimement se demander si votre expérience avec Perl ne se resume pas qu'à des oneliners pour parser des logs apache. Si vous avez un jour l'occasion de rencontrer un programmeur de chez Amazon, j'aimerai être là pour le voir vous botter le cul lorsque vous lui parlerez de ses "scripts perl".
Vos désirs de developpeurs semblent légitimes, et en me basant sur vos propres critères, j'en viendrai presque à m'étonner de votre attachement à Java. Soit, la "facilité" d'un langage reste une notion que vous aurez, je l'espère, l'occasion de m'expliquer. À défaut d'avoir la votre, je vais utiliser ma définition.
Un langage "facile" serait un langage qui me permette simplement de manipuler des structures de données, de pouvoir transcrire sans verbosité excessive aussi bien des algorithmes simples que complexes, qui soit suffisamment flexible de manière à ce que tout changement inopiné des spécifications ne soit pas un casse-tête à implémenter. Perl correspond parfaitement à cette définition en ce qui me concerne. J'attends toujours que l'on me montre comment réaliser simplement une transformation Schwartzienne en Java.
<digression>
Les commentaires concernant la "lisibilité" de Perl faisant référence indirectement ou non à l'exercice stylistique connu sous le nom de perl golf au sein de la communauté Perl ne m'intéressent pas. On peut écrire du code imbitable dans n'importe quel langage. Ce n'est pas parce que l'Obsfucate C existe que les développeurs en font usage dans les sources du noyau Linux.
</digression>
Si par portabilité, vous parlez du nombre de plateformes où votre application peut tourner, je suis heureux de vous annoncer que Perl est disponible sur un plus grand nombre de plateformes que Java. Si vous évoquez le fait que le même code tourne sur plusieurs plateformes, Java effectivement a un léger avantage (pour autant que JNI ne soit pas utilisé) comparé à Perl par exemple (qui souffre du même problème si l'on utilise XS).
Le problème de l'interface graphique en Perl existe en effet, mais est loin d'être insurmontable, des bindings existent pour Tk, WxWidgets, GTK, Qt, et d'autres encore. À ma connaissance, Python souffre moins de ce problème et possède des bindings avec de nombreux toolkits. Le fait que Microsoft ait embauché le créateur d'IronPython est un plus indéniable pour l'adoption du langage sous Windows.
Java a certainement sa place dans le monde des langages informatiques, mais est à des années lumières d'être un langage parfait, n'en déplaise à certains fanatiques vociférants. Nombreux sont les langages qui offrent des fonctionnalités puissantes que Java, au mieux, implémente de manière bancale ou simplement ignore. Je ne puis que vous inviter à essayer d'autres langages, dans d'autres familles pour vous en rendre compte. Une connaissance, sans aller jusqu'à devenir un guru s'entend, de Smalltalk, Prolog ou Lisp pour n'en citer que quelques uns vous apportetait des outils supplémentaires à vos habitudes de programmeur et vous éviterait probablement le ridicule sur des forums publiques.
La libsyck de why the lucky stiff est une implementation en C. C'est rapide, ca marche tout seul, et ca prend meme pas 5 secondes à trouver sur Google (essaie Yaml +implementation +C)
Je me donne le badge de la honte pour répondre à mon propre message. Veuillez oublier ma remarque concernant YAML, un petit malin a cru bon d'en faire mention sans m'en parler alors que je tapais mon message.
méchant!
Note cependant, c'est pas si nouveau que çà : les premières implémentations ont plus de 4 ans, et certains languages tels que Ruby peuvent nativement (c.a.d sans utilisation de module/librairie externe) loader et/ou dumper du YAML.
Bon, d'accord, admettons que ce soit sérieux, ton post a tout de même 3-4 ans de retard. Si, si, souviens toi. La belle époque où tout le monde faisait les louanges du XML, ou l'on entendait partout "XML c'est le futur coco!"...
Aujourd'hui? Mis à part les merveilleux webservices (mais si, les trucs qui on fait éclater tous les buzzword-o-meters de nos managers préférés juste après la période XML-du-sol-au-plafond) je vois pas grand chose qui utilise du XML. Pourquoi? Pour la simple et bonne raison que le XML --attention ça risque de choquer-- c'est une plaie!!! Et qu'on ne vienne pas me parler d'OOo, vous tapez du XML quand vous l'utilisez? ... C'est bien ce que je pensai.
Je vois ici ou là "le XML c'est éditable". FOUTAISES (je reste poli)!!! Ceux qui disent çà sont ceux qui pensent que httpd.conf est un fichier qui utilise toute la puissance du XML parce qu'ils y ont vu <IfModule></IfModule>. Je leur suggère de bien tourner 7 fois leur langue dans la bouche avant de l'ouvrir la prochaine fois. Le XML n'est pas fait pour être édité, le XML c'est 2Mo de charabia imbitable qui vont se faire défoncer par un parser 10 fois plus gros afin de récupérer 5 pauvres lignes de données exploitables.
Admettons. on en arrive au full-XML (systèmes de fichiers, config, protocoles, fichiers, tout... on renomme les protocoles réseau en XTCP/XIP, c'est la fête coco, faut se lacher). TOUT LE MONDE doit devenir un XML guru, c'est une obligation. Pourquoi? Parce que si tu te croutes dans ton XML, tu pêtes tout. Ça vous plairait de plus pouvoir redémarrer votre box parce que la dernière fois que vous avez édité fstab vous avez oublié un "/"? Aaaaaaaaaah, on fait moins les malins maintenant!
Admettons, tous les éditeurs de texte du monde incluent dorénavant des validateurs XML qui vous empêchent de sauvegarder si votre XML n'est pas correct (vous êtes bien sur prêts à envoyer vos patchs pour implémenter cette feature, n'est-ce pas?) pourquoi aller se casser le cul à taper 1000 caractères pour rajouter une ligne dans /etc/fstab? Non, ce qui serait mieux, ca serait de taper le nouveau fs "naturellement" et l'éditeur rajouterait le XML comme un grand en se basant sur une DTD pour l'appli en question. Ouais, ça roske cousin (bien sur, vos patchs sont déjà prêts non?). Et bien alors? Pourquoi se casser le cul a avoir un fichier XML au final, si c'est juste pour taper les infos nécéssaires?
XML est un outil puissant dont l'utilisation devrait être cantonnée aux situations où il est est vraiment indispensable. Pour les autres cas "KISS" devrait être un signal d'alarme universel pour prévenir toute vélléité d'usage du XML.
Un exemple simple qui me vient l'esprit là, tout de suite, maintenant (promis si vous me laissez du temps, je peux en sortir plus), le XML arrange les données sous forme de hiérarchie, d'arbre, de whatever... Pourquoi, ô grand pourquoi, devrait-on utiliser un tel outil pour représenter des données plates? Juste pour le plaisir de faire de la récursion? Mouaip...
Pour les indécrottables convaincus que XML say-le-bien, je vous renvoie aux blogs de certains devs Gnome qui pestaient contre le fait que la majorité des applis se goinffraient de mémoire au lancement juste pour parser du XML. Ce n'est pas parce que la machine que Madame Michu achète aujourd'hui chez [un grossiste en électroménager de votre choix] a 4 fois plus de RAM par défaut qu'il y a 3 ans que les applis doivent être codées de manière porcine.
Pour reprendre une expression utilisée y'a pas si longtemps par sa sainteté Linus himself lors de sa quête d'un nouveau SCMS après les déboires avec BK, le père de melenusme recherchait "the right tool for the right job." XML n'est certainement pas la solution universelle à tous les problèmes. Suivant les cas, les alternatives sont multiples et souvent bien plus utilisables. Je m'étonne que personne n'ai suggéré YAML (par exemple) pour la problématique des fichiers de conf.
[^] # Re: GCU-Squad
Posté par Geraud . En réponse à la dépêche La version 2.0 de DragonFlyBSD est disponible. Évalué à -1.
Non, pardon. Et à part çà, t'as un commentaire intelligent à formuler ou tu cherchais juste l'occasion de coller "anus" dans une phrase à la grammaire approximative?
T'es bien le genre une adresse en @gcu-squad.org. Si c'est pas déjà le cas, vas vite leur en demander une. Il paraît qu'ils bradent durant les vacances scolaires.
Tiens, une pelle, un seau et de la crème solaire. Maintenant retourne faire des pâtés de sable sur la plage.
G.
[^] # Re: GCU-Squad
Posté par Geraud . En réponse à la dépêche La version 2.0 de DragonFlyBSD est disponible. Évalué à 3.
A part foutre leur merde dans les expos et coller des news (qu'ils repompent toujours des 3 pauvres mêmes sites d'infos *BSD) avec des textes qu'ils sont seuls à trouver drôles sur leur Wordpress à deux balles, ils ne font absolument rien pour le logiciel libre.
Ils ne se rendent pas compte à quel point ils sont ridicules. Honnêtement, il faut passer sur leur canal de temps en temps. Toujours à se prendre pour les sheriffs de l'Open Source, s'auto-congratuler à chaque fois qu'une variante de BSD implémente une fonctionnalité que Linux a dejà depuis 3 ans. Ils sont juste pitoyables.
Pauvres nains.
[^] # Re: Java = le diable ?
Posté par Geraud . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 4.
- On ne peut pas écrire du code imbitable en Python.
Faux! Quand bien même tu refuses d'accepter l'exemple de l'obfuscation, un développeur a toujours la possibilité d'écrire des fonctions ayant pour nom un ou deux caracteres. Idem pour les noms de variables. Même si le langage impose des restrictions sur la présentation pour améliorer la lisibilité, le code reste imbitable. Et cela est valable pour n'importe quel langage!
- Personne n'utilise lambda() ...
Faux! L'extrait du blog de Guido van Rossum (datant d'il y a 18 mois, pas moins) que tu donnes est ridicule. Il ne dit rien des motivations de GvR pour retirer ces fonctions. Le principal grief qu'il a contre celles-ci sont d'ordre esthétique : pour le néophyte, ces fonctions peuvent être déroutantes, et pour chacune d'elles il donne une syntaxe moins 'fonctionnelle' produisant un résultat équivalent.
Il semble cependant que la tétrachiée de commentaires à cette entrée l'ait soit convaincu, tout du moins forcé à revenir sur sa décision.
« After about a year of attempts to convince people that lambda had to die or be improved, I gave up. Lambda lives. See http://mail.python.org/pipermail/python-dev/2006-February/06(...) for details. »
Ne t'en déplaise, il semblerait qu'une minorité (suffisament bruyante cependant) utilise lambda(), map() et consorts en Python.
- Le rejet de programmation fonctionnelle par GvR
J'avoue manquer d'information sur le processus de validation de ce qui rentre et de ce qui sort de Python à chacune des releases. Cependant, l'incorporation du PEP-309 dans Python 2.5 --qui permet de faire du currying via 'partial'-- me laisse penser que la programmation fonctionnelle en Python a encore de beaux jours devant elle.
Pour finir, le ton condescendant. C'est généralement le ton que j'utilise lorsque je lis des affirmations non fondées, non réfléchies ou emprunte d'une bêtise incommensurable comme tu as pu en écrire. Je puis t'assurer que j'aurais utlisé une formulation crue bien plus tôt si j'avais su que cela avait ta préférence.
G.
[^] # Re: Java = le diable ?
Posté par Geraud . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 3.
http://www.python.org/doc/essays/ppt/accu2006/Py3kACCU.ppt [Slide 14]
- Last year, I said I wanted lambda to die
- We still don't have a better version
- So lambda lives!
Concernant votre généralisation sur la non-utilisation de reduce, map et lambda, je me retiendrai de commenter.
S'il vous plaît, cessez. Cela vous dessert.
G.
[^] # Re: Java = le diable ?
Posté par Geraud . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 2.
Passons. Dans un désir d'éduquer les plus idiots, je tiens à faire partager ce petit morceau de code trouvé en une minute grâce à GrandMa' Google. Attention, Mr. gallenza, ceci pourrait ébranler les fondements même de votre conception de la réalite. Je vous conseille donc de vous accrocher fortement à un objet qui vous tient à coeur. Un nounours, une tétine ou un doudou feront très bien l'affaire.
< -- snip -- >
#!/usr/local/bin/python
f = lambda x:map(lambda o:(map(lambda c:map(lambda l:
o.__setslice__(l[0],l[1],l[2]),([o[2]+3,o[2]+4,[o[0]]],[0,3,[o[1],
reduce(lambda x,o:x+o,o[:2]),o[2]+1]])),range(x)),o)[1],[[1,1,0]+
range(x)])[0][3:]
print f(20)
< -- snip -- >
Lisible, hein?
Je reste sur ma position.
G.
[^] # Re: Java = le diable ?
Posté par Geraud . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 8.
Puisque le fait de s'excuser par avance semble permettre de se dédouaner de dire n'importe quelle connerie, je souhaite donc m'excuser par avance, mais tiens à vous signaler que vous êtes au mieux un troll velu, au pire un idiot et un incompétent dont je ne recommanderai le CV à personne.
La première phrase à elle seule démontre clairement votre totale ignorance en matière de théorie des langages. Un langage de script EST un langage de haut niveau. Un langage de haut niveau est un langage qui donne un plus haut niveau d'abstraction que le langage machine. Cela permet de ne pas avoir à se soucier de certains détails dépendants du matériel tels que par exemple, l'allocation de mémoire, les registres, la pile d'exécution, etc. En général, plus le niveau est haut, plus le langage est spécialisé dans une tâche particulière.
Le terme "langage de script" est plus difficile à définir. Initialement, un langage de script était un langage permettant de joindre des composants déjà existants ou d'automatiser certaines tâches manuelles. Souvent dotés d'une syntaxe plus compacte, ils sont de-facto des langages de haut niveau. Le consensus actuel (et la bêtise ambiante qui plombe l'industrie informatique en général) tend à faire l'amalgame entre langage de script et langage interprété.
À lire votre commentaire, on peut légitimement se demander si votre expérience avec Perl ne se resume pas qu'à des oneliners pour parser des logs apache. Si vous avez un jour l'occasion de rencontrer un programmeur de chez Amazon, j'aimerai être là pour le voir vous botter le cul lorsque vous lui parlerez de ses "scripts perl".
Vos désirs de developpeurs semblent légitimes, et en me basant sur vos propres critères, j'en viendrai presque à m'étonner de votre attachement à Java. Soit, la "facilité" d'un langage reste une notion que vous aurez, je l'espère, l'occasion de m'expliquer. À défaut d'avoir la votre, je vais utiliser ma définition.
Un langage "facile" serait un langage qui me permette simplement de manipuler des structures de données, de pouvoir transcrire sans verbosité excessive aussi bien des algorithmes simples que complexes, qui soit suffisamment flexible de manière à ce que tout changement inopiné des spécifications ne soit pas un casse-tête à implémenter. Perl correspond parfaitement à cette définition en ce qui me concerne. J'attends toujours que l'on me montre comment réaliser simplement une transformation Schwartzienne en Java.
<digression>
Les commentaires concernant la "lisibilité" de Perl faisant référence indirectement ou non à l'exercice stylistique connu sous le nom de perl golf au sein de la communauté Perl ne m'intéressent pas. On peut écrire du code imbitable dans n'importe quel langage. Ce n'est pas parce que l'Obsfucate C existe que les développeurs en font usage dans les sources du noyau Linux.
</digression>
Si par portabilité, vous parlez du nombre de plateformes où votre application peut tourner, je suis heureux de vous annoncer que Perl est disponible sur un plus grand nombre de plateformes que Java. Si vous évoquez le fait que le même code tourne sur plusieurs plateformes, Java effectivement a un léger avantage (pour autant que JNI ne soit pas utilisé) comparé à Perl par exemple (qui souffre du même problème si l'on utilise XS).
Le problème de l'interface graphique en Perl existe en effet, mais est loin d'être insurmontable, des bindings existent pour Tk, WxWidgets, GTK, Qt, et d'autres encore. À ma connaissance, Python souffre moins de ce problème et possède des bindings avec de nombreux toolkits. Le fait que Microsoft ait embauché le créateur d'IronPython est un plus indéniable pour l'adoption du langage sous Windows.
Java a certainement sa place dans le monde des langages informatiques, mais est à des années lumières d'être un langage parfait, n'en déplaise à certains fanatiques vociférants. Nombreux sont les langages qui offrent des fonctionnalités puissantes que Java, au mieux, implémente de manière bancale ou simplement ignore. Je ne puis que vous inviter à essayer d'autres langages, dans d'autres familles pour vous en rendre compte. Une connaissance, sans aller jusqu'à devenir un guru s'entend, de Smalltalk, Prolog ou Lisp pour n'en citer que quelques uns vous apportetait des outils supplémentaires à vos habitudes de programmeur et vous éviterait probablement le ridicule sur des forums publiques.
Cordialement,
G.
[^] # Re: 18 jours de retard?
Posté par Geraud . En réponse au journal Basculer l'informatique en tout-XML?. Évalué à 2.
Cordialement,
G.
[^] # Re: Pour apporter mon grain de sable au moulin
Posté par Geraud . En réponse au journal Basculer l'informatique en tout-XML?. Évalué à 1.
http://www.symfony-project.com/trac/wiki/InstallingSyck
La libsyck de why the lucky stiff est une implementation en C. C'est rapide, ca marche tout seul, et ca prend meme pas 5 secondes à trouver sur Google (essaie Yaml +implementation +C)
G.
[^] # Re: 18 jours de retard?
Posté par Geraud . En réponse au journal Basculer l'informatique en tout-XML?. Évalué à 3.
méchant!
Note cependant, c'est pas si nouveau que çà : les premières implémentations ont plus de 4 ans, et certains languages tels que Ruby peuvent nativement (c.a.d sans utilisation de module/librairie externe) loader et/ou dumper du YAML.
G.
# 18 jours de retard?
Posté par Geraud . En réponse au journal Basculer l'informatique en tout-XML?. Évalué à 10.
Bon, d'accord, admettons que ce soit sérieux, ton post a tout de même 3-4 ans de retard. Si, si, souviens toi. La belle époque où tout le monde faisait les louanges du XML, ou l'on entendait partout "XML c'est le futur coco!"...
Aujourd'hui? Mis à part les merveilleux webservices (mais si, les trucs qui on fait éclater tous les buzzword-o-meters de nos managers préférés juste après la période XML-du-sol-au-plafond) je vois pas grand chose qui utilise du XML. Pourquoi? Pour la simple et bonne raison que le XML --attention ça risque de choquer-- c'est une plaie!!! Et qu'on ne vienne pas me parler d'OOo, vous tapez du XML quand vous l'utilisez? ... C'est bien ce que je pensai.
Je vois ici ou là "le XML c'est éditable". FOUTAISES (je reste poli)!!! Ceux qui disent çà sont ceux qui pensent que httpd.conf est un fichier qui utilise toute la puissance du XML parce qu'ils y ont vu <IfModule></IfModule>. Je leur suggère de bien tourner 7 fois leur langue dans la bouche avant de l'ouvrir la prochaine fois. Le XML n'est pas fait pour être édité, le XML c'est 2Mo de charabia imbitable qui vont se faire défoncer par un parser 10 fois plus gros afin de récupérer 5 pauvres lignes de données exploitables.
Admettons. on en arrive au full-XML (systèmes de fichiers, config, protocoles, fichiers, tout... on renomme les protocoles réseau en XTCP/XIP, c'est la fête coco, faut se lacher). TOUT LE MONDE doit devenir un XML guru, c'est une obligation. Pourquoi? Parce que si tu te croutes dans ton XML, tu pêtes tout. Ça vous plairait de plus pouvoir redémarrer votre box parce que la dernière fois que vous avez édité fstab vous avez oublié un "/"? Aaaaaaaaaah, on fait moins les malins maintenant!
Admettons, tous les éditeurs de texte du monde incluent dorénavant des validateurs XML qui vous empêchent de sauvegarder si votre XML n'est pas correct (vous êtes bien sur prêts à envoyer vos patchs pour implémenter cette feature, n'est-ce pas?) pourquoi aller se casser le cul à taper 1000 caractères pour rajouter une ligne dans /etc/fstab? Non, ce qui serait mieux, ca serait de taper le nouveau fs "naturellement" et l'éditeur rajouterait le XML comme un grand en se basant sur une DTD pour l'appli en question. Ouais, ça roske cousin (bien sur, vos patchs sont déjà prêts non?). Et bien alors? Pourquoi se casser le cul a avoir un fichier XML au final, si c'est juste pour taper les infos nécéssaires?
XML est un outil puissant dont l'utilisation devrait être cantonnée aux situations où il est est vraiment indispensable. Pour les autres cas "KISS" devrait être un signal d'alarme universel pour prévenir toute vélléité d'usage du XML.
Un exemple simple qui me vient l'esprit là, tout de suite, maintenant (promis si vous me laissez du temps, je peux en sortir plus), le XML arrange les données sous forme de hiérarchie, d'arbre, de whatever... Pourquoi, ô grand pourquoi, devrait-on utiliser un tel outil pour représenter des données plates? Juste pour le plaisir de faire de la récursion? Mouaip...
Pour les indécrottables convaincus que XML say-le-bien, je vous renvoie aux blogs de certains devs Gnome qui pestaient contre le fait que la majorité des applis se goinffraient de mémoire au lancement juste pour parser du XML. Ce n'est pas parce que la machine que Madame Michu achète aujourd'hui chez [un grossiste en électroménager de votre choix] a 4 fois plus de RAM par défaut qu'il y a 3 ans que les applis doivent être codées de manière porcine.
Pour reprendre une expression utilisée y'a pas si longtemps par sa sainteté Linus himself lors de sa quête d'un nouveau SCMS après les déboires avec BK, le père de melenusme recherchait "the right tool for the right job." XML n'est certainement pas la solution universelle à tous les problèmes. Suivant les cas, les alternatives sont multiples et souvent bien plus utilisables. Je m'étonne que personne n'ai suggéré YAML (par exemple) pour la problématique des fichiers de conf.
mes 0.02Euros
G.