Discussion :

[Jade Emy]

Le langage de balisage extensible XML serait bien mieux que YAML, d'autant que YAML ne sert à rien, d'après Carl Johnson.

Le langage de balisage extensible ou XML est un métalangage informatique de balisage générique dont l'objectif initial est de faciliter l'échange automatisé de contenus complexes entre systèmes d'informations hétérogènes (interopérabilité). Tandis que YAML permet de représenter des informations plus élaborées que le simple CSV en gardant cependant une lisibilité presque comparable. La syntaxe du flux YAML est relativement simple, efficace, moins verbeuse que du XML.

Cependant, dans le podcast Go Time, Carl Johnson déclare que XML est meilleur que YAML. De son point de vue épicé, XML est meilleur que YAML, parce qu'il y a des situations où XML est approprié, mais il n'y a aucune situation où YAML est approprié.

Parlons d'abord de XML

XML a eu une très mauvaise réputation. La raison pour laquelle il a eu cette mauvaise réputation est que les gens l'utilisaient pour des choses pour lesquelles il n'aurait jamais dû être utilisé. XML signifie Extensible Markup Language (langage de balisage extensible). Et si vous l'utilisez comme un langage de balisage extensible, c'est en fait très bien.

Disons que vous travaillez sur quelque chose et que vous vous dites : "Je fais un nouveau type de livre, et j'ai besoin d'annoter tous les versets de la Bible, et d'avoir les titres des chapitres et tout ça." C'est très bien pour ça. C'est vraiment bien quand vous avez un document, que certaines choses sont en italique, que d'autres sont en langue étrangère, qu'il y a des sous-titres et tout le reste. C'est vraiment bien pour ça.

Ce n'est pas bon si c'est comme : "Je dois configurer ce serveur et le serveur doit savoir si cette valeur est vraie ou fausse." Non, ce n'est pas bon. Ne faites pas ça. Ce n'est pas une bonne utilisation de XML.

Mais XML peut être utilisé à certaines fins. Et je pense que le fait que maintenant tout le monde écrive React... et qu'ils l'écrivent avec JSX... et que JSX est fondamentalement juste du XML en ligne... je pense que cela montre qu'il y a des cas où XML est plutôt bon.

YAML d'un autre côté

Je pense que YAML n'est jamais bon. Il y a toujours quelque chose de mieux que YAML ! Nous sommes enfin arrivés à Go 1.21 et j'en suis très heureux. Et vous savez pourquoi ? Parce que YAML m'a toujours mordu le derrière avec Go 1.20. Demandez-moi pourquoi.

Eh bien, quand vous dites dans votre fichier de test : "testez ceci contre Go 1.20". Il interprète cela comme Go 1.2. C'est ainsi qu'à deux ou trois reprises, j'ai eu un repo où je me suis dit : "Ces tests ne passent pas. Pourquoi mes tests ne passent-ils pas ? Je viens de passer à Go 1.20." Et c'était comme : "Oh, non. J'ai décidé que c'était Go 1.2 " Et donc YAML va toujours vous faire ça...

De meilleurs choix

Je comprends pourquoi les gens utilisent YAML, mais il y a de meilleurs choix. Vous pouvez utiliser TOML. Vous pouvez utiliser CUE. Vous pouvez utiliser beaucoup de choses. J'aime la façon dont Caddy le fait. Avec Caddy, le langage canonique que Caddy comprend est JSON, mais ils ont des adaptateurs.

Ainsi, si vous voulez écrire du YAML, vous pouvez le faire. Mais Caddy prend ce YAML et le transforme en JSON dans les coulisses. Il existe également un langage Caddy spécifique. Vous pouvez donc lui donner le langage Caddy et il le transforme en JSON dans les coulisses. Vous pouvez également lui donner une configuration NGINX et il la transformera en JSON dans les coulisses. Si vous disposez des cycles et du temps nécessaires, c'est probablement la meilleure solution pour la plupart des gens...

