Terlalu Banyak YAML

• YAML dipakai seperti standar dalam pengaturan DevOps dan CI, tetapi karena konversi tipe implisit dan perbedaan parser, konfigurasi yang sama pun bisa ditafsirkan berbeda dari yang diharapkan
• Dalam YAML 1.1, nilai seperti NO, 07, 08, 04:30, 0666 dapat berubah menjadi boolean, angka, waktu, atau oktal, sehingga niat untuk menjadikannya string harus dinyatakan dengan jelas
• Contoh dari GitHub Actions, Kubernetes, CloudFormation, dan berbagai layanan CI menunjukkan bahwa sintaks YAML dan struktur khusus tiap layanan dapat berujung pada commit berulang, nested escaping, dan representasi job yang tidak seragam
• Tautan referensi mengumpulkan contoh YAML yang dapat dieksekusi, perbedaan perilaku antar-parser, notasi string multi-baris, masalah versi 1.70 yang diparse sebagai 1.7, serta alasan desain StrictYAML
• Alternatif seperti Nickel, Dhall, CUE, dan Jsonnet juga ditampilkan, tetapi halaman itu sendiri tampak seperti kolom teks besar yang bisa diedit, melanjutkan satire tentang kegunaan YAML

---

Satire YAML sebagai bahasa konfigurasi DevOps

• YAML sering dipakai dalam konfigurasi DevOps, tetapi halaman ini menampilkan kelelahan terhadap YAML lewat kalimat bernada “tak seorang pun benar-benar ingin memakai YAML”
• Alasannya memakai YAML sebagai teknologi DevOps dijabarkan secara ironis
  • Disindir seolah-olah semuanya selalu bisa dikompilasi dan dideploy
  • Menyindir bahwa selama pengembangan tidak ada penanganan error paksa, dan masalah baru meledak saat runtime di produksi
  • Dikatakan seakan pesan “ada sesuatu yang rusak” lebih baik daripada stack trace dengan nomor baris
  • Memuat keluhan bahwa membuat pipeline CI baru berarti harus membakar banyak waktu
  • Menyindir situasi ketika sesuatu dianggap pilihan aman hanya karena Kubernetes memakainya
  • Juga disebutkan kelebihan bahwa YAML mendukung komentar, tidak seperti JSON

Jebakan akibat konversi tipe implisit

• Dalam YAML 1.1, NO dapat diparse sebagai tipe boolean
  • NO: Norway dapat menimbulkan masalah interpretasi boolean alih-alih dibaca sebagai kode negara
  • Jika yang dimaksud adalah string, harus dibungkus tanda kutip seperti "NO"
  • Disebutkan bahwa dalam spesifikasi YAML 1.1 ada 22 cara untuk menulis true atau false
• Nilai yang tampak seperti angka juga bisa diterima berbeda oleh parser
  • Contoh 07 dan 08 menunjukkan hasil bisa berbeda seperti [ 7, "08" ]
  • Ini disatirkan sebagai klaster Kubernetes yang berhasil deploy sampai node ketujuh lalu gagal di node kedelapan
• String yang tampak seperti waktu juga bisa menjadi target konversi otomatis
  • 04:30 dapat berubah bukan menjadi string waktu yang ditulis pengguna, tetapi menjadi 16200, yaitu jumlah detik sejak tengah malam
  • Jika yang dimaksud adalah string, harus dinyatakan eksplisit seperti !!str 04:30
• Perbedaan notasi oktal YAML juga menambah kebingungan
  • YAML 1.1 memakai notasi 0666
  • YAML 1.2 memakai notasi 0o666
  • Fakta bahwa Kubernetes memakai YAML 1.1 diperlakukan seperti “ritus peralihan DevOps”

Masalah penanganan versi, SHA, dan string

• Versi paket bisa diparse seperti bilangan floating-point
  • foo: 1.7 dan bar: 1.70 bisa ditafsirkan sebagai versi yang sama
  • fizz: 1.7.0 dan buzz: 1.70.0 bisa diperlakukan sebagai string versi yang berbeda
• Git SHA pendek yang dipakai di CI juga belum tentu aman
  • SHA 8 karakter bisa saja seluruhnya angka
  • my.flaky_version yang berisi ${GIT_SHORT_SHA} tanpa tanda kutip mungkin tidak dianggap string
  • Disebutkan bahwa nilai ini sekitar 98% akan menjadi string, dan akan 100% menjadi string jika dibungkus seperti "${GIT_SHORT_SHA}"
