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é.
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é.
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