Résultats
XML est
- un langage informatique de balisage : 1150 votes.
- gainial \o/ : 176 votes.
- excellent pour échanger des données : 739 votes.
- pratique : 470 votes.
- une usine à gaz : 462 votes.
- une pourriture infâme : 484 votes.
- utilisé dans mon entreprise : 115 votes.
- décideur compliant : 491 votes.
- moins à la mode qu'AJAX : 403 votes.
Total : 4490 votes
Vous avez demandé le commentaire #770470.
Run by 
Cette page a été générée par Templeet en 0.0792s (dont 0.0063 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
une immondice infame
XML est peut-être bien pour l'echange de données mais quand je vois des protocoles (upnp par exemple) et programmes l'utiliser en interne, alors là, je dis que c'est du délire.
Rien ne vaut le binaire. Surtout dans l'embarqué.
A+
[ Répondre ]
[^]Re: une immondice infame
J'ai voté immondice infâme aussi. Parmi les choses qu'on peut reprocher, voici une courte liste:
* XML est trop verbeux, il prend trop de place (cf: JSON, YAML) - il y a aussi le binaire mais ce n'est pas forcément extensible, et puis on peut aussi zipper les données
* XML est pas du tout évident à parser (namespaces, modes dom/sax, etc) ni à débogger - j'attends de voir un parser rapide et ayant toutes les fonctionnalités
* Les dtds ne sont pas en XML
Plus d'infos: http://xmlsucks.com
[ Répondre ]
[^]Re: une immondice infame
« XML est trop verbeux, il prend trop de place (cf: JSON, YAML) - il y a aussi le binaire mais ce n'est pas forcément extensible, et puis on peut aussi zipper les données »
C'est le prix à payer pour quelque chose de totalement générique d'une part, et à peu près lisible pour un humain d'autre part. La représentation interne d'un fichier XML (en mémoire dans la machine) n'est que celle d'un arbre : beaucoup moins verbeux, donc.
« Les dtds ne sont pas en XML »
D'où la création des schémas XML, qui possèdent une sémantique plus forte que les DTD. Cependant, la DTD permet de définir très simplement les balises. Il est plus simple à mon avis d'écrire une DTD, de la transformer en schéma XML (via un outil qui automatise la tâche), et ensuite de compléter ledit schéma.
Dans tous les cas, si tu veux spécifier du XML en XML, tu peux.
[ Répondre ]
[^]Re: une immondice infame
JSON est totalement générique aussi, et pourtant il est largement plus lisible pour un humain mais aussi pour des parseurs à écrire (pareil pour YAML).
La représentation XML prend de la place, de la bande passante, et n'est certainement pas simple à débogger. Cela explique l'utilisation de JSON avec AJAX en particulier (appel de la fonction "eval" au lieu de responseXML pour obtenir un objet javascript).
Si le format XML était si bien et si générique, alors pourquoi n'ont ils pas commencé par écrire les DTD dans ce format ?
[ Répondre ]
[^]Re: une immondice infame
« JSON est totalement générique aussi, et pourtant il est largement plus lisible pour un humain mais aussi pour des parseurs à écrire (pareil pour YAML). »
Possible, je ne connais pas ces deux solutions.
« La représentation XML prend de la place, de la bande passante, »
Bof. Suffit de compresser le tout (et le XML, ça se compresse bien) avant d'envoyer.
« Si le format XML était si bien et si générique, alors pourquoi n'ont ils pas commencé par écrire les DTD dans ce format ? »
J'en sais rien. Le fait est qu'ils ont commencé par des DTD. La question en fait me semble totalement inutile : le langage C n'a pas su se compiler lui-même dès le départ, à ce que j'ai compris. Maintenant il sait. Est-ce vraiment pertinent de demander pourquoi XML n'a pas su se récrire en XML au début, alors que maintenant il sait ?
[ Répondre ]
[^]Re: une immondice infame
Et le temps CPU pris pour générer une réponse en XML puis de la comprimer, c'est pas plus long que de simplement envoyer le binaire proprement?
Essayez de faire du XML en environnement restreint. Vous m'en direz des nouvelles....
PS: Pascal (et Delphi) ont toujours sus se compiler eux-même si je me souvient bien.
[ Répondre ]
[^]Re: une immondice infame
« Et le temps CPU pris pour générer une réponse en XML puis de la comprimer, c'est pas plus long que de simplement envoyer le binaire proprement? »
Ton binaire, tu l'envoie en little ou big endian ? Il passe à l'échelle 32/64 bits ? (et je suis certain que tout un tas de questions supplémentaires pourraient me venir en tête).
L'intérêt de XML c'est le côté plain-text des fichiers.
« Essayez de faire du XML en environnement restreint. Vous m'en direz des nouvelles.... »
Qu'est-ce que tu appelles environnement restreint ? (de façon générale, je ne suis pas pour le tout-XML, mais les attaques que j'ai vu contre le format n'étaient pas justifiées, de mon point de vue).
« PS: Pascal (et Delphi) ont toujours sus se compiler eux-même si je me souvient bien. »
Tant mieux pour eux. Ce n'était absolument pas le but de ma remarque. LISP aussi sait se compiler lui-même, je ne vois pas en quoi ça change le fait que XML sait se définir en XML, lui aussi. Même s'il est passé par une phase avec DTD qui n'était pas du XML (et à la limite on s'en fout un peu non ? L'important c'est que ton format de stockage soit défini).
[ Répondre ]
[^]Re: une immondice infame
Sachant que tu as prévu que ton binaire soit envoyé par le réseau, tu utilise bien entendu le network byte order...
A vrai dire y a peu prés qu'une archi qui fait des siennes ...
C'est intéressant dans certains cas, mais certainement pas dans une discussions soft à soft.
(je rapelle le post initial de la discussion : quand je vois des [...] programmes l'utiliser en interne )
Sans doute embarqué toussa je présume.
Subete ga wakatta toki…watashi ga anta wo korosu.
[ Répondre ]
[^]Re: une immondice infame
Formulé autrement: XML c'est génial, tant que l'on ne connaît rien d'autre (surtout JSON et surtout YAML).
La question sur les DTD montre à quel point le format (il ne s'agit pas d'un language de programmation) est lisible et pratique à utiliser rien que pour le cas d'utilisation le plus basique.
[ Répondre ]
[^]Re: une immondice infame
« Formulé autrement: XML c'est génial, tant que l'on ne connaît rien d'autre (surtout JSON et surtout YAML). »
Non. D'après le site :
« YAML is optimized for data serialization, configuration settings, log files, Internet messaging and filtering. »
Exactement le genre de choses où je n'utiliserais pas XML (utiliser XML pour faire des fichiers ce configuration est quelque chose de totalement débile la plupart du temps, sauf pour certains logiciels-usines à gaz, et encore).
Pour JSON, on faisait remarquer plus haut que des problèmes de performances pouvaient survenir. Quid de la machine virtuelle JavaScript qui doit tourner ?
« La question sur les DTD montre à quel point le format (il ne s'agit pas d'un language de programmation) est lisible et pratique à utiliser rien que pour le cas d'utilisation le plus basique. »
Je ne vois pas en quoi. Honnêtement, ça ne me dérange absolument pas d'utiliser une DTD tant que la description des données reste simple. Ce que les gens oublient, c'est que XML a été inventé pour être « human readable », mais pas dans une optique « je me farcis tout le texte avec les yeux, tout le temps ». On a tout de suite pensé le format pour qu'il puisse être traité automatiquement par des machines, mais modifiable quand même à la main par des humains, si besoin était.
[ Répondre ]
[^]Re: une immondice infame
>> « Formulé autrement: XML c'est génial, tant que l'on ne connaît rien d'autre (surtout JSON et surtout YAML). »
>
> Non. D'après le site :
>
>> « YAML is optimized for data serialization, configuration settings, log files, Internet messaging and filtering. »
>
> Exactement le genre de choses où je n'utiliserais pas XML (utiliser XML pour faire des fichiers ce configuration est quelque chose de totalement débile la plupart du temps, sauf pour certains logiciels-usines à gaz, et encore).
Donc tu n'utilises pas xml ni pour la sérialisation des données, ni pour les fichiers de configuration, ni pour les fichiers log, ni pour les transferts de données. Tu l'utilises pourquoi déjà ?
> Pour JSON, on faisait remarquer plus haut que des problèmes de performances pouvaient survenir. Quid de la machine virtuelle JavaScript qui doit tourner ?
C'est quoi cette "machine virtuelle JavaScript" ?
>> « La question sur les DTD montre à quel point le format (il ne s'agit pas d'un language de programmation) est lisible et pratique à utiliser rien que pour le cas d'utilisation le plus basique. »
>
> Je ne vois pas en quoi. Honnêtement, ça ne me dérange absolument pas d'utiliser une DTD tant que la description des données reste simple. Ce que les gens oublient, c'est que XML a été inventé pour être « human readable », mais pas dans une optique « je me farcis tout le texte avec les yeux, tout le temps ». On a tout de suite pensé le format pour qu'il puisse être traité automatiquement par des machines, mais modifiable quand même à la main par des humains, si besoin était.
On est donc bien d'accord, XML n'est pas lisible ni pratique d'utilisation.
[ Répondre ]
[^]Re: une immondice infame
Reprenons.
« YAML is optimized for data serialization, configuration settings, log files, Internet messaging and filtering. »
Je me suis mal exprimé (j'ai tapé trop vite).
Tu me demandais : « Donc tu n'utilises pas xml ni pour la sérialisation des données, ni pour les fichiers de configuration, ni pour les fichiers log, ni pour les transferts de données. Tu l'utilises pourquoi déjà ? »
Je ne l'utilise pas pour faire des fichiers de configuration. La sérialisation, oui ; les fichiers de logs je n'ai jamais eu à en faire en XML, et les transferts de données, évidemment.
« C'est quoi cette "machine virtuelle JavaScript" ? »
Je ne savais pas que JavaScript était compilé est s'exécutait sans aide.
J'expliquais ensuite que « human readable » != « humans will like to read it » (en gros). Tu répondais :
« On est donc bien d'accord, XML n'est pas lisible ni pratique d'utilisation. »
Je passe outre le ton ironique. Le XML est effectivement fait pour être techniquement lisible par l'oeil humain.
J'aimerais que tu m'expliques comment tu fais pour avoir des données lisibles par un humain (autrement que du côté technique que j'ai évoqué précédemment) dans un format texte, lorsque tes données sont décrites de façon extrêmement complexe. Au final, si tu as 1To de données, XML ou YAML ou ... je ne vois pas trop ce que ça change dès que le volume généré est important.
Quel que soit le type de données semi-structurées que tu emploies (latex, XML, YAML, etc), tu te retrouves avec une hiérarchie (donc au minimum des arbres - bien que dans le cas du XML tu puisses faire des graphes si tu as besoin de cas tordus),
XML = arbre typé ordonné. C'est tout. Il se trouve que la syntaxe choisie pour XML (balises ouvrantes/fermantes, etc), l'a été pour permettre une bonne automatisation des traitements. Certains trouvent que justement ça l'empêche. Personnellement je ne vois pas en quoi, mais je peux concevoir que ça gêne. Mais on oublie souvent qu'avant XML, des dizaines de formats semi-structurés existaient, mais qu'aucun n'était utilisé partout. XML, c'est le résultat d'une standardisation, avec de gros acteurs industriels qui ont enfin daigné s'asseoir à la même table. Donc non, c'est pas parfait, mais au moins, c'est un format sur lequel des gens bossent (autant les chercheurs que les industriels pur sucre).
[ Répondre ]
[^]Re: une immondice infame
> Reprenons.
>
> « YAML is optimized for data serialization, configuration settings, log files, Internet messaging and filtering. »
>
> Je me suis mal exprimé (j'ai tapé trop vite).
>
> Tu me demandais : « Donc tu n'utilises pas xml ni pour la sérialisation des > données, ni pour les fichiers de configuration, ni pour les fichiers log, ni pour les transferts de données. Tu l'utilises pourquoi déjà ? »
>
> Je ne l'utilise pas pour faire des fichiers de configuration. La sérialisation, oui ; les fichiers de logs je n'ai jamais eu à en faire en XML, et les transferts de données, évidemment.
Et qu'est-ce que tu as utilisé d'autre que xml pour pouvoir comparer ?
> « C'est quoi cette "machine virtuelle JavaScript" ? »
> Je ne savais pas que JavaScript était compilé est s'exécutait sans aide.
Je ne savais pas que JavaScript avait besoin d'une machine virtuelle ?
> J'expliquais ensuite que « human readable » != « humans will like to read it » (en gros). Tu répondais :
>
> « On est donc bien d'accord, XML n'est pas lisible ni pratique d'utilisation. »
>
> Je passe outre le ton ironique. Le XML est effectivement fait pour être techniquement lisible par l'oeil humain.
L'usage montre que non: sinon on écrirait les DTD dedans sans problème.
> J'aimerais que tu m'expliques comment tu fais pour avoir des données lisibles par un humain (autrement que du côté technique que j'ai évoqué précédemment) dans un format texte, lorsque tes données sont décrites de façon extrêmement complexe. Au final, si tu as 1To de données, XML ou YAML ou ... je ne vois pas trop ce que ça change dès que le volume généré est important.
Si justement, ça change énormémént. Les balises énormément de bruit et alourdissent les transferts de données. 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.
> Quel que soit le type de données semi-structurées que tu emploies (latex, XML, YAML, etc), tu te retrouves avec une hiérarchie (donc au minimum des arbres - bien que dans le cas du XML tu puisses faire des graphes si tu as besoin de cas tordus),
>
> XML = arbre typé ordonné. C'est tout. Il se trouve que la syntaxe choisie pour XML (balises ouvrantes/fermantes, etc), l'a été pour permettre une bonne automatisation des traitements. Certains trouvent que justement ça l'empêche. Personnellement je ne vois pas en quoi, mais je peux concevoir que ça gêne. Mais on oublie souvent qu'avant XML, des dizaines de formats semi-structurés existaient, mais qu'aucun n'était utilisé partout. XML, c'est le résultat d'une standardisation, avec de gros acteurs industriels qui ont enfin daigné s'asseoir à la même table. Donc non, c'est pas parfait, mais au moins, c'est un format sur lequel des gens bossent (autant les chercheurs que les industriels pur sucre).
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.
[ Répondre ]
[^]Re: une immondice infame
[utilisations de XML]
« Et qu'est-ce que tu as utilisé d'autre que xml pour pouvoir comparer ? »
Java. :-) Plus sérieusement, j'ai utilisé ce que proposaient des langages compilés pour faire tout ce dont il est question, et XML, point. Je l'ai dit dès le départ, je ne connaissais pas YAML et JSON avant qu'on n'en parle ici. Je ne dis pas que XML est la panacée (en fait, je dis exactement le contraire dans le message auquel tu réponds), juste qu'effectivement pour l'échange de données, ainsi que la sérialisation, XML se prêtait bien à la chose (ah oui, et le stockage BDD aussi).
« Je ne savais pas que JavaScript avait besoin d'une machine virtuelle ? »
Mauvais terme de ma part. Un interpréteur.
« 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.
« 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. 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).
« 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.
[ Répondre ]
[^]Re: une immondice infame
> « 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.
[ Répondre ]
[^]Re: une immondice infame
Bon, je ne réponds qu'à la fin de ton post, ce qui précède n'étant pas argumenté correctement (analogie pas pertinentes, entre autres).
« 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. »
Le rapport avec XML ? Ce sont des structures de données dont tu parles, moi je parle d'un format de stockage, semi-structuré - et donc par définition hiérarchique, auquel la structuration en arbre pour symboliser ladite hiérarchie [des types entre autres] convient bien.
« [...] 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), »
Voyons un peu. HTML/XML sont là pour le contenu, CSS/XSL pour le rendu (et n'oublions pas que XSLT et XQuery vont quand même plus loin que ça, et permettent de générer tout un tas d'autres sorties), JavaScript pour le côté dynamique côté client, et SQL pour les bases de données.
Je ne dis pas que c'est génial, mais j'aimerais que tu m'expliques comment tu comptes simplifier le tout. Le langage généraliste qui fait tout est à exclure, car alors ce serait une usine à gaz monstrueuse (il n'y a qu'à voir les JSP au début - et même maintenant c'est pas joli à voir, malgré les simplifications et le rajout des tags). Il se trouve qu'une base de donnée n'est pas uniquement utilisée par des applications orientées Web, il leur faut donc un langage standardisé pour pouvoir être utilisées (tiens, ce serait assez drôle d'ailleurs de faire remarquer que chaque SGBD/R n'implémente pas tout des normes SQL...).
D'ailleurs, des solutions comme Hibernate pour Java sont plutôt intéressantes, car justement on peut éviter un maximum le côté SQL des SGBD et passer par la correspondance Relationnel/Modèle Objet.
Donc pour faire bref :
1/ À moins de faire une base de données spécialisée Web, les langages de type SQL/XQuery vont rester un bout de temps (et même en ayant une on duplique inutilement les efforts, du coup)
2/ Le langage spécialisé est obligatoire pour faire l'interfaçage front-end/back-end (ou alors tu réussis je ne sais comment à tout faire passer en XML/HTML/XSLT, beurk)
3/ Il te faut bien un moyen de décrire le contenu et le mettre en forme (HTML,XML/CSS,XSL)
4/ Le seul truc éventuellement serait de réussir à fusionner HTML et JS, car effectivement, au final, tout se fait côté client (d'un autre côté, on peut utiliser Javascript à part, et mélanger la description des données avec leur traitement dynamique, bof...)
L'incapacité à faire rapide/peu gourmand/etc vient du fait que le développement spécifique à une plate-forme coûte cher en temps et en expertise, d'autant plus qu'on parle d'outils de haut niveau, extrêmement complexes. Le problème c'est qu'une bonne conception nécessite de bien séparer les modules, et du coup on perd au moins le temps de communiquer entre ceux-ci.
Je te rejoins sur le côté debogage : on est encore à la préhistoire de ce qui pourrait s'envisager, quelle que soit la plate-forme envisagée (et pas seulement pour du Web, même si c'est là que ça pêche le plus).
[ Répondre ]
[^]Re: une immondice infame
> Le rapport avec XML ? Ce sont des structures de données dont tu parles, moi je parle d'un format de stockage, semi-structuré - et donc par définition hiérarchique, auquel la structuration en arbre pour symboliser ladite hiérarchie [des types entre autres] convient bien.
Représenter des données sous forme d'un arbre Lisp, sous forme de tables de hachages (python cpickle) ou sous forme d'une structure javascript revient exactement à la même chose, et les données sont extensibles de la même manière (changement de structure). Pourquoi tant tenir à ajouter des balises ?
> Donc pour faire bref :
J'aimerais en revenir aux cas d'utilisation les plus courants du web:
* transférer des données de façon sécurisée
* transférer des données de façon efficace (éviter d'ajouter du bruit)
* permettre de débogger rapidement et facilement
* échanger des données entre un client et un ou des serveurs
* apporter de la cohérence dans les outils utilisés
La complexité du développement web est aujourd'hui telle que l'on ne peut même pas disposer d'outils d'analyse automatique des erreurs. Quand on voit le résultat, eh bien oui, on est en droit de se poser des questions.
Imaginons un web entièrement en Lisp : sql s'apparente fortement à Lisp, JavaScript aussi, le stockage des données et des feuilles de style peut se faire aussi très facilement sous forme d'une structure Lisp (voir commentaires du dessus) - on peut tout à fait garder la même modularité sous une forme plus facilement utilisables à la fois pour les machines et les programmeurs.
Ce web aurait été effectivement bien plus léger et efficace (Lisp ayant été inventé il y a très longtemps). D'autres langages tels que Python, Ruby ou même une variante fortement typée sont envisageables aussi. C'est d'ailleurs la forme que prend JSON : des tables de hachage très faciles à parser et à analyser. Il était donc possible de faire largement plus simple, et en se basant sur des technologies extrêmement anciennes.
Mais je comprends, quand on ne connaît rien d'autre que XML et que l'on n'a aucune notion des languages passés tels que Lisp il est difficile d'avoir de l'imagination et surtout d'avoir le moindre regard critique pour les outils que l'on utilise.
[ Répondre ]
[^]Re: une immondice infame
« Mais je comprends, quand on ne connaît rien d'autre que XML et que l'on n'a aucune notion des languages passés tels que Lisp il est difficile d'avoir de l'imagination et surtout d'avoir le moindre regard critique pour les outils que l'on utilise. »
Et sur ces bonnes paroles, où tu ne fais qu'être aggressif, et parler pour ne rien dire, je te laisse le dernier mot.
[ Répondre ]
[^]Re: une immondice infame
T'as raison, ça doit être la faute des balises :)
[ Répondre ]
[^]Re: une immondice infame
L'argument de la DTD est un peu foireux... Plus exactement, XML est issu de SGML, comme HTML et les DTDs datent aussi de cette époque là, soit avant le tout XML. Et puis ça fait un bout de temps qu'on peut décrire du XML en XML, inutile de faire les ignorants avec des « gnagna les DTDs »...
Personnellement, le tout XML me gonfle et je trouve la syntaxe lourde à souhait (merci toutes les balises fermantes qui reprennent le nom de l'ouvrante, c'est profondément inutile puisque l'overlapping est interdit).
Après XML, ça marche et pas mal de gens et de machines le comprennent ou peuvent l'apprendre vite.
[ Répondre ]
[^]Re: une immondice infame
On peut aussi faire quelque chose de totalement générique en binaire. Une fois que les types de base sont bien définis, tout est possible.
De plus, la lisibilité par un humain ne me parais pas primordiale. Des outils de traductions binaire<->humain permettent une mise en forme humaine bcp plus lisible que du XML et le programme continue de travailler avec des données binaires optimisées pour son architecture.
Je trouve les schemas XML complètement illisible. Pire que la notation ASN.1.
[ Répondre ]
[^]Re: une immondice infame
Je suis d'accord pour la lisibilité. Dès qu'un document devient un petit peu compliqué, avec une forte granularité (en utilisant une DTD comme TEI par exemple, ou encore du RDF, ou les document généré par OpenOffice, ou un XSL un peu compliqué), le document devient illisible par l'humain qui a besoin d'un outil sérieux pour se retrouver dedans.
On se retrouve donc avec un document long à traiter de toute façon.
[ Répondre ]