Demasiado YAML

• YAML se usa como estándar en DevOps y configuraciones de CI, pero por las conversiones implícitas de tipos y las diferencias entre parsers, una misma configuración puede interpretarse de formas inesperadas
• En YAML 1.1, valores como NO, 07, 08, 04:30 y 0666 pueden convertirse en booleanos, números, horas u octales, así que hay que dejar clara la intención de que sean cadenas
• Casos de GitHub Actions, Kubernetes, CloudFormation y varios servicios de CI muestran que la sintaxis de YAML y las estructuras específicas de cada servicio pueden llevar a commits repetidos, capas de escapes y representaciones de jobs inconsistentes
• Los enlaces de referencia agrupan temas como YAML ejecutable, diferencias de comportamiento entre parsers, notación de cadenas multilínea, el problema de que la versión 1.70 se parsea como 1.7 y los fundamentos de diseño de StrictYAML
• También se presentan alternativas como Nickel, Dhall, CUE y Jsonnet, pero la página misma parece un enorme campo de texto editable, manteniendo la sátira sobre la usabilidad de YAML

---

Sátira de YAML como lenguaje de configuración para DevOps

• YAML se usa con frecuencia en configuraciones de DevOps, pero esta página expresa el cansancio con YAML con frases del estilo “nadie quiere usar YAML”
• Enumera de forma irónica las razones para usar YAML como tecnología de DevOps
  • Lo satiriza como si siempre compilara y estuviera listo para desplegarse
  • Se burla de que no haya manejo obligatorio de errores durante el desarrollo y de que los problemas exploten en runtime de producción
  • Dice que un mensaje de “algo se rompió” es mejor que un stack trace con números de línea
  • Refleja la queja de tener que quemar tiempo al crear un nuevo pipeline de CI
  • Satiriza que se lo trate como una opción segura solo porque Kubernetes lo usa
  • También menciona como ventaja que, a diferencia de JSON, soporta comentarios

Trampas creadas por la conversión implícita de tipos

• En YAML 1.1, NO puede parsearse como tipo booleano
  • NO: Norway puede causar un problema de interpretación booleana en lugar de representar un código de país
  • Si la intención era una cadena, hay que envolverla entre comillas, como "NO"
  • Señala que en la especificación YAML 1.1 hay 22 formas de escribir true o false
• Los valores que parecen números también pueden ser aceptados de forma distinta según el parser
  • Los ejemplos 07 y 08 muestran que el resultado puede variar, como [ 7, "08" ]
  • Lo satiriza con una situación en la que un clúster de Kubernetes despliega hasta el séptimo y falla en el octavo
• Las cadenas que parecen horas también quedan sujetas a conversión automática
  • 04:30 puede convertirse en 16200, el valor en segundos desde la medianoche, en lugar de la cadena de hora que escribió el usuario
  • Si se quería una cadena, hay que indicarlo explícitamente, como !!str 04:30
• Las diferencias en la notación octal de YAML también generan confusión
  • YAML 1.1 usa la notación 0666
  • YAML 1.2 usa la notación 0o666
  • El hecho de que Kubernetes use YAML 1.1 se presenta como un “rito de iniciación” de DevOps

Problemas con versiones, SHA y manejo de cadenas

• Las versiones de paquetes pueden parsearse como números de punto flotante
  • foo: 1.7 y bar: 1.70 pueden interpretarse como la misma versión
  • fizz: 1.7.0 y buzz: 1.70.0 pueden tratarse como cadenas de versión distintas
• Los Git SHA cortos usados en CI tampoco necesariamente son seguros
  • Un SHA de 8 caracteres puede estar compuesto solo por números
  • my.flaky_version con ${GIT_SHORT_SHA} sin comillas puede no ser una cadena
  • Se plantea que este valor es una cadena alrededor del 98% de las veces, y que si se envuelve como "${GIT_SHORT_SHA}" es una cadena el 100% de las veces
• También se incluye como referencia el caso de Rust toolchain
  • Toolchain version 1.70 is parsed as 1.7

Costos visibles en configuraciones de CI e infraestructura

• Se incluye el caso de alguien que, mientras aprendía GitHub Actions, hizo commit/push 8 veces en una hora, y cuyo último mensaje de commit fue “I don't really like yml”
  • Enlace: https://twitter.com/eric_sink/status/1430954572848287744
