Posté par . . .
En réponse au sondage XML est.
Évalué à 1.
> « Si justement, ça change énormémént. Les balises énormément de bruit et alourdissent les transferts de données. »
> Les balises sont redondantes, donc si compression il y a, et donc je ne vois pas en quoi ça alourdirait le transfert de données.
Il faut vraiment faire un dessin ?
Entre un gros camion et une voiture pour transporter le même chargement, tu prends le gros camion ou la petite voiture ?
Si on te donne un autre format de stockage, et qui te fait pareil que ce que tu utilises habituellement (Castor probablement?) mais en plus rapide, plus petit et plus facile à lire, tu l'utiliserais pas ? Ou bien tu veux faire acheter plus de matos à ta boîte ?
> « La meilleure façon de compresser des données, c'est avant tout de ne pas y ajouter du bruit. Ensuite cela alourdit le déboggage des données elles-même. »
>
> De toute manière, dès que tu as un format de données flexible et générique, tu es obligé de gagner en verbosité, XML ou pas XML.
Tautologie ? Si tu as des données compliquées elles sont forcément compliquées ?
> Les softs que je vois traiter de gros volumes XML utilisent leur propre représentation interne des arbres XML, et donc tout se fait en binaire. Le côté « chiant » d'XML c'est le parsing, je suis d'accord - ce qui se traduit aussi par les problèmes de transfert que tu évoques. Mais honnêtement, aussi fastidieux cela soit-il, le fait d'avoir le côté ouvrant/fermant permet justement d'être systématique dans le traitement de l'information (et de faire la validation, etc).
Il n'y a pas confusion entre le format de stockage et l'utilisation que l'on fait des données ?
> « C'est pas parce que c'est utilisé par tout le monde ou standardisé de fait/historiquement que c'est ce qu'il y a de meilleur. Les produits microsoft dominent le marché, je te laisse conclure. »
>
> Je ne peux pas accepter cet exemple, car MS est tout seul à imposer sa vision, alors que pour XML, tu as un collège d'industriels et de chercheurs. Alors oui, ça veut aussi dire qu'on n'obtient pas une forme optimale (chaque participant veut insérer à tout prix SA fonctionnalité de la mort, et pour des raisons « politiques » on laisse faire - ou pas). Mais ça veut aussi dire que pas mal de paramètres sont pris en compte et que l'évolution ne se fait pas à la va-vite.
>
> Pour le côté « standardisé de fait » : c'est justement parce qu'aucun standard n'avait su s'imposer qu'il était temps de faire quelque chose. Le C est un standard de fait dans l'industrie. Java aussi. Pourtant, le C se prête de moins en moins à la programmation généraliste je trouve (l'utilisation de langages de plus haut niveau permet de faire moins d'erreurs de programmation, avec un temps de développement plus réduit), et le Java à toutes les sauces est une aberration informatique.
>
> De façon générale, je ne sais pas depuis quand YAML et JSON existent, mais au pifomètre je dirais « ils sont plus jeunes que XML ». Et quand une structure adopte un changement déjà assez radical en lui-même, tu ne peux pas t'attendre à ce qu'elle change du jour au lendemain (un peu comme la boite qui est pleine de développeurs C et qui ne va pas se mettre au CAML du jour au lendemain). Il faut aussi gérer l'inertie, et crier « XML SAPU » tout en oubliant que, comme tout format, d'autres lui succèdent en tirant partie de ses erreurs (alors que, comme quelqu'un l'a fait judicieusement remarquer, XML a aussi un lourd passif avec SGML), c'est un peu facile.
Le pifomètre ne s'est pas trompé cette fois-ci, mais malheureusement les tables de hachage, les listes et Lisp ont existé bien avant XML.
La maitrise d'un outil, c'est aussi d'en connaître les limites. Aujourd'hui, grâce aux comités qui sortent des standards tous les jours (des chercheurs en informatique amusante), on a besoin d'au moins 5 languages pour faire des simples pages web (sql, java/python/php/langage métier, html/xml, css, javascript), avec une incapacité à faire rapide, peu gourmand en mémoire machine et facile à débogger/analyser.
Les intégristes d'aujourd'hui sont les pionniers d'hier.
[^] # Re: une immondice infame
Posté par . . . En réponse au sondage XML est. Évalué à 1.
> Les balises sont redondantes, donc si compression il y a, et donc je ne vois pas en quoi ça alourdirait le transfert de données.
Il faut vraiment faire un dessin ?
Entre un gros camion et une voiture pour transporter le même chargement, tu prends le gros camion ou la petite voiture ?
Si on te donne un autre format de stockage, et qui te fait pareil que ce que tu utilises habituellement (Castor probablement?) mais en plus rapide, plus petit et plus facile à lire, tu l'utiliserais pas ? Ou bien tu veux faire acheter plus de matos à ta boîte ?
> « La meilleure façon de compresser des données, c'est avant tout de ne pas y ajouter du bruit. Ensuite cela alourdit le déboggage des données elles-même. »
>
> De toute manière, dès que tu as un format de données flexible et générique, tu es obligé de gagner en verbosité, XML ou pas XML.
Tautologie ? Si tu as des données compliquées elles sont forcément compliquées ?
> Les softs que je vois traiter de gros volumes XML utilisent leur propre représentation interne des arbres XML, et donc tout se fait en binaire. Le côté « chiant » d'XML c'est le parsing, je suis d'accord - ce qui se traduit aussi par les problèmes de transfert que tu évoques. Mais honnêtement, aussi fastidieux cela soit-il, le fait d'avoir le côté ouvrant/fermant permet justement d'être systématique dans le traitement de l'information (et de faire la validation, etc).
Il n'y a pas confusion entre le format de stockage et l'utilisation que l'on fait des données ?
> « C'est pas parce que c'est utilisé par tout le monde ou standardisé de fait/historiquement que c'est ce qu'il y a de meilleur. Les produits microsoft dominent le marché, je te laisse conclure. »
>
> Je ne peux pas accepter cet exemple, car MS est tout seul à imposer sa vision, alors que pour XML, tu as un collège d'industriels et de chercheurs. Alors oui, ça veut aussi dire qu'on n'obtient pas une forme optimale (chaque participant veut insérer à tout prix SA fonctionnalité de la mort, et pour des raisons « politiques » on laisse faire - ou pas). Mais ça veut aussi dire que pas mal de paramètres sont pris en compte et que l'évolution ne se fait pas à la va-vite.
>
> Pour le côté « standardisé de fait » : c'est justement parce qu'aucun standard n'avait su s'imposer qu'il était temps de faire quelque chose. Le C est un standard de fait dans l'industrie. Java aussi. Pourtant, le C se prête de moins en moins à la programmation généraliste je trouve (l'utilisation de langages de plus haut niveau permet de faire moins d'erreurs de programmation, avec un temps de développement plus réduit), et le Java à toutes les sauces est une aberration informatique.
>
> De façon générale, je ne sais pas depuis quand YAML et JSON existent, mais au pifomètre je dirais « ils sont plus jeunes que XML ». Et quand une structure adopte un changement déjà assez radical en lui-même, tu ne peux pas t'attendre à ce qu'elle change du jour au lendemain (un peu comme la boite qui est pleine de développeurs C et qui ne va pas se mettre au CAML du jour au lendemain). Il faut aussi gérer l'inertie, et crier « XML SAPU » tout en oubliant que, comme tout format, d'autres lui succèdent en tirant partie de ses erreurs (alors que, comme quelqu'un l'a fait judicieusement remarquer, XML a aussi un lourd passif avec SGML), c'est un peu facile.
Le pifomètre ne s'est pas trompé cette fois-ci, mais malheureusement les tables de hachage, les listes et Lisp ont existé bien avant XML.
La maitrise d'un outil, c'est aussi d'en connaître les limites. Aujourd'hui, grâce aux comités qui sortent des standards tous les jours (des chercheurs en informatique amusante), on a besoin d'au moins 5 languages pour faire des simples pages web (sql, java/python/php/langage métier, html/xml, css, javascript), avec une incapacité à faire rapide, peu gourmand en mémoire machine et facile à débogger/analyser.
Les intégristes d'aujourd'hui sont les pionniers d'hier.