Es gibt zu viel YAML

 (noyaml.com)
2 Punkte von GN⁺ 2023-09-29 | 1 Kommentare | Auf WhatsApp teilen
  • YAML wird in DevOps- und CI-Konfigurationen zwar quasi als Standard verwendet, kann aber wegen impliziter Typumwandlung und Unterschieden zwischen Parsern selbst bei derselben Konfiguration anders interpretiert werden als erwartet
  • In YAML 1.1 können Werte wie NO, 07, 08, 04:30, 0666 zu Booleschen Werten, Zahlen, Zeitangaben oder Oktalzahlen umgewandelt werden, daher muss die beabsichtigte Zeichenkette klar kenntlich gemacht werden
  • Beispiele aus GitHub Actions, Kubernetes, CloudFormation und diversen CI-Diensten zeigen, dass YAML-Syntax und dienstspezifische Strukturen zu wiederholten Commits, verschachteltem Escaping und uneinheitlichen Job-Darstellungen führen können
  • Die Referenzlinks bündeln ausführbares YAML, Unterschiede im Parser-Verhalten, Notationen für mehrzeilige Strings, das Problem, dass Version 1.70 als 1.7 geparst wird, sowie die Designbegründung von StrictYAML
  • Alternativen wie Nickel, Dhall, CUE und Jsonnet werden ebenfalls genannt, aber die Seite selbst wirkt wie ein riesiges editierbares Textfeld und führt damit die Satire auf die Benutzbarkeit von YAML fort

Satire auf YAML als DevOps-Konfigurationssprache

  • YAML wird häufig für DevOps-Konfigurationen verwendet, doch diese Seite zeigt mit Formulierungen wie „Niemand will YAML benutzen“ eine deutliche YAML-Müdigkeit
  • Die Gründe, YAML als DevOps-Technologie zu verwenden, werden ironisch aufgezählt
    • Es wird satirisch so dargestellt, als sei damit immer alles kompilierbar und deploybar
    • Es wird gespottet darüber, dass es während der Entwicklung keine erzwungene Fehlerbehandlung gibt und Probleme erst zur Laufzeit in Produktion explodieren
    • Statt Stacktraces mit Zeilennummern sei eine Meldung wie „Irgendetwas ist kaputt“ angeblich besser
    • Es steckt Frust darüber drin, dass man beim Erstellen neuer CI-Pipelines Zeit verbrennen muss
    • Dass Kubernetes es benutzt, wird satirisch als Beleg für eine sichere Wahl behandelt
    • Auch der Vorteil gegenüber JSON, nämlich Unterstützung für Kommentare, wird erwähnt

Fallstricke durch implizite Typumwandlung

  • In YAML 1.1 kann NO als Boolescher Typ geparst werden
    • NO: Norway kann dann statt eines Ländercodes ein Problem durch Boolesche Interpretation auslösen
    • Wenn eine Zeichenkette gemeint ist, muss sie etwa mit "NO" in Anführungszeichen gesetzt werden
    • Es wird darauf hingewiesen, dass die YAML-1.1-Spezifikation 22 Schreibweisen für true oder false zulässt
  • Auch Werte, die wie Zahlen aussehen, können von Parsern unterschiedlich interpretiert werden
    • Das Beispiel 07 und 08 zeigt, dass das Ergebnis etwa zu [ 7, "08" ] werden kann
    • Das wird satirisch als Kubernetes-Cluster beschrieben, das bis zum siebten Deployment funktioniert und beim achten scheitert
  • Auch Zeichenketten, die wie Uhrzeiten aussehen, werden automatisch umgewandelt
    • 04:30 kann statt der eingegebenen Uhrzeit zum Sekundenwert 16200 seit Mitternacht werden
    • Wenn eine Zeichenkette gemeint ist, muss sie z. B. als !!str 04:30 explizit markiert werden
  • Auch Unterschiede bei der Oktalschreibweise in YAML sorgen für Verwirrung
    • YAML 1.1 verwendet die Schreibweise 0666
    • YAML 1.2 verwendet die Schreibweise 0o666
    • Dass Kubernetes YAML 1.1 verwendet, wird als eine Art „DevOps-Initiationsritus“ behandelt