• También hay un ejemplo de cómo se vería SQL si se escribiera en YAML
  • Estructuras SQL como SELECT, FROM, WHERE EXISTS, AND, EQUALS y LT se convierten en una estructura anidada de YAML
  • Satiriza cómo una expresión SQL breve se transforma en una forma YAML larga y verbosa
• Cada servicio de CI también representa jobs y steps de manera diferente
  • Azure DevOps usa una forma con job, steps y script debajo de jobs
  • CircleCI usa una forma con jobs, job1, steps, checkout y run
  • El ejemplo de un “sistema de CI del futuro” muestra que la misma tarea podría expresarse con otra estructura anidada más
• Se incluye un ejemplo en CloudFormation donde, al poner una función SEARCH dentro de DashboardBody de CloudWatch, hay que volver a escapar contenido que ya estaba escapado y cerrar todo el JSON con comillas dobles

YAML ejecutable y diferencias entre parsers

• La expresión “executable yaml” se conecta con problemas de seguridad en el parseo de YAML
  • Ruby YAML Security
  • PHP yaml_parse notes
  • Swagger YAML parser vulnerability
  • PyYAML yaml.load(input) Deprecation-Deprecation)
• Los problemas de compatibilidad entre parsers de YAML también se tratan en material aparte
  • Every YAML parser is a custom YAML parser
  • Se lo presenta como material que muestra que el comportamiento puede no ser igual entre parsers

Material relacionado y alternativas

• Se agrupan materiales de referencia sobre los problemas de YAML
  • Today we’re going to look at some general problems with the YAML format
  • We replaced 1,000 lines of YAML with 10 structs and people started contributing again
  • What if you used the same language and tools you use to define your app to define your infrastructure?
  • A YAML file is almost always still 'valid' even if it is trunca
  • the bug was that the YAML parser ignored the negative signs ... so negative GPS coordinates became positive ones
  • There are 63 different ways to write multi-line strings in YAML
  • StrictYAML Design Justifications
• Se enumeran varias herramientas y enfoques como alternativas al DevOps centrado en YAML
  • Nickel
  • Dhall
  • CUE
  • Jsonnet
  • Ejemplo de kubenix
  • tree.d

Reacciones a la página en sí

• La recopilación de reacciones de Reddit también apunta al diseño de la página como objeto de crítica
  • Hay una reacción que dice que el sitio web es un enorme campo de texto editable
  • Hay una reacción que dice que los hipervínculos no se pueden hacer clic
  • Hay una broma sobre que se resolvió el problema porque se puede seleccionar todo el texto de la página y borrarlo
  • Hay una reacción que coincide con la idea de odiar YAML, pero cuestiona las decisiones de diseño del sitio web
• La frase final aclara que la página fue hecha intencionalmente para ser “tan usable como YAML”

[GN⁺]

Opiniones de Hacker News

• Mi dolor de cabeza favorito es este:
  07
08
  El resultado termina siendo [ 7, "08" ]
  Por las suposiciones sobre los octales y las cadenas
  Esa suposición se encontró dentro de un YAML generado por plantilla tres niveles más abajo, y terminó causando una caída completa de nuestro clúster de k8s, pero solo se rompió el clúster 08. Los 7 anteriores funcionaban bien

  • Soy quien hizo este sitio web. Me encantaría que me mandaran esto como pull request
  • Demonios, creo que la mayoría de los desarrolladores de hoy no conoce los octales ni los literales numéricos octales con prefijo 0
    Me reí con este comentario, pero si pensamos que en 2023 casi nadie usa octales en archivos de configuración, este comportamiento y esas suposiciones no tienen sentido. Hexadecimal, tal vez; decimal, por supuesto; pero octal ya es demasiado
  • No entiendo cómo esto puede ser un comportamiento correcto
  • ¿Que “descubrieron” esa suposición significa que no leyeron la especificación, sino que empezaron a usarlo asumiendo que sabían cómo funcionaba?
    Quien haya generado eso claramente no serializó los datos con una biblioteca. Si hubiera usado una biblioteca, habría convertido los tipos al formato correcto