Mais quand la seule façon de le faire est YAML, c'est comme : "Non... !" C'est trop sujet aux erreurs, il y a trop de choses... Il faut toujours tout citer.

Et puis...

La spécification YAML a toutes ces fonctionnalités que personne n'utilise jamais, parce qu'elles sont vraiment déroutantes et difficiles, et qu'on peut inclure des documents à l'intérieur d'autres documents, avec des références et tout ça... Et c'est du genre : "Oh, mec, je n'ai pas envie de faire ça ! Oh, mec, je ne veux pas avoir à comprendre tout ça."

Et si on ne fait pas attention, ça peut être : "Oh ouais, les trois premiers trucs que je lui ai donnés ont compris ça, mais le troisième a utilisé un analyseur qu'ils ont trouvé à l'arrière d'un camion, et il ne l'a pas compris." et c'est comme : "Oh, mec..."

YAML... jamais approprié. XML est parfois approprié.

Source : Carl Johnson

Et vous ?

Pensez-vous que cette avis est crédible ou pertinent ?
Quel est votre avis sur le langage YAML ?

Voir aussi :

Le langage C ne sera-t-il jamais battu en termes de rapidité d'exécution et de faible consommation d'énergie ? Voici les résultats d'une étude sur 27 langages de programmation les plus populaires

Kubernetes exposé : Un Yaml près du désastre, 72% des installations sont non sécurisées et exposées aux attaques

« Les formules Excel sont le langage de programmation le plus utilisé », d'après Microsoft qui annonce donc LAMBDA
Pour la création des fonctions personnalisées à partir des formules Excel

[Daïmanu]

Il y a des situations où XML est approprié, mais aucune où YAML n'est pas approprié

Oui, XML est beaucoup plus complet, mais au détriment de la lisibilité. Pour une configuration simple, je préfère utiliser YAML.

Si vraiment on a un risque que `version: 1.20` soit interprété comme `version: 1.2`, je vois pas pourquoi on ne pourrait pas utiliser de guillemets.

On n'utilise pas toutes les fonctionnalités de YAML

je pense que c'est applicable à beaucoup d'outils et de langages, cet argument n'est pas spécifique.

J'ai bien entendu ses arguments, mais je ne suis pas convaincu.

[dourouc05]

Oui, XML est beaucoup plus complet, mais au détriment de la lisibilité. Pour une configuration simple, je préfère utiliser YAML.

Ça tombe bien, il ne parle absolument pas de XML pour ce cas d'utilisation !

[Daïmanu]

Ça tombe bien, il ne parle absolument pas de XML pour ce cas d'utilisation !

Effectivement il ne le dit pas ouvertement, mais c'est tout le flou quand il dit que YAML ne sert à rien. Du moins c'est comme ça que je le comprends.

[Zefling]

Autant utiliser des fichiers Json. Quand je tombe sur des fichiers Yaml ça me gave, il suffit de faire une erreur d'indentation et ça casse tout. Bien sûr c'est pas forcément simple de voir le problème. Et plus la configuration est grande, plus je trouve ça horrible.
Pour des fichiers des quelques lignes ça va, et plus ça grandi, plus j'ai vraiment envie d'utiliser autre chose.

[Pyramidev]

Well, when you say in your test file:

“test this against Go 1.20”

It interprets that as Go 1.2. 😭🤣

Avec YAML, quand on écrit une chaîne de caractères, souvent, on peut omettre les guillemets. Mais on peut alors se faire avoir par surprise si les guillemets étaient nécessaires. C'est ce que Colm O'Connor, l'auteur de StrictYAML, nomme The Norway Problem.

Hélas, les formats les plus populaires pour représenter une arborescence lisible par un humain sont souvent nuls.

XML et YAML sont tous les deux des usines à gaz remplies de failles de sécurité. Par exemple, ils sont tous les deux vulnérables à la billion laughs attack. Quand un fichier XML ou YAML est une entrée utilisateur, il faut utiliser un parseur qui n'accepte qu'un sous ensemble de XML ou YAML pour éviter les problèmes. En pratique, j'avoue apprécier la concision de YAML malgré ses défauts.