Probleme bei Versionen, SHA-Werten und Strings

  • Paketversionen können wie Gleitkommazahlen geparst werden
    • foo: 1.7 und bar: 1.70 können als dieselbe Version interpretiert werden
    • fizz: 1.7.0 und buzz: 1.70.0 können dagegen als unterschiedliche Versionsstrings behandelt werden
  • Auch kurze Git-SHAs aus CI sind nicht unbedingt sicher
    • Ein 8-stelliger SHA kann komplett aus Ziffern bestehen
    • ${GIT_SHORT_SHA} ohne Anführungszeichen in my.flaky_version ist dann möglicherweise kein String
    • Es wird angegeben, dass dieser Wert zu etwa 98 % ein String ist und mit "${GIT_SHORT_SHA}" zu 100 % ein String wird
  • Das Beispiel zur Rust-Toolchain ist ebenfalls als Referenzlink enthalten

Sichtbare Kosten in CI- und Infrastrukturkonfigurationen

  • Enthalten ist ein Beispiel, in dem jemand beim Lernen von GitHub Actions in einer Stunde achtmal commitet und pusht und die letzte Commit-Nachricht „I don't really like yml“ lautet
  • Es gibt auch ein Beispiel dafür, wie SQL aussähe, wenn man es in YAML schreiben würde
    • SQL-Strukturen wie SELECT, FROM, WHERE EXISTS, AND, EQUALS, LT werden in verschachtelte YAML-Strukturen umgewandelt
    • Damit wird satirisch gezeigt, wie eine kurze SQL-Schreibweise zu einer langen und umständlichen YAML-Form wird
  • Auch die Darstellung von Jobs und Steps unterscheidet sich je nach CI-Dienst stark
    • Azure DevOps verwendet die Form jobs → job → steps → script
    • CircleCI verwendet die Form jobs → job1 → steps → checkout → run
    • Ein Beispiel für ein „CI-System der Zukunft“ zeigt, dass dieselbe Aufgabe wieder in einer anderen verschachtelten Struktur dargestellt werden könnte
  • Für CloudFormation mit einer SEARCH-Funktion innerhalb von CloudWatch-DashboardBody ist ein Beispiel enthalten, in dem bereits escapte Inhalte erneut escaped und das gesamte JSON zusätzlich in doppelte Anführungszeichen gesetzt werden muss

Ausführbares YAML und Unterschiede zwischen Parsern

Verwandte Materialien und Alternativen

Reaktionen auf die Seite selbst

  • Eine Sammlung von Reddit-Reaktionen nimmt sogar das Seitendesign ins Visier
    • Es gibt die Reaktion, die Website sei ein riesiges editierbares Textfeld
    • Es gibt die Reaktion, dass Hyperlinks nicht anklickbar seien
    • Es gibt den Witz, dass das Problem gelöst worden sei, indem man den gesamten Seitentext markiert und gelöscht habe
    • Es gibt die Reaktion, dass man der YAML-kritischen Stoßrichtung zwar zustimme, die Designentscheidung der Website aber fragwürdig finde
  • Der letzte Satz erklärt, die Seite sei absichtlich „so benutzbar wie YAML“ gemacht worden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-29