• YAML tiene muchos problemas, pero creo que el problema central de verdad es intentar meter lógica dentro de la configuración
  Si YAML se usa solo para datos y no para lógica, es uno de los formatos de datos más fáciles de leer y escribir para humanos
  En CI/CD siempre hay cierta lógica, casi nunca alcanza con YAML puro, y encima se mezclan plantillas raras. A veces pienso que mejor deberían ofrecer una API real para un lenguaje de programación real

  • Eso no es tanto un problema de YAML como un mal uso de YAML. La completitud de Turing accidental es un problema en cualquier lado
    Hace 15 años, cuando usaba Ant basado en XML, tenía exactamente el mismo problema, y no era culpa de XML
    Creo que el principal problema de YAML es la falta de seguridad de tipos. Cosas como una indentación incorrecta, errores tipográficos en claves o cadenas que se parsean como booleanos
    Fuera de eso, me parece un buen formato porque es conciso y tiene mucho menos ruido sintáctico que otros formatos. Por eso creé https://github.com/crdoconnor/strictyaml para que la gente use YAML con seguridad de tipos y reciba mensajes de error inmediatos y claros sobre estos problemas
  • En mi experiencia, cuanto más puede hacer un lenguaje, más lo usa la gente de formas complicadas
    Porque incorporan abstracciones pensando que las necesitan. Por eso siempre evito usar un lenguaje de programación Turing completo como formato de configuración
    Una vez pasé horas recorriendo línea por línea AWS CDK con el depurador de JavaScript. Si hubiera sido un archivo yaml/JSON/lo que sea, simple y tonto, ese problema no habría existido. Era un proyecto pequeño y no necesitaba esa complejidad
    Por eso, incluso para la configuración de herramientas de JS, prefiero JSON antes que JS. También es por esto que las configuraciones de webpack terminan siendo un desastre. Cuando se puede usar un lenguaje real, se activa el “sensor DRY” de la gente y lo vuelven más complejo
    Si es declarativo, también es más fácil seguir prácticas estándar y el soporte de herramientas mejora. Si package.json realmente se volviera como build.gradle, sería mucho peor
  • La configuración ejecutable puede aportar grandes ventajas. Python es una opción obvia
    Basta con definir: “ejecutar el script en un intérprete de Python dentro de un cgroup muy restringido, y el resultado debe ser un diccionario llamado CONFIG”. La lógica envolvente puede serializar eso de la forma más conveniente para el programa que se va a configurar
  • No entiendo por qué un mal diseño de esquema sería culpa de YAML y no de quien diseñó el esquema
    Es parecido a quejarse de la complejidad o rigidez de helm. Los charts de Helm no se escriben solos. Supongo que es más fácil quejarse e ignorar el problema que entenderlo e implementarlo
  • Coincido al 100%. Cuando la gente dice que odia YAML, en muchos casos creo que lo que realmente quiere decir es “odio describir pipelines en YAML”. Entiendo esa sensación
    Como formato de archivo, YAML tiene ventajas y desventajas. Pero el verdadero problema está en intentar expresar condicionales, bucles, funciones y algo como clases/subclases mediante plantillas, todo en un formato de archivo equivalente a JSON
    YAML está bien para configuraciones pequeñas. Pero en cuanto necesitas cualquier tipo de flujo de control, crece muy rápido hasta convertirse en espagueti específico de cada proveedor