JSON a ses qualités, mais il y a plusieurs standards qui coexistent. Nicolas Seriot avait écrit un article à ce sujet : Parsing JSON is a Minefield 💣.

Pour les configurations, TOML n'est pas mal. Le problème de JSON est qu'on ne peut pas ajouter des commentaires.

[Zefling]

Pour les configurations, TOML n'est pas mal. Le problème de JSON est qu'on ne peut pas ajouter des commentaires.

Ça c'est un gros problème. L'absence de commentaires rend le format non utilisable dans certains cas.

[Madmac]

Effectivement il ne le dit pas ouvertement, mais c'est tout le flou quand il dit que YAML ne sert à rien. Du moins c'est comme ça que je le comprends.

YAML est un bon outil de transfert de base de données ou pour sérialiser des objets. Et XML est excellent pour faire des trucs comme HTML. Ils ont tous les deux leur force et faiblesses. Le problème est que certains pensent qu'un des deux puisse être utiliser comme une solution universelle.

[olsimare]

A deux doigt de découvrir que JSON c'est bien...

[TJ1985]

Il y a fort, fort longtemps, dans un endroit fort, fort lointain, il nous arrivait de définir un langage propre à l'accomplissement d'un type de tâches spécifiques. Une grammaire restreinte, un vocabulaire précis, tout ce qui n'y entrait pas était rejeté.
Bon, nous étions vêtu de peaux de bêtes, chacun de nous devait maîtriser chaque aspect de sa vie depuis la couture des chaussons jusqu'à l'allumage du feu. Ce genre de truc ne nous posait donc pas vraiment problème. Seul souci, impossible de laisser sa trace au plafond de la caverne, nous étions anonymes, noyés dans l'obscurité de ces âges lointains, sans le plus petit réseau social pour faire notre pub.
Groumpf !

[pcdwarf]

Je suis un vieux c**. J'ai jamais compris l'engouement pour le YAML.
C'est comme JSON mais la clareté en moins.

YAML est un langage assez facile à lire mais difficile à écrire, même avec l'éditeur qui va bien pour gérer l'indentation.

Heureusement, comme le YAML peut s'écrire en JSON et vice versa, c'est assez facile de faire la traduction.

[pcdwarf]

Hélas, les formats les plus populaires pour représenter une arborescence lisible par un humain sont souvent nuls.

Json avec un pretty printer, je trouve ça limpide. En tout cas très largement plus que le YAML

[popo]

Ça c'est un gros problème. L'absence de commentaires rend le format non utilisable dans certains cas.

Le sujet est sur YAML et non JSON.
Et en YAML, un commentaire est introduit avec un #.

Mais juste pour ma culture personnelle, peux-tu préciser dans quel cas l'absence de commentaire est un problème en JSON ?

[Pyramidev]

dans quel cas l'absence de commentaire est un problème en JSON ?

Par exemple, si on bidouille un fichier de configuration pour éviter un bogue, alors il peut être pertinent de laisser sur place un commentaire pour expliquer pourquoi on a mis tel champ avec telle valeur.

[popo]

Par exemple, si on bidouille un fichier de configuration pour éviter un bogue, alors il peut être pertinent de laisser sur place un commentaire pour expliquer pourquoi on a mis tel champ avec telle valeur.

La bidouille ne devrait jamais être une raison valable selon moi.

Et même dans ce cas, il n'y a aucune raison de laisser un commentaire sur le fichier en lui-même.
La place d'un tel commentaire est dans la zone prévue à cet effet lors du push avec ton gestionnaire de versions.

Et, de toute manière, un fichier de configuration est, par définition, normé.
Remplace ceci { "parameter1" : "value" } par ceci { "_parameter1" : "a tiny text to explain the change", "parameter1" : "other" } et tu obtiendras le même résultat que si tu avais mis un commentaire.

[Pyramidev]