• Kasus Rust toolchain juga dimasukkan sebagai referensi
  • Toolchain version 1.70 is parsed as 1.7

Biaya yang terlihat dalam konfigurasi CI dan infrastruktur

• Ada contoh seseorang yang saat mempelajari GitHub Actions melakukan commit/push 8 kali dalam satu jam, dan pesan commit terakhirnya adalah “I don't really like yml”
  • Tautan: https://twitter.com/eric_sink/status/1430954572848287744
• Ada juga contoh bagaimana jadinya jika SQL ditulis dengan YAML
  • Struktur SQL seperti SELECT, FROM, WHERE EXISTS, AND, EQUALS, LT diubah menjadi struktur nested YAML
  • Ini menyindir bagaimana ekspresi SQL yang singkat berubah menjadi bentuk YAML yang panjang dan bertele-tele
• Cara tiap layanan CI mengekspresikan job dan step juga berbeda-beda
  • Azure DevOps memakai bentuk jobs di bawah job, steps, script
  • CircleCI memakai bentuk jobs, job1, steps, checkout, run
  • Contoh “sistem CI masa depan” menunjukkan pekerjaan yang sama bisa dinyatakan lagi dalam struktur nested lain
• Untuk kasus CloudFormation yang menaruh fungsi SEARCH di dalam DashboardBody milik CloudWatch, ada contoh yang mengharuskan isi yang sudah di-escape untuk di-escape lagi, lalu seluruh JSON ditutup dengan tanda kutip ganda

YAML yang dapat dieksekusi dan perbedaan parser

• Ungkapan “executable yaml” dikaitkan dengan masalah parsing YAML terkait keamanan
  • Ruby YAML Security
  • PHP yaml_parse notes
  • Swagger YAML parser vulnerability
  • PyYAML yaml.load(input) Deprecation-Deprecation)
• Masalah kompatibilitas parser YAML juga dibahas dalam materi terpisah
  • Every YAML parser is a custom YAML parser
  • Materi itu ditempatkan untuk menunjukkan bahwa perilaku tiap parser bisa tidak sama

Materi terkait dan alternatif

• Referensi yang membahas masalah YAML dikumpulkan bersama
  • 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
• Berbagai alat dan pendekatan dicantumkan sebagai alternatif untuk DevOps yang berpusat pada YAML
  • Nickel
  • Dhall
  • CUE
  • Jsonnet
  • contoh kubenix
  • tree.d

Reaksi terhadap halaman itu sendiri

• Kumpulan reaksi Reddit juga menjadikan desain halaman sebagai sasaran kritik
  • Ada reaksi bahwa situs web itu seperti kolom teks besar yang bisa diedit
  • Ada reaksi bahwa hyperlink tidak bisa diklik
  • Ada lelucon bahwa masalah terselesaikan dengan memilih seluruh teks halaman lalu menghapusnya
  • Ada reaksi yang setuju dengan sentimen anti-YAML tetapi mempertanyakan keputusan desain situs webnya
• Kalimat penutup menyatakan bahwa halaman itu sengaja dibuat “seusable YAML”

[GN⁺]

Komentar Hacker News

• Masalah favorit saya adalah ini:
  07
08
  Hasilnya menjadi [ 7, "08" ]
  Karena asumsi tentang oktal dan string.
  Asumsi ini ditemukan di dalam YAML yang dihasilkan dari templat tiga tingkat di bawah, dan menyebabkan seluruh klaster k8s kami mengalami gangguan, tetapi hanya klaster 08 yang rusak. Tujuh yang sebelumnya berjalan baik-baik saja

  • Saya pembuat situs web ini. Saya akan senang kalau ini dikirim sebagai pull request
  • Sial, sepertinya sebagian besar developer sekarang tidak tahu oktal atau literal angka oktal dengan prefiks 0
    Saya memang tertawa membaca komentar ini, tetapi mengingat hampir tidak ada orang yang memakai oktal di file konfigurasi pada 2023, perilaku dan asumsi seperti ini tidak masuk akal. Kalau heksadesimal mungkin masih bisa dimaklumi, desimal tentu saja, tapi oktal itu agak keterlaluan
  • Saya tidak mengerti bagaimana ini bisa dianggap perilaku yang benar
  • Ketika mengatakan “menemukan” asumsi itu, apakah maksudnya mereka tidak membaca spesifikasi, melainkan mulai memakainya dengan asumsi bahwa mereka tahu perilakunya?
    Pihak yang membuat itu jelas tidak menserialisasi data dengan library. Kalau memakai library, library itu akan mengonversi tipe ke format yang benar

