Le temps passé à poser des #ifdefs et à bidouiller le build system pour windows, c'est du temps en moins (instabilités, patches, distractions) pour faire le portage vers Qt4.
Si KDE fonctionne sur Windows(tm), c'est tout d'abord grâce aux développeurs de CMake qui ont contribué au portage de KDE, en étendant les fonctionnalités de CMake et en le rendant aussi plus rapide.
Le make distcheck a peu d'importance avec CMake ou Waf sachant que le répertoire des sources est séparé du répertoire de construction.
Dans les cas de Waf le "distcheck" peut s'écrire avec deux lignes de code supplémentaires, cette fonctionnalité n'est pas présente par défaut par manque de demande.
Premièrement, je n'ai aucun espoir qu'un langage devienne populaire (que ce soit caml ou autre) et deuxièmement la syntaxe par défaut est probablement le moindre des problèmes.
Si l'on regarde sh (posix shell) par exemple, cela n'empêche pas 90% des gens de coder en bash et de s'imaginer faire du shell portable.
Pour le cas de caml, il manque de nombreux exemples pour se mettre au langage, la création de bindings avec c/c++ paraît en particulier beaucoup plus difficile qu'avec python ce qui ne donne pas envie de s'y mettre. Autre exemple, l'absence de support pour les librairies partagées compilées (environnements type unix) limite l'intégration de programmes caml avec d'autres applications.
Pour s'intéresser au language, il faut peut-être commencer à s'intéresser à ce qu'on peut faire avec celui-ci dès aujourd'hui (autres que MLDonkey):
La syntaxe de caml n'est pas la meilleure, c'est la raison pour laquelle il existe des préprocesseurs tels que camlp4. J'utilise de préférence twt: http://people.csail.mit.edu/mikelin/ocaml+twt/ qui permet d'obtenir une syntaxe proche de celle de python. Meilleure lisibilité et typage fort, productivité accrue.
C'est le cas depuis un moment, ces icones sont déjà utilisées sur pas mal de sites qui sont bien loin de contribuer aux logiciels libres. Mais bon, du moment que c'est du libre et que c'est utilisé c'est forcément bien.
Merci d'avoir mentionné : "Les utilisateurs Windows auront tout à gagner en utilisant cette version, étant donné que Windows a toujours de très bons "pilotes" pour presque toutes les cartes graphiques."
On aurait pu s'abstenir de passer une telle remarque, qui n'apporte absolument rien pour les utilisateurs de Linux (Linuxfr?), et qui de plus contribue à propager une mauvaise image des systèmes libres ("Linux ca fonctionne mal car pas de drivers", etc).
On peut aussi se demander à quoi bon promouvoir les logiciels libres puisque finalement tout fonctionne si bien (et même mieux) sous Windows. On se peut se demander si il n'y a pas une perte d'identité de pas mal de projets libres ces derniers temps, où pour qu'un projet reste populaire, il faut qu'il fonctionne d'abord sur Windows (exemple: KDE enfin sous windows).
D'où le logo en forme d'oignon ? le code Perl c'est lacrymogène ? :-)
Blague à part, l'interpréteur Perl possède les outils adéquats pour éviter de faire du code illisible (perl -w et le mode non tainted), je n'ai pas vu pour l'instant de code illisible écrit sur ces bases.
Posté par . . .
En réponse au sondage XML est.
Évalué à 1.
> 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.
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.
Posté par . . .
En réponse au sondage XML est.
Évalué à 0.
> 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.
Posté par . . .
En réponse au sondage XML est.
Évalué à 0.
>> « 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.
Posté par . . .
En réponse au sondage XML est.
Évalué à 0.
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.
Posté par . . .
En réponse au sondage XML est.
Évalué à 0.
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 ?
Posté par . . .
En réponse au sondage XML est.
Évalué à 0.
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
[^] # Re: Je n'apprécie guère les portage sous Windows
Posté par . . . En réponse à la dépêche KDE devient multiplateforme. Évalué à 1.
[^] # Re: Je n'apprécie guère les portage sous Windows
Posté par . . . En réponse à la dépêche KDE devient multiplateforme. Évalué à 1.
[^] # Re: Je n'apprécie guère les portage sous Windows
Posté par . . . En réponse à la dépêche KDE devient multiplateforme. Évalué à 5.
Si KDE fonctionne sur Windows(tm), c'est tout d'abord grâce aux développeurs de CMake qui ont contribué au portage de KDE, en étendant les fonctionnalités de CMake et en le rendant aussi plus rapide.
[^] # Re: Autotools vs CMake
Posté par . . . En réponse à la dépêche KDE devient multiplateforme. Évalué à 2.
Dans les cas de Waf le "distcheck" peut s'écrire avec deux lignes de code supplémentaires, cette fonctionnalité n'est pas présente par défaut par manque de demande.
[^] # Re: Tout bon!
Posté par . . . En réponse à la dépêche OCaml summer project. Évalué à 1.
Si l'on regarde sh (posix shell) par exemple, cela n'empêche pas 90% des gens de coder en bash et de s'imaginer faire du shell portable.
Pour le cas de caml, il manque de nombreux exemples pour se mettre au langage, la création de bindings avec c/c++ paraît en particulier beaucoup plus difficile qu'avec python ce qui ne donne pas envie de s'y mettre. Autre exemple, l'absence de support pour les librairies partagées compilées (environnements type unix) limite l'intégration de programmes caml avec d'autres applications.
Pour s'intéresser au language, il faut peut-être commencer à s'intéresser à ce qu'on peut faire avec celui-ci dès aujourd'hui (autres que MLDonkey):
Le solveur d'équations de Kalzium est écrit en caml http://edu.kde.org/kalzium/screenshots.php (basé sur eqchem : http://freehackers.org/~tnagy/eqchem.html), ce composant n'a toujours pas pu être réécrit en c++ malgré les efforts de l'auteur de Kalzium (utilise le solveur de contraintes "Facile" http://www.recherche.enac.fr/opti/facile/)
L'environnement de développement Coq peut permettre de s'ouvrir au domaine des preuves formelles.
Tout n'est pas forcément bon à prendre, mais il y a énormément à apprendre.
[^] # Re: Tout bon!
Posté par . . . En réponse à la dépêche OCaml summer project. Évalué à 2.
[^] # Re: LGPL
Posté par . . . En réponse au message Licence des icones Crystal de KDE. Évalué à 1.
# Kdirstat
Posté par . . . En réponse au message [Admin] Traquer les fichiers gourmands en espace disque. Évalué à 1.
Faire du -s *|sort -rn permet de faire le ménage, mais pas à tous les niveaux de l'arborescence.
# Merci d'avoir mentionné
Posté par . . . En réponse à la dépêche K3DSurf 0.6.0 : Mise à jour majeure. Évalué à 2.
On aurait pu s'abstenir de passer une telle remarque, qui n'apporte absolument rien pour les utilisateurs de Linux (Linuxfr?), et qui de plus contribue à propager une mauvaise image des systèmes libres ("Linux ca fonctionne mal car pas de drivers", etc).
On peut aussi se demander à quoi bon promouvoir les logiciels libres puisque finalement tout fonctionne si bien (et même mieux) sous Windows. On se peut se demander si il n'y a pas une perte d'identité de pas mal de projets libres ces derniers temps, où pour qu'un projet reste populaire, il faut qu'il fonctionne d'abord sur Windows (exemple: KDE enfin sous windows).
--
Bon logiciel tout de même.
[^] # Re: La réponse est simple
Posté par . . . En réponse à la dépêche Le monopole de Microsoft : mode d'emploi. Évalué à 0.
[^] # Re: Foutaises
Posté par . . . En réponse à la dépêche Le monopole de Microsoft : mode d'emploi. Évalué à 1.
[^] # Re: Foutaises
Posté par . . . En réponse à la dépêche Le monopole de Microsoft : mode d'emploi. Évalué à 1.
[^] # Re: Peux pas m'empêcher
Posté par . . . En réponse à la dépêche PeerTV pour Linux. Évalué à 4.
Blague à part, l'interpréteur Perl possède les outils adéquats pour éviter de faire du code illisible (perl -w et le mode non tainted), je n'ai pas vu pour l'instant de code illisible écrit sur ces bases.
# avec mplayer ?
Posté par . . . En réponse au message Probléme récent de lecture DVD saccadée. Évalué à 0.
[^] # Re: IronPython
Posté par . . . En réponse à la dépêche Mono passe en version 1.2. Évalué à 1.
[^] # Re: une immondice infame
Posté par . . . En réponse au sondage XML est. Évalué à 1.
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.
[^] # 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.
[^] # Re: une immondice infame
Posté par . . . En réponse au sondage XML est. Évalué à 0.
>
> « 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.
[^] # Re: une immondice infame
Posté par . . . En réponse au sondage XML est. Évalué à 0.
>
> 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.
[^] # Re: une immondice infame
Posté par . . . En réponse au sondage XML est. Évalué à 0.
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.
[^] # Re: une immondice infame
Posté par . . . En réponse au sondage XML est. Évalué à 0.
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 ?
[^] # Re: une immondice infame
Posté par . . . En réponse au sondage XML est. Évalué à 0.
* 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
[^] # Re: AJAX = ....
Posté par . . . En réponse au sondage XML est. Évalué à 1.
[^] # Re: AJAX = ....
Posté par . . . En réponse au sondage XML est. Évalué à 1.