Et même dans ce cas, il n'y a aucune raison de laisser un commentaire sur le fichier en lui-même.
La place d'un tel commentaire est dans la zone prévue à cet effet lors du push avec ton gestionnaire de versions.

Si on explique la bidouille uniquement dans le message du commit et pas dans un commentaire du fichier de configuration, alors on augmente les chances que l'explication ne sera pas lue par les prochaines personnes qui mettront à jour le fichier de configuration.

Et, de toute manière, un fichier de configuration est, par définition, normé.
Remplace ceci { "parameter1" : "value" } par ceci { "_parameter1" : "a tiny text to explain the change", "parameter1" : "other" } et tu obtiendras le même résultat que si tu avais mis un commentaire.

Si le programme qui lit le fichier de configuration accepte et ignore les champs inconnus, alors on peut en effet se servir de ces champs come des zones de commentaire. C'est effectivement une solution de contournement possible, même si je trouve ça un peu moche.

[popo]

Si on explique la bidouille uniquement dans le message du commit et pas dans un commentaire du fichier de configuration, alors on augmente les chances que l'explication ne sera pas lue par les prochaines personnes qui mettront à jour le fichier de configuration.

Toutes mes excuses, j'étais parti du principe que la fameuse bidouille était temporaire.
Si on ne corrige jamais le bug et qu'on laisse la bidouille, il y a effectivement des chances que l'information se perde.

Si le programme qui lit le fichier de configuration accepte et ignore les champs inconnus, alors on peut en effet se servir de ces champs come des zones de commentaire. C'est effectivement une solution de contournement possible, même si je trouve ça un peu moche.

C'est effectivement moche, tout comme le fait de mettre une bidouille.
C'est le même principe, c'est sensé être temporaire.

[Pyramidev]

La discussion sera plus simple avec des exemples concrets. Je ne me rappelle plus sur quels cas j'étais tombé au boulot, mais je viens de trouver un exemple dans le monde de l'open source.

broot est une CLI codée en Rust que j'utilise régulièrement. Dans son code source, je viens de regarder la configuration des dépendances et je suis tombé sur la ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

syntect = { package = "syntect-no-panic", version = "4.6.1" } # see issue #485

https://github.com/Canop/broot/blob/...Cargo.toml#L59

Au lieu d'utiliser le package syntect, le code utilise le package syntect-no-panic qui est un fork de syntect.
Le commentaire permet de savoir que c'est pour contourner un bogue décrit ici : https://github.com/Canop/broot/issues/485
L'auteur de broot espérait que le problème soit réglé à partir de la version 5 de syntect, mais cela n'a pas été le cas et la bidouille est restée.

Oui, une bidouille, c'est moche. Mais, quand on a des dépendances, on ne contrôle pas tout.

À part ça, toujours dans le même fichier de configuration, il y a un autre exemple de commentaire qui permet d'illustrer un autre cas que les contournements de problèmes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

codegen-units = 1 # this removes a few hundred bytes from the final exec size

https://github.com/Canop/broot/blob/...Cargo.toml#L91

codegen-units = 1 peut rendre le code plus rapide et rendre plus petit l'exécutable généré. En contrepartie, cela peut augmenter le temps de compilation.
Dans cet exemple, le commentaire met en évidence que la motivation était de réduire la taille de l'exécutable généré.

[AlexRutny]

Le XML aurait pu (du) être un excellent outil s'il n'avait pas été pollué par une tonne de fonctionnalités inutiles sinon dangereuses. C'est malheureusement souvent le problème des standards qui incorporent plein de trucs pour faire plaisir à tout le monde (comme le CORBA par exemple qui était une véritable usine à gaz). Ce qui est étonnant dans ce cas, est que le XML avait été conçu à l'origine comme une simplification du SGML. Quoiqu'il en soit le XML reste un bien meilleur choix pour l'échange de données complexes que le YAML.

[popo]

Pyramide, les deux lignes que tu montres ne sont pas du JSON.

AlexRutny, tu peux préciser de quelles fonctionnalités inutiles et dangereuses tu parles ?