• Jinja dentro de YAML me parece claramente un antipatrón
  Creo que surgió porque no se diseñó desde el inicio con suficiente capacidad de programación, y después la gente empezó a imitar proyectos que habían tenido éxito al tomar ese camino
  En el artículo se mencionan alternativas como Dhall y Jsonnet, pero se pueden considerar dos más
  Primero, crear una biblioteca de configuración para un lenguaje de programación real y hacer que esa biblioteca genere archivos de configuración JSON. Ese JSON no se trataría como algo para editar a mano, sino solo como un artefacto verificable. El usuario pondría en control de versiones la configuración en forma de código, con soporte de herramientas. Que sea más difícil hacer correcciones urgentes directamente en el servidor es tanto una desventaja como una ventaja
  Segundo, Starlark. Es un lenguaje derivado de Python, no Turing-completo, desarrollado inicialmente para el sistema de build Bazel. Hay varias implementaciones, y no sé qué tan profunda es la compatibilidad, pero también hay bindings para Python: https://github.com/caketop/python-starlark-go, https://github.com/inducer/starlark-pyo3

  • Estoy de acuerdo en que Jinja dentro de YAML es un antipatrón, pero sobre todo porque los caracteres predeterminados de bloques/expresiones, {% y {{, son ambos caracteres de YAML, así que hay que poner entre comillas todos los puntos donde se usan
    Me parece mucho mejor el enfoque de GitHub Actions con ${{, o cosas como <% y <<. Claro, existe el riesgo de que <<: sea sintaxis de YAML, pero no es Jinja válido
    Si lo que se quiere decir es que no debería meterse nada ejecutable dentro de YAML, creo que ese barco ya zarpó. La gente ya descubrió que dejar las partes literales como base y meter solo de vez en cuando partes ejecutables es una buena forma de crear contenido, como en ASP/JSP/PHP
    Si uno quisiera iniciar una flamewar hermana en este hilo, bastaría con hablar de HCL y for_each, pero al menos aquí mejor no hacerlo
  • Este es el camino que tomó Amazon con CDK. Hasta cierto punto funciona, pero cuando quieres hacer algo no trivial, se siente mucho como construir una máquina de Rube Goldberg
    No sé cuánto de eso es culpa de CDK y cuánto de que CloudFormation ya era malo de por sí
  • De acuerdo. Trabajar con YAML parametrizado era tan engorroso que al final hice una herramienta llamada Cels por eso: https://github.com/pacha/cels
    Me gustan Jsonnet y Starlark, pero en la práctica la mayoría de los casos de uso no necesitan un lenguaje de programación nuevo. Normalmente solo quieres crear un documento base y modificarlo aplicando parches. Eso simplifica muchísimo todo
    La experiencia de usar YAML puro no es tan mala. El formato tiene algunas partes bastante cuestionables, pero es utilizable. Creo que el problema aparece en la complejidad de las soluciones adicionales que hay que sumar para adaptar los documentos a varios entornos
  • Solo pensar en volver a tocar Ansible por esto me da pesadillas
    Escuché que antes había un DSL real en Python que se podía usar en lugar de YAML, pero parece que lo discontinuaron. Así que ahora los bucles y los if-then se convierten en bloques horribles y larguísimos de YAML, e interpreta Jinja de forma totalmente impredecible
  • Me pregunto si existe una herramienta independiente que, como jsonnet, pueda ejecutar código Starlark para generar JSON o YAML

• Creo que YAML en sí es excelente. Lo que no es excelente es que hayamos hecho demasiado difícil la parte de despliegue de CD
  Admito que nuestra configuración dentro de Azure DevOps no es precisamente buenísima, pero me sorprende que existan organizaciones donde varios equipos o 5 o 6 operadores tengan que manejar estas herramientas. Quizá en lugares como Google, pero en una empresa común con un máximo de 50 mil usuarios concurrentes, o por lo general mucho menos, se siente excesivo
  A principios de los 2000, era más fácil desplegar una app web empresarial en un IIS on-premise, donde menos de 0.25 personas de tiempo completo se encargaban de todo tipo de cosas como balanceo de carga y redes, que desplegar lo mismo en una configuración “moderna” actual
  Claro que los pipelines modernos tienen ventajas. Hemos superado en gran medida el problema de “en mi computadora sí funciona” y hemos elevado mucho el control de calidad con mejores puertas de aprobación. Pero el despliegue real sigue siendo una pesadilla incluso en 2023
  Esto quizá no sea un problema para los programadores de HN que trabajan en empresas tecnológicas reales o en compañías con buenos equipos DevOps dedicados. Pero en el mundo empresarial no tecnológico, CI/CD nunca había estado tan mal en mi carrera
  Se puede culpar a YAML, o al hecho de que se necesite demasiado YAML para hacer cualquier cosa y de que las plantillas sean difíciles. Pero en mi opinión, es mucho más un problema organizacional que un problema técnico. Las herramientas de CD deberían estar mucho más automatizadas para que no termine siendo tarea de los desarrolladores describir la infraestructura como código
  Está bien que sea posible, pero la realidad es que les estamos pidiendo a millones de desarrolladores que desplieguen infraestructura que quizá apenas entienden. Nunca he visto a un desarrollador que no preferiría simplemente entregar un contenedor y esperar que el networking y las “cosas del lado del servidor” se resolvieran solos
  Si no se hace así, terminas con un montón de VNET y subredes cuyo funcionamiento nadie entiende bien, y la organización pierde mucho dinero porque los desarrolladores no saben que se podía hacer con /x

  • La nube es el nuevo mainframe
    Escribes offline algún tipo de “definición de trabajo”, la envías a un sistema compartido propietario, esperas en una cola y luego recibes archivos de log generados por un sistema que no controlas. Como no puedes ejecutar localmente en tu workstation el código del sistema propietario, el ciclo de iteración interna toma, en el mejor de los casos, decenas de minutos, y en el peor, horas o días
    No hay modo de vista previa ni “what if”, ni “dry run”. Aunque lo llamen “pruebas”, como solo hay un sistema, en la práctica estás trabajando en producción
    El verdadero problema no es YAML. Daria igual que el pipeline estuviera escrito en el lenguaje de programación de los dioses
    La razón por la que se volvió tan popular desarrollar software en workstations en lugar de hacerlo en mainframes centrales de tiempo compartido fue que aceleró drásticamente la iteración interna, la aisló del entorno de producción y devolvió el control a manos de los desarrolladores
    La generación actual de pipelines CI/CD, en general, revierte todo eso
    Kubernetes en una sola máquina recupera la mayoría de las ventajas del desarrollo basado en workstation, pero sigue siendo un sistema muy nuevo y tiene muchos dolores de crecimiento
    Como problema relacionado, hay excelentes soluciones para un desarrollador que opera una app por su cuenta haciendo clics, y también para megacorporaciones que automatizan a gran escala para miles de desarrolladores. Pero el punto intermedio, donde unos pocos desarrolladores empresariales gestionan decenas de apps, es simplemente caos
  • No sé si realmente hemos superado por completo lo de “en mi computadora sí funciona”
    Varias veces algo funcionó bien en mi imagen de Docker, pero se rompió en la imagen desplegada
    Es un problema que solo se puede superar si todo el pipeline de build y despliegue es completamente transparente, si tienes acceso total al repositorio de imágenes y si realmente puedes controlar las instrucciones de build. Esto es tan restrictivo como controlar el sistema operativo local, y creo que fallará en tantas organizaciones como aquellas donde el código se rompía al moverlo a otra máquina
  • No sé cuál es el problema con los despliegues. En las configuraciones que hice, simplemente etiquetabas un commit y hacías push, y ese commit se desplegaba
    Configurarlo así en cualquier sistema de CI/CD parece bastante intuitivo

• Si todos respetaran universalmente una sola regla, creo que habría una solución para mantener la paz: no usemos YAML fuera del ecosistema de Python.
  Así, quienes disfrutan de formatos de scripting crípticos que priorizan la legibilidad por encima de la exactitud, la durabilidad y la mantenibilidad podrían seguir usando tabulaciones, tipos laxos y sintaxis oscura. El resto no tendría por qué hacerlo. Quienes prefieren la sintaxis estilo C podrían conservar la cordura.
  Creo que recién ahora se señaló el núcleo del problema. Para mí, como desarrollador de sintaxis C, el espacio en blanco sintáctico es pura locura. El espacio en blanco es formato, no información ni una instrucción. Un buen formato ayuda y es útil, y un buen desarrollador de sintaxis C también se preocupa por que el formato sea legible.
  En Python y YAML, el formato es información directiva. Tiene la ventaja de que todo código funcional se vuelve fácil de leer. Pero ¿por qué el código tiene que ser necesariamente fácil de leer para funcionar?
  Basta imaginar trabajar con un colega como YAML. Le mandas un mensaje largo y responde: “¿Qué? Esto no tiene sentido”. Resulta que el significado se rompió porque no pusiste una línea en blanco entre párrafos. Vuelves a enviar el mensaje con las líneas en blanco y recién entonces puede leerlo. Sin un formato sintácticamente correcto, la información enviada no tenía sentido.

  • Otro propósito del código como software, además de poder ejecutarse, es ser legible.
    Hay innumerables formas de dar formato, y prefiero que la gente use linters al escribir código. Si es posible, ojalá el mismo linter que uso yo.
    Esos lenguajes imponen una estructura sintáctica estándar. Es algo bueno, porque reduce las formas en que se puede escribir código difícil de leer.
  • Normalmente se considera que el espacio en blanco significativo es una cuestión filosófica o religiosa. A algunos les gusta y a otros no; ambos lados racionalizan sus preferencias, pero al final se lo ve como un tema de gustos fuertes.
    Pero ahora llegué a pensar que la diferencia no es filosófica, sino de herramientas. Algunas herramientas, como editores de texto o clientes de correo, soportan bien el espacio en blanco significativo, y otras no.
    Todos los editores de texto que uso están configurados para mostrar espacios y tabulaciones, y los muestran de forma distinta. Normalmente como puntos tenues y guiones tenues. Ya estoy acostumbrado y no me molesta en absoluto.
    Desde mi punto de vista, el código no es texto arbitrario. Usa una fuente monoespaciada que no usaría en un libro, y distingue la sintaxis con colores. Tampoco hay motivo para no hacer visible el espacio en blanco.
    Sigo prefiriendo los lenguajes que no tienen espacio en blanco significativo, pero no odio esos lenguajes. Para mí no son un problema.
    Pero si tus herramientas favoritas no soportan bien el espacio en blanco significativo, no hacen visible el espacio en blanco, o incluso programas con una fuente de ancho variable, no te queda más que odiar fervientemente el espacio en blanco significativo y verlo como pura locura.
  • Viniendo de C, yo también pensaba lo mismo: que el espacio en blanco no es información ni una instrucción. En los primeros tiempos de Python incluso lo miraba un poco por encima del hombro por eso.
    Lo que me hizo cambiar de opinión fue, curiosamente, usar CoffeeScript. No me gusta mucho JavaScript, y usar CoffeeScript se sentía como una versión destilada de The Good Parts de Crockford. Era imposible crear por accidente las partes malas.
    Además, la forma en que la indentación se convierte en código era bastante cómoda. La única molestia era que en Vi no podía presionar % sobre una llave de apertura o cierre para encontrar el otro extremo del bloque. En cambio, gracias a la indentación, si el código se veía raro, muchas veces realmente estaba raro.
    Aun así, todavía no he aprendido mucho Python. Hoy uso TypeScript, pero si algún día aparece CoffeeTypeScript…
  • Es un poco raro que TOML esté en la biblioteca estándar y YAML no. Y además TOML es feo.
  • La comunidad de Kubernetes mira con una expresión interesante.

• Por eso empecé a crear yo mismo un formato llamado BCL: https://github.com/wkhere/bcl
  No ayudará de inmediato con todos los casos de uso de YAML, pero al menos puede ser una forma más elegante de definir recursos al estilo de Terraform. De hecho, ya nos está sirviendo como reemplazo de HCL en un proyecto interno, y eso fue la motivación final para crearlo.
  En un sentido más amplio, no sé cómo ayudaría con el problema de que YAML esté por todas partes en Kubernetes. Más de la mitad de mi problema con $daily_job está en que combinar charts de Helm finales a partir de varias fuentes es demasiado burdo.
  No quiero decir que Helm sea una mala herramienta por naturaleza, ni que mi empresa haya elegido Helm de una forma bastante mala. Creo que todos hacen lo mejor que pueden dadas las circunstancias.
  Pero manipular plantillas de texto con espacio en blanco significativo es demasiado propenso a errores, y los errores se detectan demasiado tarde. Creo que Kubernetes habría estado mucho mejor si hubiera usado un formato personalizado basado en sintaxis estilo C, en vez de intentar demostrar lo genial que es YAML. Sobre todo porque YAML ni siquiera es genial.

  • YAML tiene dos funciones buenas: las cadenas multilínea y el hecho de que YAML sea un superconjunto de JSON.
    Cualquier cosa que genere JSON puede usarse para generar YAML.
    Nickel puede evaluarse como JSON: https://nickel-lang.org/
  • Esta charla de Nixcon me pareció impresionante.
    https://youtu.be/SEA1Qm8K4gY?feature=shared
  • Me pregunto si viste ucl: https://github.com/vstakhov/libucl
    Parece bastante parecido.

• Esto es el efecto de plataforma interna. A medida que una aplicación crece, la configuración también se expande hasta que al final se convierte en un lenguaje de programación, pero uno con muchos bugs, una especificación deficiente y una usabilidad horrible.
  Declaras la bancarrota de la configuración y eliges un nuevo formato de configuración. Y se repite.
  Por supuesto, el formato en sí tampoco está libre de culpa. Cuanto más flexible es, más fácil es reutilizarlo como un mal lenguaje de programación.
  Después de cometer este error repetidamente, hoy elegiría el formato de configuración más simple posible para la configuración básica. Incluso .ini puede ser demasiado potente. La “configuración” más compleja se la delegaría a un lenguaje de programación real, de ser posible el lenguaje en el que está escrita la aplicación.

• La enorme mayoría de los ejemplos de “YAML apesta” se resuelven si todos los literales raros se ponen entre comillas
  Es cierto que YAML a veces es molesto. Por ejemplo, las listas de mapas se vuelven raras rápidamente, y los espacios en blanco significativos casi con seguridad te van a hacer tropezar algún día. Pero estos textos, viéndolos con buena voluntad, parecen algo poco rigurosos

  • Pero en esos ejemplos nunca usan comillas, y las herramientas tampoco lo hacen por ti
    Todo el ecosistema de YAML te empuja a escribir valores sin comillas. Por lo general funciona bien, hasta que de vez en cuando se rompe lo suficiente como para hacerte tropezar en producción

• EDN es un subconjunto de Clojure: https://github.com/edn-format/edn
  Es claro, permite streaming, es extensible y no es sensible a los espacios en blanco. Aunque sí tiene convenciones de formato para facilitar la lectura

  • Es la primera vez que veo un formato de datos que distingue explícitamente entre listas y conjuntos, y eso está bueno
    Pero no tengo muy claro cuál es la diferencia semántica entre listas y vectores. En mi cabeza, los arrays y las listas enlazadas son detalles de implementación de estructuras de datos en el código, no diferencias de un formato de datos
  • Es mucho mejor que las alternativas. De verdad espero que empiece a usarse también fuera del ecosistema de Clojure
  • Para ser precisos, es difícil decir que no dependa de los espacios en blanco, porque los necesita para delimitar o separar elementos
    Aun así, no tiene nada de juegos de indentación semántica. Es hermoso que las comas se consideren espacios en blanco y no sean necesarias

• Cuando los estudiantes entregan tareas en la plataforma de e-learning, nosotros recibimos todas las entregas como un archivo XML bastante grande
  Leemos las entregas, las pasamos por análisis estático y ejecución de ejemplos, y luego escribimos un archivo YAML por tarea que contiene todas las entregas, pistas de calificación, comentarios, campos para ingresar puntajes, etc.
  Después, a partir del archivo YAML, generamos reportes, estadísticas y PDFs de feedback pasando por markdown+lectura (Pandoc)
  Para nosotros, YAML encaja muy bien. Es fácil agregar feedback adicional con sintaxis Markdown. Por ejemplo, algo como - you missed a \NOT` here` correctamente indentado
  Gracias a las distintas formas de escapar texto en bloque, podemos mostrar de forma prolija las entregas SQL sin caracteres de escape, aunque los estudiantes usen distintos delimitadores SQL
  Como todo es texto plano, usamos solo un editor de texto y lo guardamos en git para asegurar la responsabilidad en la calificación. Al conservar todo en un formato legible por máquina, también podemos probar nuevas herramientas de análisis estático sobre entregas antiguas
  Pero como también hay que escribir pipelines de CI y configuraciones de automatización del hogar en YAML, entiendo ese sufrimiento

  • La eliminación de indentación en texto incrustado probablemente sea una de las mejores funciones que tiene YAML
    En TOML, o renuncias a indentar strings multilínea y bajas la legibilidad, o tienes que poner una barra invertida al final de cada línea. Ninguna opción es ideal
    Por eso YAML es bastante bueno para DSLs o configuraciones que necesitan incluir Markdown u otros formatos de texto, y tiene ventaja sobre cosas como TOML
    Pero no le echaría toda la culpa de la “fatiga de YAML” solo a las herramientas de CI y DevOps que eligieron YAML como formato contenedor para DSLs. Como el texto original lo resumía bien, YAML en sí también tiene problemas grandes
    El famoso “problema de Norway” se resolvió en YAML 1.2, y el problema de parsear números con cero inicial como octales también se resolvió en YAML 1.2. La coerción excesiva de tipos para números, fechas, horas, etc., puede ser confusa. Los modos de manejo de strings multilínea también pueden resultar bastante enredados. La serialización insegura no es un problema en los parsers modernos, pero hay que tener cuidado al usar YAML en lenguajes antiguos con funciones dinámicas como Ruby, Python y Java
    Todo esto es un problema de la propia especificación de YAML