Meinungen auf Hacker News

  • Mein Lieblingsärgernis ist dieses hier:
    07
    08
    Das Ergebnis wird zu [ 7, "08" ]
    Wegen der Annahmen zu Oktalzahlen und Strings.
    Diese Annahme wurde drei Ebenen tiefer in per Template erzeugtem YAML entdeckt und führte bei uns zu einem Ausfall des gesamten k8s-Clusters, wobei nur der 08-Cluster kaputtging. Die ersten sieben liefen problemlos

    • Ich bin der Betreiber dieser Website. Es wäre schön, wenn du das als Pull Request schicken könntest
    • Verdammt, ich glaube, die meisten Entwickler heutzutage kennen Oktalzahlen oder Oktal-Zahlenliterale mit Präfix 0 gar nicht mehr
      Ich musste über diesen Kommentar zwar lachen, aber wenn man bedenkt, dass 2023 praktisch niemand Oktalzahlen in Konfigurationsdateien verwendet, sind dieses Verhalten und diese Annahme unsinnig. Hexadezimal könnte ich noch verstehen, Dezimal sowieso, aber Oktal ist schon heftig
    • Ich verstehe nicht, wie das korrektes Verhalten sein kann
    • Dass ihr diese Annahme „entdeckt“ habt, heißt das, dass ihr nicht die Spezifikation gelesen habt, sondern einfach angenommen habt, ihr kennt das Verhalten, und losgelegt habt?
      Die Seite, die das erzeugt hat, hat die Daten sicher nicht mit einer Bibliothek serialisiert. Hätte sie eine Bibliothek verwendet, hätte diese die Typen in das korrekte Format umgewandelt

  • YAML hat viele Probleme, aber ich denke, das eigentliche Kernproblem ist der Versuch, Logik in Konfiguration zu stecken
    Wenn man YAML nur für Daten und nicht für Logik verwendet, ist es eines der gut von Menschen les- und schreibbaren Datenformate
    In CI/CD steckt immer ein gewisses Maß an Logik, und mit reinem YAML ist es fast nie getan; dazu kommen noch merkwürdige Templates. Ich frage mich, warum man nicht lieber eine echte API für eine echte Programmiersprache bereitstellt

    • Das ist eher kein YAML-Problem, sondern Missbrauch von YAML. Zufällige Turing-Vollständigkeit ist überall ein Problem
      Vor 15 Jahren gab es mit dem XML-basierten Ant dasselbe Problem, und das war nicht die Schuld von XML
      Das Hauptproblem von YAML sehe ich in der fehlenden Typsicherheit. Falsche Einrückung, Tippfehler in Keys, Strings, die als Booleans geparst werden, und Ähnliches
      Abgesehen davon halte ich es für ein gutes Format, weil es knapp ist und deutlich weniger syntaktisches Rauschen hat als andere Formate. Deshalb habe ich https://github.com/crdoconnor/strictyaml gebaut, damit Leute typsicheres YAML verwenden und zu solchen Problemen sofort klare Fehlermeldungen bekommen
    • Meiner Erfahrung nach gilt: Je mehr eine Sprache kann, desto komplexer setzen Menschen sie ein
      Weil sie Abstraktionen hineinziehen, die sie für nötig halten. Deshalb vermeide ich es immer, eine turing-vollständige Programmiersprache als Konfigurationsformat zu verwenden
      Ich habe einmal Stunden damit verbracht, AWS CDK Zeile für Zeile im JavaScript-Debugger nachzuverfolgen. Mit einer einfachen, dummen yaml-/JSON-/Was-auch-immer-Datei hätte es dieses Problem nicht gegeben. Es war ein kleines Projekt und brauchte diese Komplexität nicht
      Deshalb bevorzuge ich auch bei Konfigurationen für JS-Tools JSON gegenüber JS. Das ist auch der Grund, warum webpack-Konfigurationen aus dem Ruder laufen. Sobald man eine echte Sprache verwenden kann, schlägt bei Leuten der „DRY-Sensor“ an und sie machen alles komplexer
      Wenn es deklarativ ist, lassen sich Standardpraktiken leichter einhalten und die Tool-Unterstützung wird besser. Wenn package.json tatsächlich wie build.gradle würde, wäre das deutlich schlimmer
    • Ausführbare Konfiguration kann große Vorteile bringen. Python ist die naheliegende Wahl
      Man könnte festlegen: „Führe ein Skript in einem Python-Interpreter innerhalb einer stark eingeschränkten cgroup aus, und als Ergebnis muss ein Dictionary namens CONFIG entstehen.“ Die Wrapper-Logik serialisiert das dann auf eine für das zu konfigurierende Programm passende Weise
    • Ich verstehe nicht, warum schlechtes Schema-Design YAMLs Schuld sein soll und nicht die der Schema-Designer
      Das ist ähnlich wie Beschwerden über die Komplexität oder Starrheit von helm. Helm-Charts schreiben sich nicht von selbst. Es scheint einfacher zu sein, sich zu beschweren und Dinge zu ignorieren, statt das Problem zu verstehen und umzusetzen
    • Stimme zu 100 % zu. Wenn Leute sagen, sie hassen YAML, meinen sie meiner Ansicht nach oft eher: „Ich hasse es, Pipelines in YAML zu beschreiben.“ Dieses Gefühl kann ich nachvollziehen
      Als Dateiformat hat YAML Vor- und Nachteile. Das eigentliche Problem ist aber der Versuch, Dinge wie Bedingungen, Schleifen, Funktionen sowie Klassen/Unterklassen über Templates in einem JSON-ähnlichen Dateiformat auszudrücken
      YAML ist für kleine Konfigurationen in Ordnung. Aber sobald irgendeine Art von Kontrollfluss nötig wird, wächst es sehr schnell zu vendor-spezifischen Spaghetti heran

  • Jinja in YAML halte ich eindeutig für ein Antipattern.
    Vermutlich wurde am Anfang nicht genug Programmierbarkeit eingeplant, und später ist es entstanden, weil Leute Projekten folgten, die diesen Weg gewählt hatten und damit erfolgreich waren.
    Im Artikel werden Alternativen wie Dhall und Jsonnet genannt, aber zwei weitere Möglichkeiten kann man ebenfalls in Betracht ziehen.
    Erstens: eine Konfigurationsbibliothek für eine echte Programmiersprache bauen, die dann JSON-Konfigurationsdateien erzeugt. Dieses JSON wird nicht von Hand editiert, sondern nur als prüfbares Artefakt behandelt. Nutzer legen die Konfiguration als Code mit Tool-Unterstützung in der Versionsverwaltung ab. Dass es dadurch schwieriger wird, direkt auf dem Server schnelle Notfalländerungen vorzunehmen, ist Nachteil und Vorteil zugleich.
    Zweitens: Starlark. Das ist eine von Python abgeleitete, nicht Turing-vollständige Sprache, die ursprünglich für das Bazel-Buildsystem entwickelt wurde. Es gibt mehrere Implementierungen, und ich weiß nicht, wie weit die Kompatibilität reicht, aber es gibt auch Python-Bindings: https://github.com/caketop/python-starlark-go, https://github.com/inducer/starlark-pyo3

    • Ich stimme zu, dass Jinja in YAML ein Antipattern ist, vor allem weil die Standardzeichen für Blöcke/Ausdrücke, {% und {{, beide YAML-Zeichen sind und man deshalb jede Verwendungsstelle in Anführungszeichen setzen muss.
      Ansätze wie ${{ bei GitHub Actions oder <%, << finde ich deutlich besser. Natürlich besteht bei <<: die Gefahr, dass es YAML-Syntax ist, aber gültiges Jinja ist es nicht.
      Falls gemeint ist, dass man überhaupt nichts Ausführbares in YAML packen sollte: Ich denke, der Zug ist längst abgefahren. Die Leute haben gemerkt, dass die Methode, Literalteile als Standard zu nehmen und nur gelegentlich ausführbare Teile einzufügen, wie bei ASP/JSP/PHP gut zum Erzeugen von Content funktioniert.
      Wenn man in diesem Thread einen Neben-Flamewar starten wollte, müsste man HCL und for_each erwähnen, aber zumindest hier sollte man das wohl besser lassen.
    • Das ist der Weg, den Amazon mit CDK eingeschlagen hat. Bis zu einem gewissen Grad funktioniert es, aber sobald man etwas Nichttriviales tun will, fühlt es sich stark danach an, eine Rube-Goldberg-Maschine zu bauen.
      Ich weiß nicht, wie viel davon an CDK liegt und wie viel daran, dass CloudFormation von Haus aus nicht besonders gut ist.
    • Stimme zu. Die Arbeit mit templatisiertem YAML war so mühsam, dass ich deswegen schließlich ein Tool namens Cels gebaut habe: https://github.com/pacha/cels
      Ich mag Jsonnet und Starlark, aber in der Praxis braucht man für die meisten Use Cases keine neue Programmiersprache. Meist will man nur ein Basisdokument erstellen und es durch Anwenden von Patches ändern. Dann wird alles viel einfacher.
      Die Erfahrung mit reinem YAML an sich ist gar nicht so schlecht. Das Format hat zwar ein paar ziemlich fragwürdige Stellen, ist aber brauchbar. Das Problem entsteht meiner Meinung nach durch die Komplexität der Workarounds, die man hinzufügen muss, um Dokumente an mehrere Umgebungen anzupassen.
    • Allein der Gedanke, deswegen wieder Ansible anfassen zu müssen, ist ein Albtraum.
      Ich habe gehört, früher habe es statt YAML eine echte Python-DSL gegeben, aber die scheint eingestellt worden zu sein. Deshalb werden Schleifen und if-then jetzt zu furchtbaren, ausufernden YAML-Klumpen, und Jinja wird völlig unvorhersehbar interpretiert.
    • Ich frage mich, ob es ein Standalone-Tool gibt, das wie jsonnet Starlark-Code ausführen kann, um JSON oder YAML zu erzeugen.

  • YAML an sich halte ich für großartig. Nicht großartig ist, dass wir den Deployment-Teil von CD viel zu schwierig gemacht haben.
    Ich gebe zu, dass unsere Konfiguration in Azure DevOps nicht gerade fantastisch ist, aber es ist erstaunlich, dass es Organisationen gibt, in denen mehrere Teams oder fünf bis sechs Betreiber mit solchen Tools umgehen müssen. Bei Google oder ähnlichen Unternehmen mag das anders sein, aber für ein normales Enterprise mit höchstens 50.000 gleichzeitigen Nutzern, meist deutlich weniger, wirkt das übertrieben.
    Anfang der 2000er war es einfacher, eine Enterprise-Web-App auf einem On-Premises-IIS zu deployen, bei dem weniger als 0,25 Vollzeitstellen alles Mögliche wie Load Balancing und Networking betreuten, als dieselbe App heute in ein „modernes“ Setup zu deployen.
    Natürlich haben moderne Pipelines Vorteile. Sie haben viele „Auf meinem Rechner funktioniert es“-Probleme überwunden und mit besseren Approval-Gates die Qualitätskontrolle deutlich verbessert. Aber das eigentliche Deployment ist auch 2023 noch ein Albtraum.
    Für HN-Programmierer in echten Tech-Unternehmen oder Firmen mit guten dedizierten DevOps-Teams ist das vielleicht kein Problem. Aber in der nichttechnischen Enterprise-Welt war CI/CD in meiner Laufbahn noch nie so schlecht.
    Man kann YAML die Schuld geben oder der Tatsache, dass man für alles Mögliche zu viel YAML braucht und Templates schwierig sind. Aber meiner Meinung nach ist das Organisationsproblem viel größer als das technische Problem. CD-Tools müssten viel stärker automatisiert sein, damit Entwickler nicht Infrastruktur als Code beschreiben müssen.
    Es ist gut, dass das möglich ist, aber die Realität ist, dass man Millionen Entwickler auffordert, Infrastruktur zu deployen, die sie womöglich kaum verstehen. Ich habe noch keinen Entwickler gesehen, der nicht einfach einen Container abgeben und hoffen wollte, dass Networking und der „Server-Kram“ von selbst erledigt werden.
    Wenn man das nicht tut, entstehen jede Menge VNETs und Subnetze, deren Funktionsweise niemand richtig versteht, und Unternehmen verlieren viel Geld, weil Entwickler nicht wissen, dass es mit /x gegangen wäre.

    • Die Cloud ist der neue Mainframe.
      Man schreibt offline irgendeine Art von „Job-Definition“, reicht sie bei einem proprietären, gemeinsam genutzten System ein, wartet in einer Queue und bekommt anschließend Logdateien von einem System, das man nicht kontrolliert. Weil man den proprietären Systemcode nicht lokal auf der Workstation ausführen kann, dauert der innere Iterationszyklus selbst im besten Fall Dutzende Minuten, im schlechteren Fall Stunden oder Tage.
      Es gibt keine Preview, keinen „what if“-Modus und keinen „dry run“. Selbst wenn man es „Test“ nennt, arbeitet man faktisch in Produktion, weil es nur ein System gibt.
      Das eigentliche Problem ist nicht YAML. Es wäre egal, wenn die Pipeline in Gottes Programmiersprache geskriptet wäre.
      Softwareentwicklung auf Workstations statt auf zentralen Time-Sharing-Mainframes wurde vor allem deshalb so populär, weil sie die inneren Iterationen drastisch beschleunigte, von der Produktionsumgebung isolierte und den Entwicklern wieder Kontrolle gab.
      Die aktuelle Generation von CI/CD-Pipelines macht all das weitgehend rückgängig.
      Single-Machine-Kubernetes bringt die meisten Vorteile der Workstation-basierten Entwicklung zurück, ist aber noch ein sehr neues System mit vielen Wachstumsschmerzen.
      Ein verwandtes Problem: Für Entwickler, die allein per Klick eine einzelne App betreiben, gibt es großartige Lösungen, und für riesige Unternehmen, die groß angelegte Automatisierung für Tausende Entwickler betreiben, ebenfalls. Aber der Bereich dazwischen, in dem einige Enterprise-Entwickler Dutzende Apps verwalten, ist schlicht Chaos.
    • Ich bin mir nicht sicher, ob wir „Auf meinem Rechner funktioniert es“ wirklich vollständig überwunden haben.
      In meinem Docker-Image lief es mehrfach problemlos, aber im deployten Image ist es schon einige Male kaputtgegangen.
      Das sind Probleme, durch die man nur hindurchkommt, wenn die gesamte Build- und Deployment-Pipeline vollständig transparent ist, man vollen Zugriff auf das Image-Repository hat und die Build-Anweisungen tatsächlich kontrollieren kann. Das ist genauso restriktiv wie die Kontrolle über das lokale Betriebssystem, und ich denke, es wird in genauso vielen Organisationen scheitern, wie Code früher beim Wechsel auf eine andere Maschine kaputtging.
    • Ich weiß nicht, was am Deployment das Problem sein soll. Bei den Dingen, die ich eingerichtet habe, hat man einfach einen Commit getaggt und gepusht, und genau dieser Commit wurde deployt.
      Das in einem beliebigen CI/CD-System so einzurichten, wirkt ziemlich intuitiv.

  • Ich glaube, es gäbe eine Lösung, um den Frieden zu wahren, wenn alle nur eine einzige Regel allgemein respektieren würden: Außerhalb des Python-Ökosystems kein YAML verwenden
    Dann können die Leute, die ein obskures Scripting-Format mögen, das Lesbarkeit über Korrektheit, Robustheit und Wartbarkeit stellt, weiter Tab-Zeichen, lockeres Typing und schwer durchschaubare Syntax verwenden. Der Rest von uns müsste das nicht mehr. Wer C-artige Syntax bevorzugt, könnte bei Verstand bleiben
    Ich glaube, damit ist endlich der Kern des Problems getroffen. Für mich als Entwickler mit C-Syntax ist syntaktischer Whitespace reiner Wahnsinn. Whitespace ist Formatierung, keine Information und kein Befehl. Gute Formatierung ist hilfreich und nützlich, und auch gute Entwickler in C-Syntax achten auf lesbare Formatierung
    In Python und YAML ist Formatierung Anweisungsinformation. Der Vorteil ist, dass jeder funktionierende Code dadurch gut lesbar wird. Aber warum muss Code zwingend gut lesbar sein, damit er funktioniert?
    Man muss sich nur vorstellen, mit einem Kollegen wie YAML zu arbeiten. Man schickt eine lange Nachricht, und er antwortet: „Was? Das ergibt keinen Sinn.“ Dann stellt sich heraus, dass die Bedeutung kaputtging, weil zwischen den Absätzen keine Leerzeilen standen. Fügt man die Leerzeilen wieder ein und schickt die Nachricht erneut, kann er sie plötzlich lesen. Ohne syntaktisch korrekte Formatierung waren die gesendeten Informationen bedeutungslos

    • Ein weiterer Zweck von Code als Software ist neben der Ausführbarkeit auch, lesbar zu sein
      Es gibt zahllose Arten zu formatieren, und ich bevorzuge es, wenn Leute beim Schreiben von Code einen Linter verwenden. Wenn möglich denselben Linter wie ich
      Solche Sprachen erzwingen standardisierte syntaktische Strukturen. Das reduziert die Möglichkeiten, schwer lesbaren Code zu schreiben, und das ist gut
    • Normalerweise betrachtet man signifikanten Whitespace als philosophische oder religiöse Frage. Manche mögen ihn, manche hassen ihn, und beide Seiten rationalisieren ihre Vorlieben, aber am Ende gilt es als starke Geschmacksfrage
      Inzwischen denke ich aber, dass der Unterschied keine Philosophie-, sondern eine Werkzeugfrage ist. Manche Tools, etwa Texteditoren oder E-Mail-Programme, unterstützen signifikanten Whitespace gut, andere nicht
      Alle Texteditoren, die ich benutze, sind so eingestellt, dass sie Leerzeichen und Tab-Zeichen anzeigen, und zwar unterschiedlich. Meist als blasse Punkte und blasse Striche oder ähnlich. Ich bin daran gewöhnt, und es stört mich überhaupt nicht
      Aus meiner Sicht ist Code kein beliebiger Text. Man verwendet eine Monospace-Schrift, die man für Bücher nicht nehmen würde, und hebt Syntax farblich hervor. Es gibt keinen Grund, Whitespace nicht sichtbar zu machen
      Ich bevorzuge zwar weiterhin Sprachen ohne signifikanten Whitespace, aber ich hasse solche Sprachen nicht. Für mich ist das überhaupt kein Problem
      Wenn die bevorzugten Tools signifikanten Whitespace aber nicht gut unterstützen, Whitespace nicht sichtbar machen oder man sogar in einer Proportionalschrift programmiert, dann bleibt einem kaum etwas anderes übrig, als signifikanten Whitespace leidenschaftlich zu hassen und ihn für reinen Wahnsinn zu halten
    • Mit C-Hintergrund dachte ich ebenfalls, dass Whitespace weder Information noch Befehl ist. In den frühen Tagen von Python habe ich deshalb sogar ein wenig darauf herabgesehen
      Geändert hat sich meine Meinung überraschenderweise durch CoffeeScript. Ich mag JavaScript nicht besonders, aber CoffeeScript fühlte sich an wie eine destillierte Version von Crockfords The Good Parts. Man konnte die schlechten Teile nicht versehentlich erzeugen
      Außerdem war es ziemlich angenehm, dass Einrückung zu Code wurde. Der einzige Nachteil war, dass man in Vi nicht auf einer öffnenden oder schließenden geschweiften Klammer % drücken konnte, um das andere Ende des Blocks zu finden. Umgekehrt sorgte die Einrückung dafür, dass Code, der seltsam aussah, oft tatsächlich seltsam war
      Python habe ich trotzdem noch nicht besonders gründlich gelernt. Heute nutze ich TypeScript, aber falls irgendwann CoffeeTypeScript erscheint …
    • Dass TOML in der Standardbibliothek ist, YAML aber nicht, ist schon etwas seltsam. Und TOML ist hässlich
    • Die Kubernetes-Community schaut mit interessiertem Blick zu

  • Deshalb habe ich angefangen, selbst ein Format namens BCL zu bauen: https://github.com/wkhere/bcl
    Es wird nicht sofort bei allen YAML-Anwendungsfällen helfen, könnte aber zumindest eine schönere Art sein, Ressourcen im Stil von Terraform zu definieren. Tatsächlich hilft es in einem internen Projekt bereits als HCL-Ersatz, und das war der letzte Anstoß, es zu bauen
    Im größeren Bild weiß ich nicht, wie es beim Problem helfen soll, dass YAML in Kubernetes überall ist. Mehr als die Hälfte meines $daily_job-Problems besteht darin, dass das Zusammenführen des endgültigen Helm-Charts aus mehreren Quellen viel zu grob ist
    Das heißt nicht, dass Helm an sich ein schlechtes Tool ist oder dass mein Unternehmen Helm auf ziemlich schlechte Weise gewählt hat. Ich denke, alle tun unter den gegebenen Umständen ihr Bestes
    Aber Text-Templates mit signifikantem Whitespace zu manipulieren ist viel zu fehleranfällig, und Fehler werden viel zu spät entdeckt. Kubernetes wäre meiner Meinung nach deutlich besser gefahren, wenn es ein eigenes Format auf Basis C-artiger Syntax verwendet hätte, statt beweisen zu wollen, wie toll YAML ist. Zumal YAML nicht einmal toll ist

  • Das ist der Inner-Platform-Effekt. Je größer eine Anwendung wird, desto mehr wächst auch die Konfiguration, bis sie schließlich zu einer Programmiersprache wird – nur zu einer mit vielen Bugs, schwacher Spezifikation und schrecklicher Usability
    Man erklärt den Konfigurationsbankrott und wählt ein neues Konfigurationsformat. Und dann wiederholt sich alles
    Natürlich ist das Format selbst nicht völlig unschuldig. Je flexibler es ist, desto leichter wird es als schlechte Programmiersprache zweckentfremdet
    Nachdem ich diesen Fehler wiederholt gemacht habe, würde ich heute für Basiskonfigurationen das möglichst einfachste Konfigurationsformat wählen. Selbst .ini kann schon zu mächtig sein. Komplexere „Konfiguration“ würde ich einer echten Programmiersprache überlassen, möglichst der Sprache, in der die Anwendung geschrieben ist

  • Die überwältigende Mehrheit der Beispiele für „YAML ist schlecht“ lässt sich lösen, indem man seltsame Literale einfach in Anführungszeichen setzt
    Es stimmt schon, dass YAML manchmal nervt. Zum Beispiel werden Listen von Maps schnell merkwürdig, und bedeutungstragende Leerzeichen werden einem fast zwangsläufig irgendwann zum Verhängnis. Aber solche Artikel wirken selbst wohlwollend betrachtet etwas nachlässig

    • Nur verwendet in diesen Beispielen niemand Anführungszeichen, und die Tools tun es auch nicht
      Das gesamte YAML-Ökosystem verleitet dazu, Werte ohne Anführungszeichen zu schreiben. Meist funktioniert das gut, bis es gelegentlich genau oft genug kaputtgeht, um in Production darüber zu stolpern

  • EDN ist eine Teilmenge von Clojure: https://github.com/edn-format/edn
    Es ist eindeutig, streambar, erweiterbar und nicht empfindlich gegenüber Whitespace. Es gibt allerdings Formatierungskonventionen für die Lesbarkeit

    • Es ist das erste Datenformat, das ich gesehen habe, das Listen und Sets explizit unterscheidet, und das ist gut
      Aber ich bin mir nicht sicher, worin der semantische Unterschied zwischen Listen und Vektoren liegt. In meinem Kopf sind Arrays und verkettete Listen Implementierungsdetails von Datenstrukturen im Code, keine Unterschiede im Datenformat
    • Viel besser als die Alternativen. Ich hoffe wirklich, dass es auch außerhalb des Clojure-Ökosystems verwendet wird
    • Genau genommen ist es schwer zu sagen, dass es unabhängig von Whitespace ist, weil Whitespace für Elementgrenzen oder zur Trennung nötig ist
      Trotzdem gibt es keinerlei semantische Einrückungsspielchen. Dass Kommas als Whitespace gelten und nicht nötig sind, ist schön

  • Wenn Studierende Aufgaben über die E-Learning-Plattform einreichen, bekommen wir alle Einreichungen als ziemlich große XML-Datei
    Wir lesen die Einreichungen, geben sie an statische Analyse und Beispielausführungen weiter und schreiben dann für jede Aufgabe eine YAML-Datei, die alle Einreichungen, Bewertungshinweise, Kommentare sowie Eingabefelder für Punkte enthält
    Danach erzeugen wir aus der YAML-Datei über Markdown+Rendering (Pandoc) Berichte, Statistiken und Feedback-PDFs
    Für uns passt YAML sehr gut, weil man zusätzliches Feedback leicht in Markdown-Syntax einfügen kann. Zum Beispiel etwas wie korrekt eingerücktes - you missed a \NOT` here`
    Dank der verschiedenen Escape-Varianten für Blocktext können wir SQL-Einreichungen schön ohne Escape-Zeichen ausgeben, auch wenn die Studierenden unterschiedliche SQL-Delimiter verwenden
    Alles ist Plain Text, daher nutzen wir nur Texteditoren und speichern es in git, um Verantwortlichkeit bei der Bewertung sicherzustellen. Weil wir alles maschinenlesbar aufbewahren, können wir neue statische Analyse-Tools auch an alten Einreichungen testen
    Aber da CI-Pipelines und Home-Automation-Konfigurationen ebenfalls in YAML geschrieben werden müssen, verstehe ich den Schmerz

    • Das Entfernen von Einrückung bei eingebettetem Text ist wahrscheinlich eine der besten Funktionen von YAML
      In TOML muss man entweder auf Einrückung bei mehrzeiligen Strings verzichten und damit die Lesbarkeit senken, oder am Ende jeder Zeile einen Backslash setzen. Beides ist nicht ideal
      Deshalb ist YAML für DSLs oder Konfigurationen, die Markdown oder andere Textformate enthalten müssen, ziemlich gut und hat gegenüber Dingen wie TOML einen Vorteil
      Aber ich würde die gesamte „YAML-Müdigkeit“ nicht allein den CI- und DevOps-Tools anlasten, die YAML als Transportformat für ihre DSL gewählt haben. Wie der Originalbeitrag gut zusammenfasst, hat YAML selbst große Probleme
      Das berühmte „Norway-Problem“ wurde in YAML 1.2 gelöst, und auch das Parsen führender Nullen als Oktalzahlen wurde in YAML 1.2 behoben. Übermäßige Typumwandlung bei Zahlen, Datums- und Zeitwerten usw. kann verwirrend sein. Auch die Modi zur Behandlung mehrzeiliger Strings können ziemlich irritierend sein. Unsichere Serialisierung ist in modernen Parsern kein Problem, aber wenn man YAML in älteren Sprachen mit dynamischen Funktionen wie Ruby, Python oder Java verwendet, sollte man vorsichtig sein
      All das sind Probleme der YAML-Spezifikation selbst