• YAML punya banyak masalah, tetapi menurut saya masalah intinya adalah upaya memasukkan logika ke dalam konfigurasi
  Jika YAML hanya dipakai untuk data dan bukan untuk logika, ia termasuk salah satu format data yang mudah dibaca dan ditulis manusia
  CI/CD selalu punya kadar logika tertentu, jarang sekali selesai hanya dengan YAML murni, dan sering tercampur templat aneh. Rasanya lebih baik kalau mereka menyediakan API sungguhan untuk bahasa pemrograman sungguhan

  • Itu bukan masalah YAML, lebih tepatnya penyalahgunaan YAML. Turing-completeness yang tidak disengaja memang masalah di mana-mana
    Saat memakai Ant berbasis XML 15 tahun lalu pun masalah yang sama ada, dan itu bukan salah XML
    Menurut saya masalah utama YAML adalah kurangnya keamanan tipe. Hal-hal seperti indentasi yang salah, typo pada key, dan string yang diparse sebagai boolean
    Selain itu, saya menganggapnya format yang bagus karena ringkas dan jauh lebih sedikit noise sintaks dibanding format lain. Karena itu saya membuat https://github.com/crdoconnor/strictyaml agar orang bisa memakai YAML yang aman secara tipe dan mendapatkan pesan error yang langsung serta jelas untuk masalah-masalah seperti ini
  • Dari pengalaman saya, semakin banyak hal yang bisa dilakukan sebuah bahasa, semakin kompleks cara orang memakainya
    Karena mereka merasa membutuhkannya lalu menarik abstraksi ke dalamnya. Karena itu saya selalu menghindari memakai bahasa pemrograman Turing-complete sebagai format konfigurasi
    Saya pernah menghabiskan berjam-jam menelusuri AWS CDK baris demi baris dengan debugger JavaScript. Kalau itu file yaml/Json/apa pun yang sederhana dan bodoh, masalah seperti itu tidak akan ada. Proyeknya kecil dan tidak membutuhkan kompleksitas
    Karena itu, untuk konfigurasi tooling JS pun saya lebih suka JSON daripada JS. Ini juga alasan konfigurasi webpack jadi berantakan. Begitu orang bisa memakai bahasa sungguhan, “sensor DRY” mereka aktif dan membuatnya lebih kompleks
    Kalau deklaratif, mengikuti praktik standar lebih mudah dan dukungan tooling juga lebih baik. Kalau package.json benar-benar menjadi seperti build.gradle, itu akan jauh lebih buruk
  • Konfigurasi yang dapat dieksekusi bisa memberi manfaat besar. Python adalah pilihan yang jelas
    Cukup tetapkan bahwa “skrip dijalankan di interpreter Python dalam cgroup yang sangat dibatasi, dan hasilnya harus berupa dictionary bernama CONFIG.” Logika wrapper lalu menserialisasikannya dengan cara yang nyaman bagi program yang dikonfigurasi
  • Saya tidak mengerti mengapa desain skema yang buruk dianggap salah YAML dan bukan salah perancang skemanya
    Ini mirip dengan mengeluhkan kompleksitas atau kekakuan helm. Chart Helm tidak menulis dirinya sendiri. Sepertinya lebih mudah mengeluh dan mengabaikan daripada memahami masalah dan mengimplementasikannya
  • Saya 100% setuju. Ketika orang bilang mereka membenci YAML, dalam banyak kasus maksud sebenarnya lebih dekat ke “saya tidak suka mendeskripsikan pipeline dengan YAML.” Saya juga paham perasaan itu
    Sebagai format file, YAML punya kelebihan dan kekurangan. Namun masalah sebenarnya adalah mencoba merepresentasikan hal-hal seperti kondisional, loop, fungsi, serta kelas/subkelas melalui templat dalam format file yang setara JSON
    YAML oke untuk konfigurasi kecil. Tetapi begitu Anda membutuhkan control flow apa pun, ia sangat cepat membesar menjadi spaghetti khusus vendor

• Jinja di dalam YAML jelas merupakan antipola menurut saya
  Sepertinya ini muncul karena sejak awal tidak dirancang dengan kemampuan pemrograman yang memadai, lalu belakangan orang-orang meniru proyek-proyek yang berhasil mengambil jalan itu
  Tulisan tersebut menyebut alternatif seperti Dhall dan Jsonnet, tetapi ada dua hal lain yang bisa dipertimbangkan
  Pertama, membuat pustaka konfigurasi untuk bahasa pemrograman sungguhan, lalu pustaka ini menghasilkan file konfigurasi JSON. JSON itu tidak diperlakukan sebagai sesuatu yang diedit manual, melainkan hanya sebagai artefak yang bisa diperiksa. Pengguna memasukkan konfigurasi berbentuk kode yang didukung tooling ke version control. Lebih sulit melakukan perbaikan darurat langsung di server adalah kekurangan sekaligus kelebihan
  Kedua, Starlark. Ini adalah bahasa turunan Python yang tidak Turing-complete, awalnya dikembangkan untuk sistem build Bazel. Ada beberapa implementasi dan saya tidak tahu seberapa dalam kompatibilitasnya, tetapi ada juga binding Python: https://github.com/caketop/python-starlark-go, https://github.com/inducer/starlark-pyo3

  • Saya setuju bahwa Jinja di dalam YAML adalah antipola, tetapi terutama karena karakter blok/ekspresi default {% dan {{ sama-sama merupakan karakter YAML, sehingga semua titik pemakaian harus diapit tanda kutip
    Menurut saya cara seperti ${{ di GitHub Actions, atau <%, <<, jauh lebih baik. Memang ada risiko <<: merupakan sintaks YAML, tetapi itu bukan Jinja yang valid
    Jika maksudnya tidak boleh memasukkan apa pun yang bisa dieksekusi ke dalam YAML, menurut saya kapal itu sudah telanjur berlayar. Orang-orang sudah tahu bahwa membiarkan bagian literal sebagai default dan sesekali menyisipkan bagian eksekusi, seperti ASP/JSP/PHP, cocok untuk membuat konten
    Kalau ingin memulai flamewar saudara di thread ini, cukup bahas HCL dan for_each, tetapi sebaiknya setidaknya jangan dilakukan di sini
  • Inilah jalur yang dipilih Amazon dengan CDK. Sampai batas tertentu ini bekerja, tetapi untuk melakukan hal yang tidak sepele, rasanya sangat seperti membuat mesin Rube Goldberg
    Saya tidak tahu seberapa banyak itu salah CDK dan seberapa banyak karena CloudFormation memang dari awal kurang bagus
  • Setuju. Pekerjaan dengan YAML bertemplat begitu merepotkan sampai akhirnya saya membuat alat bernama Cels karena itu: https://github.com/pacha/cels
    Saya suka Jsonnet dan Starlark, tetapi dalam praktiknya sebagian besar use case tidak membutuhkan bahasa pemrograman baru. Biasanya kita hanya ingin membuat dokumen dasar lalu mengubahnya dengan menerapkan patch. Dengan begitu semuanya jauh lebih sederhana
    Pengalaman memakai YAML murni sendiri tidak terlalu buruk. Formatnya memang punya beberapa bagian yang cukup meragukan, tetapi masih bisa dipakai. Menurut saya masalahnya muncul dari kompleksitas berbagai solusi yang harus ditambahkan agar dokumen sesuai untuk banyak environment
  • Memikirkan harus berurusan lagi dengan Ansible gara-gara ini saja sudah seperti mimpi buruk
    Saya dengar dulu ada DSL Python sungguhan yang bisa dipakai sebagai pengganti YAML, tetapi tampaknya sudah dihentikan. Jadi sekarang loop dan if-then menjadi gumpalan YAML panjang yang mengerikan, dan Jinja ditafsirkan dengan cara yang sama sekali tidak bisa diprediksi
  • Saya penasaran apakah ada alat standalone yang bisa menjalankan kode Starlark untuk menghasilkan JSON atau YAML, seperti jsonnet

• Menurut saya YAML itu sendiri bagus. Yang tidak bagus adalah kita membuat bagian deployment dari CD menjadi terlalu sulit
  Saya mengakui konfigurasi kami di Azure DevOps tidak terlalu bagus, tetapi tetap mengejutkan bahwa ada organisasi di mana beberapa tim atau 5–6 operator harus menangani alat seperti ini. Mungkin tidak untuk tempat seperti Google, tetapi untuk enterprise biasa dengan maksimal 50 ribu pengguna bersamaan, atau biasanya jauh lebih sedikit dari itu, rasanya berlebihan
  Pada awal 2000-an, men-deploy aplikasi web enterprise ke IIS on-premise—dengan load balancing, networking, dan segala macam hal lain ditangani oleh kurang dari 0,25 pegawai tetap—lebih mudah daripada men-deploy hal yang sama ke konfigurasi “modern” sekarang
  Tentu saja pipeline modern punya kelebihan. Kita sudah banyak melewati masalah “di komputer saya jalan”, dan kontrol kualitas meningkat besar berkat approval gate yang lebih baik. Tetapi deployment yang sebenarnya, bahkan pada 2023, masih mimpi buruk
  Ini mungkin bukan masalah bagi para programmer HN di perusahaan teknologi sungguhan atau perusahaan yang punya tim DevOps khusus yang bagus. Tetapi di dunia enterprise non-teknologi, CI/CD belum pernah seburuk ini sepanjang karier saya
  Kita bisa menyalahkan YAML, atau menyalahkan fakta bahwa untuk melakukan sesuatu dibutuhkan terlalu banyak YAML dan template-nya sulit. Namun menurut saya masalah organisasi jauh lebih besar daripada masalah teknis. Tool CD harus jauh lebih otomatis supaya developer tidak perlu menjadikan infrastruktur sebagai code
  Bagus bahwa hal itu memungkinkan, tetapi kenyataannya kita meminta jutaan developer untuk men-deploy infrastruktur yang mungkin hampir tidak mereka pahami. Saya belum pernah bertemu developer yang tidak ingin cukup menyerahkan container lalu berharap networking dan “urusan sisi server” ditangani otomatis
  Kalau tidak begitu, akan muncul banyak VNET dan subnet yang tidak ada seorang pun benar-benar memahami cara kerjanya, dan organisasi kehilangan banyak uang karena developer tidak tahu bahwa itu bisa dilakukan dengan /x

  • Cloud adalah mainframe baru
    Kita menulis semacam “job definition” secara offline, mengirimkannya ke sistem bersama proprietary, menunggu di antrean, lalu menerima file log yang dibuat oleh sistem yang tidak kita kendalikan. Karena kode sistem proprietary tidak bisa dijalankan secara lokal di workstation, siklus iterasi internal paling cepat puluhan menit, dan bisa berjam-jam atau berhari-hari
    Tidak ada mode preview atau “what if”, juga tidak ada “dry run”. Meskipun disebut “test”, karena hanya ada satu sistem, pada dasarnya kita bekerja di production
    Masalah sebenarnya bukan YAML. Bahkan kalau pipeline ditulis dengan bahasa pemrograman ciptaan Tuhan pun mungkin tidak akan banyak berbeda
    Alasan pengembangan software di workstation menjadi jauh lebih populer dibandingkan mainframe time-sharing terpusat adalah karena ia membuat iterasi internal jauh lebih cepat, mengisolasi dari lingkungan production, dan mengembalikan kendali ke tangan developer
    Generasi pipeline CI/CD saat ini pada umumnya membalikkan semua itu
    Kubernetes single-machine menghidupkan kembali sebagian besar keunggulan pengembangan berbasis workstation, tetapi sistem ini masih sangat baru sehingga banyak mengalami growing pain
    Masalah terkaitnya, ada solusi hebat untuk developer yang sendirian mengoperasikan satu aplikasi dengan klik-klik, dan ada solusi hebat untuk perusahaan raksasa yang melakukan otomasi skala besar untuk ribuan developer. Namun area di tengahnya—beberapa developer enterprise yang mengelola puluhan aplikasi—benar-benar kacau
  • Saya tidak yakin kita sudah sepenuhnya melewati “di komputer saya jalan”
    Di image Docker saya, semuanya beberapa kali berjalan baik, tetapi di image yang sudah di-deploy cukup sering rusak
    Ini adalah masalah yang hanya bisa diatasi jika seluruh pipeline build dan deployment sepenuhnya transparan, ada akses penuh ke image repository, dan kita benar-benar bisa mengendalikan instruksi build. Ini sama terbatasnya dengan mengendalikan sistem operasi lokal, dan saya rasa akan gagal sebanyak jumlah organisasi yang kodenya rusak ketika dipindahkan ke mesin lain
  • Saya tidak tahu apa masalahnya dalam deployment. Hal-hal yang saya konfigurasi cukup diberi tag pada commit lalu di-push, dan commit itu ter-deploy
    Di sistem CI/CD mana pun, mengaturnya seperti itu tampak cukup intuitif

• Saya rasa ada solusi untuk menjaga perdamaian jika semua orang secara universal menghormati satu aturan saja: jangan gunakan YAML di luar ekosistem Python
  Dengan begitu, orang-orang yang menyukai format scripting yang sulit dipahami, yang mengutamakan keterbacaan di atas akurasi, ketahanan, dan kemudahan pemeliharaan, tetap bisa memakai karakter tab, tipe yang longgar, dan sintaks yang ruwet. Kita yang lain tidak perlu melakukannya. Orang-orang yang lebih suka sintaks gaya C bisa tetap waras
  Rasanya baru sekarang inti masalahnya tersentuh. Bagi saya sebagai developer sintaks C, whitespace sintaktis adalah kegilaan murni. Whitespace itu format, bukan informasi atau perintah. Format yang baik memang membantu dan berguna, dan developer sintaks C yang baik juga peduli pada format yang mudah dibaca
  Di Python dan YAML, format adalah informasi instruksional. Keuntungannya, semua kode yang berfungsi menjadi mudah dibaca. Tapi mengapa kode harus mudah dibaca agar bisa berfungsi?
  Bayangkan saja bekerja dengan rekan seperti YAML. Anda mengirim pesan panjang, lalu dia menjawab, “Apa maksudnya? Ini tidak masuk akal.” Ternyata maknanya rusak karena Anda tidak memasukkan baris kosong di antara paragraf. Setelah baris kosong ditambahkan kembali dan pesan dikirim lagi, barulah ia bisa membacanya. Tanpa format yang benar secara sintaktis, informasi yang Anda kirim tadi menjadi tidak bermakna

  • Tujuan lain kode sebagai perangkat lunak, selain bisa dieksekusi, adalah bisa dibaca
    Ada begitu banyak cara untuk memformat, dan saya lebih suka orang memakai linter saat menulis kode. Kalau bisa, linter yang sama dengan yang saya gunakan
    Bahasa-bahasa seperti itu memaksakan struktur sintaks standar. Itu hal yang baik karena mengurangi cara untuk menulis kode yang sulit dibaca
  • Biasanya whitespace bermakna dianggap sebagai persoalan filosofis atau religius. Ada yang suka, ada yang tidak, dan kedua pihak merasionalisasi preferensinya, tetapi pada akhirnya dianggap sebagai soal selera yang kuat
    Namun sekarang saya mulai berpikir perbedaannya bukan soal filosofi, melainkan soal tool. Beberapa tool, misalnya editor teks atau program email, mendukung whitespace bermakna dengan baik, sementara yang lain tidak
    Semua editor teks yang saya pakai diatur untuk menampilkan spasi dan karakter tab, dan menampilkan keduanya secara berbeda. Biasanya seperti titik samar dan garis pendek samar. Saya sudah terbiasa sehingga sama sekali tidak mengganggu
    Dari sudut pandang saya, kode bukan teks sembarang. Kita memakai font monospace yang tidak akan dipakai di buku, dan membedakan sintaks dengan warna. Tidak ada alasan juga untuk tidak membuat whitespace terlihat
    Saya memang masih lebih suka bahasa yang tidak memiliki whitespace bermakna, tetapi saya tidak membenci bahasa seperti itu. Bagi saya itu sama sekali bukan masalah
    Namun jika tool favorit Anda tidak mendukung whitespace bermakna dengan baik, tidak membuat whitespace terlihat, atau bahkan Anda coding dengan font proportional, wajar saja Anda sangat membenci whitespace bermakna dan melihatnya sebagai kegilaan murni
  • Karena berlatar C, saya juga dulu berpikir hal yang sama: whitespace bukan informasi atau perintah. Pada masa awal Python, saya bahkan agak meremehkannya karena itu
    Yang mengejutkan, titik balik saya terjadi saat memakai CoffeeScript. Saya tidak terlalu menyukai JavaScript, tetapi pengalaman memakai CoffeeScript terasa seperti versi tersaring dari The Good Parts karya Crockford. Bagian-bagian buruknya tidak bisa tercipta secara tidak sengaja
    Selain itu, cara indentasi menjadi kode terasa cukup nyaman. Satu-satunya ketidaknyamanan adalah di Vi saya tidak bisa menekan % pada kurung kurawal pembuka atau penutup untuk menemukan ujung lain blok. Sebaliknya, berkat indentasi, jika kode terlihat aneh, sering kali memang benar-benar aneh
    Meski begitu, saya masih belum banyak belajar Python. Sekarang saya memakai TypeScript, tetapi kalau suatu hari ada CoffeeTypeScript…
  • Agak aneh bahwa TOML ada di pustaka standar, sementara YAML tidak. Dan TOML itu jelek
  • Komunitas Kubernetes sedang menatap dengan sorot mata penuh minat

• Jadi saya mulai membuat sendiri sebuah format bernama BCL: https://github.com/wkhere/bcl
  Ini tidak akan langsung membantu semua kasus penggunaan YAML, tetapi setidaknya bisa menjadi cara yang lebih bagus untuk mendefinisikan resource dengan gaya seperti Terraform. Bahkan, di satu proyek internal, ini sudah membantu sebagai pengganti HCL, dan itulah dorongan terakhir yang membuat saya membuatnya
  Secara lebih luas, saya tidak tahu bagaimana membantu masalah YAML yang ada di mana-mana di Kubernetes. Lebih dari separuh masalah $daily_job saya adalah proses menggabungkan chart Helm akhir dari berbagai sumber yang terlalu kasar
  Bukan berarti Helm pada dasarnya adalah tool yang buruk, atau perusahaan kami memilih Helm dengan cara yang cukup buruk. Saya rasa semua orang melakukan yang terbaik dengan mempertimbangkan situasi
  Namun memanipulasi template teks dengan whitespace bermakna terlalu mudah menimbulkan error, dan error-nya juga terlalu terlambat ditemukan. Menurut saya Kubernetes akan jauh lebih baik jika, alih-alih mencoba membuktikan betapa kerennya YAML, ia memakai format khusus berbasis sintaks gaya C. Terutama karena YAML juga tidak keren

  • YAML punya dua fitur bagus. String multi-baris dan fakta bahwa YAML adalah superset dari JSON
    Apa pun yang menghasilkan JSON bisa dipakai untuk menghasilkan YAML
    Nickel dapat dievaluasi menjadi JSON: https://nickel-lang.org/
  • Presentasi Nixcon ini berkesan bagi saya
    https://youtu.be/SEA1Qm8K4gY?feature=shared
  • Penasaran apakah Anda sudah melihat ucl: https://github.com/vstakhov/libucl
    Kelihatannya cukup mirip

• Ini adalah efek platform internal. Seiring aplikasi membesar, konfigurasi juga ikut berkembang hingga akhirnya menjadi bahasa pemrograman, tetapi menjadi bahasa yang banyak bug, spesifikasinya kurang, dan usability-nya mengerikan
  Deklarasikan kebangkrutan konfigurasi dan pilih format konfigurasi baru. Lalu siklusnya berulang
  Tentu format itu sendiri juga tidak sepenuhnya bebas tanggung jawab. Semakin fleksibel, semakin mudah ia didaur ulang menjadi bahasa pemrograman yang buruk
  Setelah melakukan kesalahan ini berulang kali, sekarang saya akan memilih format konfigurasi yang sesederhana mungkin untuk konfigurasi dasar. Bahkan .ini pun bisa terlalu kuat. “Konfigurasi” yang lebih kompleks akan saya serahkan ke bahasa pemrograman sungguhan, sebaiknya bahasa yang dipakai untuk menulis aplikasinya

• Mayoritas besar contoh “YAML itu buruk” bisa diselesaikan dengan membungkus semua literal aneh dalam tanda kutip
  Memang benar YAML kadang menyebalkan. Misalnya, daftar di dalam map cepat menjadi aneh, dan whitespace yang bermakna hampir pasti suatu saat akan menjegal. Namun tulisan-tulisan seperti ini, paling baik pun, terasa agak kurang serius

  • Namun di antara contoh-contoh seperti itu tidak ada yang memakai tanda kutip, dan alat-alatnya juga tidak melakukannya
    Seluruh ekosistem YAML mendorong penulisan nilai tanpa tanda kutip. Biasanya berfungsi baik, lalu sesekali rusak—cukup untuk membuat tersandung di produksi

• EDN adalah subset dari Clojure: https://github.com/edn-format/edn
  Jelas, bisa di-streaming, dapat diperluas, dan tidak sensitif terhadap whitespace. Namun ada konvensi pemformatan untuk keterbacaan

  • Ini pertama kalinya saya melihat format data yang secara eksplisit membedakan list dan set, dan itu bagus
    Namun saya tidak begitu paham apa perbedaan makna antara list dan vector. Di kepala saya, array dan linked list adalah detail implementasi struktur data di dalam kode, bukan perbedaan format data
  • Jauh lebih baik daripada alternatifnya. Saya benar-benar berharap ini mulai dipakai juga di luar ekosistem Clojure
  • Tepatnya, agak sulit menyebutnya tidak bergantung pada whitespace, karena whitespace diperlukan untuk batas atau pemisahan elemen
    Meski begitu, sama sekali tidak ada permainan indentasi semantik. Fakta bahwa koma dianggap sebagai whitespace dan tidak diperlukan itu indah

• Ketika mahasiswa mengumpulkan tugas lewat platform e-learning, kami menerima semua pengumpulan sebagai file XML yang cukup besar
  Kami membaca pengumpulan tersebut, meneruskannya ke analisis statis dan eksekusi contoh, lalu untuk tiap tugas menulis file YAML yang berisi semua pengumpulan, petunjuk penilaian, komentar dan kolom input nilai, dan sebagainya
  Setelah itu, dari file YAML kami membuat laporan, statistik, dan PDF umpan balik melalui markdown+rendering (Pandoc)
  Bagi kami, YAML sangat cocok. Karena mudah menambahkan umpan balik tambahan dengan sintaks Markdown. Misalnya, sesuatu seperti - you missed a \NOT` here` yang diindentasi dengan benar
  Berkat berbagai cara escaping untuk teks blok, meskipun mahasiswa memakai beragam delimiter SQL, kami bisa menampilkan pengumpulan SQL dengan rapi tanpa karakter escape
  Semuanya berupa teks biasa, jadi kami hanya memakai editor teks, lalu menyimpannya di git untuk memastikan akuntabilitas penilaian. Karena semuanya disimpan agar dapat dibaca mesin, kami juga bisa menguji alat analisis statis baru pada pengumpulan lama
  Namun karena pipeline CI dan konfigurasi otomasi rumah juga harus ditulis dengan YAML, saya memahami rasa sakitnya

  • Penghapusan indentasi pada teks yang disematkan mungkin adalah fitur terbaik yang dimiliki YAML
    Di TOML, kita harus menyerah pada indentasi string multi-baris sehingga keterbacaan menurun, atau menaruh backslash di akhir setiap baris. Keduanya tidak ideal
    Karena itu, YAML cukup bagus untuk DSL atau konfigurasi yang perlu memuat Markdown atau format teks lain, dan punya keunggulan dibandingkan yang seperti TOML
    Namun saya tidak akan menimpakan seluruh “kelelahan YAML” hanya kepada alat CI dan DevOps yang memilih YAML sebagai format pembawa DSL. Seperti yang dirangkum dengan baik oleh tulisan aslinya, YAML sendiri juga punya masalah besar
    “Masalah Norway” yang terkenal sudah diselesaikan di YAML 1.2, dan masalah parsing angka dengan awalan 0 sebagai oktal juga sudah diselesaikan di YAML 1.2. Pemaksaan tipe yang berlebihan untuk angka, tanggal, waktu, dan sebagainya bisa membingungkan. Mode penanganan string multi-baris juga bisa cukup membingungkan. Serialisasi yang tidak aman bukan masalah pada parser modern, tetapi saat memakai YAML di bahasa lama yang memiliki fitur dinamis seperti Ruby, Python, dan Java, kita harus berhati-hati
    Semua ini adalah masalah pada spesifikasi YAML itu sendiri