Membela YAML

 (opensource.posit.co)
1 poin oleh GN⁺ 21 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • YAML 1.2 adalah format serialisasi berbasis indentasi untuk file konfigurasi bertingkat yang ditulis langsung oleh manusia, dan perlu dibedakan dari kritik soal ketidakstabilan yang berasal dari pengalaman lama dengan PyYAML
  • Format file konfigurasi telah berkembang untuk memperbaiki keterbatasan generasi sebelumnya, seperti kedangkalan INI, verbositas XML, serta tidak adanya komentar dan string multi-baris pada JSON
  • TOML jelas untuk struktur dangkal seperti pyproject.toml dan Cargo.toml, tetapi pada struktur bertingkat yang dalam, beban membaca dan mengedit meningkat karena pengulangan path dan array of tables
  • YAML 1.2 Core Schema memperlakukan yes, no, on, off, y, n sebagai string, serta menghapus angka basis-60 dan timestamp sebagai tipe inti sehingga mengurangi masalah inferensi tipe implisit di masa lalu
  • py-yaml12 adalah parser dan formatter YAML 1.2 untuk Python yang, melalui implementasi Rust, menawarkan default yang aman, kepatuhan 100% terhadap yaml-test-suite, dan performa yang mampu bersaing dengan ekstensi C milik PyYAML

Permasalahan

  • Dalam beberapa tahun terakhir, suasana seputar format file konfigurasi telah bergeser ke arah anggapan bahwa YAML buruk dan TOML baik, tetapi penilaian terhadap YAML adalah soal yang harus dilihat bersama sejarah, perubahan spesifikasi, dan keadaan alat pada 2026
  • Kritik terhadap YAML memang lama bersifat masuk akal, dan bahkan pengguna yang berhati-hati pun mengalami perilaku tak terduga, tetapi spesifikasinya telah berubah dan ekosistem alat sedang mengejarnya
  • Kritik YAML saat ini hanya bisa dipahami jika melihat silsilah format file konfigurasi secara bersama-sama, sebagai alur berulang ketika format berikutnya memperbaiki ekses format sebelumnya

Sejarah singkat format file konfigurasi

  • File INI muncul pada awal 1980-an bersama MS-DOS dan Windows awal, dan merupakan format datar yang mudah dibaca serta bisa diedit manusia dengan pasangan key-value, section dalam tanda kurung siku, dan komentar titik koma
  • INI cukup untuk kebutuhan saat itu seperti konfigurasi driver perangkat, penunjukan path font, dan pengaturan aplikasi, tetapi memiliki keterbatasan struktural karena tidak bisa bersarang lebih dari satu tingkat dan tidak memiliki spesifikasi resmi sehingga tiap parser menerapkan dialeknya sendiri
  • XML diadopsi luas pada akhir 1990-an di dunia perangkat lunak enterprise, dan menyediakan hierarki arbitrer, schema, namespace, transformasi, serta struktur yang menjelaskan dirinya sendiri, tetapi file konfigurasi nyata menjadi sangat verbose sehingga sulit dipelihara secara manual
  • JSON muncul sebagai reaksi yang lebih ringan terhadap XML, dan dengan kesederhanaan object literal JavaScript menggantikan XML di web API pada akhir 2000-an dan awal 2010-an, tetapi sebagai file konfigurasi ia punya batasan berupa tidak adanya komentar, tidak adanya string multi-baris, dan larangan trailing comma
  • YAML pada 2001 dan TOML pada 2013 muncul untuk mengisi celah yang ditinggalkan JSON; YAML menawarkan sintaks berbasis indentasi dengan nesting arbitrer, banyak dokumen, referensi, dan tipe kustom, sedangkan TOML mengarah pada “INI yang distandardisasi” dengan tipe eksplisit dan spesifikasi resmi
  • Setiap generasi format baru berangkat dari ekses format sebelumnya, dan banyak masalah YAML saat ini lebih merupakan hasil dari versi spesifikasi tertentu dan parser yang terikat pada versi itu, bukan dari desain format itu sendiri

Masalah yang menjadi dasar penolakan terhadap YAML

  • Kritik terhadap YAML bukan masalah yang dibuat-buat, melainkan berdasarkan pengalaman nyata para programmer selama bertahun-tahun
  • Masalah Norway yang paling terkenal adalah ketika pada YAML 1.1 skalar tanpa tanda kutip NO ditafsirkan sebagai boolean false, sehingga no dalam daftar kode negara berubah menjadi nilai false 
    countries:
  - dk
  - fi
  - is
  - no
  - se

    ["dk", "fi", "is", false, "se"]
  • Aturan yang sama juga berlaku untuk yes, on, off, y, n dan berbagai variasi huruf besar-kecil; pemetaan port seperti 22:22 dibaca sebagai bilangan basis-60, nomor versi seperti 10.23 dibaca sebagai float alih-alih string, dan nilai yang tampak seperti tanggal ditafsirkan sebagai timestamp
  • Dalam kode data science dan machine learning, nama variabel alami seperti n dan y juga bisa ditafsirkan sebagai key False dan True, bukan key string, di bawah aturan boolean implisit YAML 1.1 
    {"variables": {"x": "features", False: "sample_size", True: "target"}}
  • Inferensi tipe implisit yang agresif pada YAML 1.1 dimaksudkan untuk keterbacaan, misalnya membaca true tanpa kutip sebagai boolean, tetapi pada file konfigurasi nyata justru menghasilkan ketidakpastian yang lebih besar
  • File konfigurasi sering tidak sering diedit dan kerap diubah oleh orang yang bukan penulis aslinya, sehingga salah parsing yang diam-diam bisa menyebar ke seluruh sistem selama berbulan-bulan, menjadikannya area yang paling sulit mentoleransi perilaku tak terduga
  • Kompleksitas spesifikasi YAML secara keseluruhan juga menjadi beban, dan spesifikasi YAML 1.2.2 adalah dokumen yang cukup besar dengan 10 bab dan struktur bagian bernomor empat tingkat
  • Ada banyak cara merepresentasikan string multi-baris, dan anchor serta alias membentuk sistem referensi yang kuat tetapi bagi kebanyakan pekerjaan konfigurasi membawa beban konseptual yang melampaui kebutuhan
  • Masalah keamanan pada deserialisasi objek berbasis tag, terutama kerentanan yaml.load() di Python, menjadi vektor serangan yang dikenal luas, dan kritik seperti ini memang valid terhadap YAML 1.1 beserta ekosistem alat di sekitarnya

Hal yang dikerjakan TOML dengan baik

  • TOML adalah format yang rapi, mudah dibaca, dan tidak ambigu untuk struktur konfigurasi yang datar atau dangkal
  • Sintaks TOML terasa akrab bagi siapa pun yang pernah melihat file INI, sambil menambahkan tipe eksplisit, spesifikasi resmi, dan dukungan nested table melalui key bertitik
  • pyproject.toml dan Cargo.toml biasanya memiliki section yang terdefinisi baik dengan kedalaman satu atau dua tingkat dan isi yang dapat diprediksi, sehingga TOML cocok untuk kasus seperti ini
  • Dalam TOML, string selalu dibungkus tanda kutip sehingga no tidak ambigu apakah boolean atau kata biasa; integer, float, dan tanggal adalah tipe kelas satu, dan komentar bekerja seperti yang diharapkan
  • Adopsi PEP 518 di ekosistem packaging Python dan penggunaan Cargo di komunitas Rust menjadi bukti bahwa TOML adalah pilihan yang tepat untuk ruang masalah seperti ini
  • Spesifikasi TOML cukup pendek sehingga programmer yang kompeten bisa menulis parser kompatibel dalam waktu akhir pekan, dan hasilnya adalah ekosistem parser yang besar, teruji baik, dan konsisten
  • TOML tidak memiliki masalah perpecahan versi seperti antara YAML 1.1 dan 1.2; TOML 1.0 tetap TOML 1.0 di mana-mana

Titik ketika TOML mulai terasa berat

  • Saat file konfigurasi perlu mengekspresikan kedalaman, struktur nested TOML bergantung pada header section bertitik ([servers.alpha]) atau array of tables ([[products]]), dan makin dalam nesting-nya, makin sulit dibaca
  • Martin Vejnár dari PyTOML, ketika menolak agar pustakanya dijadikan dependensi pip, menyebut pengalaman bahwa saat skema konfigurasi makin kompleks, sintaks TOML menjadi jelek dipandang dan sulit dibaca
  • Di YAML, indentasi menyampaikan hierarki secara langsung, sedangkan di TOML seluruh path harus diulang pada setiap header section 
    services:
  web:
    image: nginx:latest
    environment:
      DB_HOST: postgres
      DB_PORT: 5432
    resources:
      limits:
        memory: 512M
        cpu: "0.5"

    [services.web]
image = "nginx:latest"

[services.web.environment]
DB_HOST = "postgres"
DB_PORT = 5432

[services.web.resources.limits]
memory = "512M"
cpu = "0.5"
  • Pembaca TOML harus merekonstruksi struktur pohon di kepala dari rangkaian nama bertingkat yang datar, dan menurut pengukuran dalam dokumentasi StrictYAML, untuk mengekspresikan data yang sama file TOML memakai sekitar 50% lebih banyak karakter karena pengulangan prefiks path
  • Python telah lama menunjukkan bahwa memakai indentasi sebagai struktur bukan kelemahan, melainkan kekuatan, karena menghilangkan jenis bug saat struktur visual dan struktur sintaks tidak selaras
  • YAML mewarisi keunggulan struktur berbasis indentasi ini, sementara TOML tidak mewajibkan indentasi sehingga hubungan antara key dan tabel yang dikandungnya hanya ada pada header section, bukan pada tata letak fisik file
  • Dalam file konfigurasi yang bertingkat dalam, TOML sulit dipindai dan sulit diedit dengan yakin

Perubahan pada YAML 1.2

  • Spesifikasi YAML 1.2 diumumkan pada 2009, dan revisi klarifikasinya, 1.2.2, selesai pada Oktober 2021
  • Dalam YAML 1.2 Core Schema, hanya true, false serta True, False, TRUE, FALSE yang dikenali sebagai boolean, sedangkan yes, no, on, off, y, n adalah string biasa
  • Literal angka basis-60 yang menyebabkan masalah 22:22 dihapus sepenuhnya, dan timestamp bukan lagi tipe inti, sehingga dalam Core Schema nilai tanpa kutip seperti 2026-05-05 tidak otomatis dideteksi sebagai tanggal melainkan string
  • JSON menjadi subset yang ketat dan benar dari YAML 1.2, sehingga dokumen JSON yang valid akan diparse sama persis sebagai YAML
  • Aturan interpretasi tag menjadi lebih ketat dan jelas, dan spesifikasi itu sendiri ditulis lebih terang serta dipelihara secara terbuka di GitHub
  • YAML yang selama ini dikritik orang adalah YAML 1.1, sedangkan spesifikasi yang mendominasi saat ini adalah YAML 1.2 yang lebih aman dan dapat diprediksi
  • Masalahnya adalah pengalaman pengguna terhadap YAML dimediasi oleh parser, bukan oleh spesifikasi, dan bagi mayoritas pengguna Python parser itu adalah PyYAML yang mengimplementasikan YAML 1.1 dan tidak mengubah semantik inti sejak 2006

Lanskap parser YAML di Python

  • PyYAML adalah pustaka YAML de facto standar di Python, membungkus pustaka C LibYAML untuk performa dan juga menyediakan jalur alternatif Python murni
  • PyYAML diunduh jutaan kali per minggu dan menjadi dependensi bagi sangat banyak paket, tetapi mengimplementasikan YAML 1.1, sehingga menjadi akar pengalaman “YAML mem-parse kode negara sebagai boolean” di ekosistem Python
  • Repositori PyYAML memiliki lebih dari 200 issue terbuka dan lebih dari 100 pull request terbuka; proyeknya tetap dipelihara tetapi bergerak lambat, dan transisi major version ke semantik YAML 1.2 belum terwujud
  • ruamel.yaml mendukung YAML 1.2 dan menyediakan kemampuan round-trip editing yang mempertahankan komentar, flow style, dan urutan key, sehingga jauh lebih kuat daripada PyYAML untuk pelestarian komentar atau pengeditan yang sadar format
  • ruamel.yaml dalam mode round-trip default terutama memakai implementasi Python murni, sehingga jauh lebih lambat daripada jalur cepat berbasis C milik PyYAML, dan memiliki riwayat packaging yang membingungkan pipeline distribusi karena masalah namespace package dan rantai dependensi
  • StrictYAML mengimplementasikan subset YAML yang disengaja, dengan menghapus seluruh inferensi tipe implisit, tag, anchor, dan flow style
  • StrictYAML secara filosofis lebih dekat ke TOML daripada ke YAML penuh; ia adalah format yang aman dan sederhana dengan sintaks indentasi ala YAML, tetapi hanya untuk Python, tidak punya implementasi bahasa lain, dan tidak menargetkan kepatuhan spesifikasi
  • Dalam lanskap ini, telah lama kurang tersedia pustaka yang cepat, sepenuhnya patuh terhadap YAML 1.2, dan mudah menggantikan antarmuka default PyYAML

Memperkenalkan py-yaml12

  • py-yaml12 adalah parser dan formatter YAML 1.2 untuk Python, diimplementasikan dalam Rust demi kecepatan dan akurasi
  • py-yaml12 dibangun di atas crate YAML Rust saphyr, dan menyediakan API kecil serta terfokus berupa parse_yaml(), read_yaml() untuk pemuatan, serta format_yaml(), write_yaml() untuk serialisasi

  • Kesederhanaan

    • Untuk kebanyakan kasus penggunaan, desainnya memungkinkan bekerja dari awal sampai akhir hanya dengan tipe bawaan Python dasar seperti dict, list, int, float, str, None
    • Jalur umum tidak memiliki kelas dokumen khusus atau tipe node kustom, dan karena YAML 1.2 adalah superset JSON, semua JSON valid akan diparse sama persis
    • py-yaml12 mencapai kepatuhan 100% pada yaml-test-suite, kumpulan uji edge case dan kesesuaian yang dipelihara komunitas
    • no dalam daftar regions diam-diam menjadi False dalam perilaku YAML 1.1 milik PyYAML, tetapi dalam perilaku YAML 1.2 milik py-yaml12 ia tetap sebagai string "no" sebagaimana diwajibkan spesifikasi
    • API file-nya juga langsung dan lugas; jika dictionary Python ditulis ke disk lalu dibaca kembali, hasilnya adalah objek yang sama tanpa kehilangan informasi dalam round-trip
    • Untuk fitur YAML tingkat lanjut seperti nilai yang diberi tag, tersedia tipe pembungkus Yaml, tetapi untuk pekerjaan konfigurasi umum fitur ini opsional

  • Keamanan

    • Default py-yaml12 tidak hanya lebih nyaman dipakai, tetapi juga lebih aman, sementara pendekatan PyYAML yang berlawanan memperlakukan tag seperti perintah sehingga hanya dengan membaca file YAML saja bisa menjalankan kode Python arbitrer
    • Jika file YAML yang membuat alias untuk namespace tag Python object-apply milik PyYAML dibaca dengan yaml.load(f, Loader=yaml.Loader), kode Python akan dijalankan lebih dulu sebelum fungsi itu mengembalikan dictionary biasa
    • Dalam contoh, hasil parsing tampak sebagai {'debug': False, 'retries': 3}, tetapi sebelumnya variabel lingkungan YAML_PAYLOAD_RAN telah diatur menjadi '1', sehingga dari hasil saja tidak terlihat bahwa eksekusi telah terjadi
    • py-yaml12 tidak mengeksekusi tag yang tidak dipilih secara eksplisit, melainkan mempertahankannya sebagai data, dan tag yang tidak ditangani dikembalikan sebagai pembungkus Yaml yang memuat nilai dan tag

  • Kecepatan

    • Benchmark py-yaml12 membandingkan performa baca dan tulis pada ukuran file dari kilobyte hingga megabyte dengan jalur Python murni default PyYAML, CSafeLoader dan CSafeDumper berbasis LibYAML, serta ruamel.yaml
    • Karena logika inti parsing dan formatting diimplementasikan dalam Rust terkompilasi alih-alih Python terinterpretasi, py-yaml12 mampu memberikan performa yang bersaing dengan ekstensi C PyYAML sambil tetap mempertahankan kepatuhan penuh terhadap YAML 1.2
    • Saat ini belum banyak pilihan pustaka Python yang sekaligus menawarkan kepatuhan penuh terhadap YAML 1.2 dan performa setingkat ekstensi C PyYAML

Kesimpulan

  • Perdebatan umum YAML versus TOML lebih mendekati perdebatan melawan bentuk format yang bermasalah tetapi sebenarnya sudah tidak ada lagi; kritiknya nyata, tetapi bersifat historis
  • Kritik terhadap YAML sering kali sebenarnya menunjuk ke YAML 1.1 yang dialami lewat PyYAML, bukan ke spesifikasi dan implementasi YAML 1.2 yang benar
  • TOML tetap pilihan yang baik untuk konfigurasi yang dangkal dan datar, dan pyproject.toml memang cocok untuk peran itu, tetapi klaim bahwa YAML pada dasarnya tidak aman atau tidak dapat diprediksi tidak berlaku di hadapan parser YAML 1.2 yang kompatibel
  • Pertanyaan pentingnya bukan format mana yang terbaik secara abstrak, melainkan format dan alat mana yang cocok untuk tugas tertentu
  • Untuk file konfigurasi kompleks, bertingkat, dan ditulis manusia, YAML 1.2 dengan parser modern adalah jawaban yang kuat, dan format membaik dengan cara generasi berikutnya memperbaiki sisi kasar generasi sebelumnya
  • Di Python, pengalaman YAML modern yang patuh spesifikasi bisa dicoba dengan pip install py-yaml12
  • Di lingkungan R, r-yaml12 menawarkan manfaat yang sama, dengan kepatuhan penuh terhadap YAML 1.2, performa berbasis Rust, dan default yang aman setara dengan paket Python

Bacaan terkait

1 komentar

 
GN⁺ 21 jam lalu
Komentar Lobste.rs

  • Penjelasan bahwa YAML muncul untuk menutup celah JSON terasa aneh. Seingat saya, YAML berasal dari komunitas Perl, dan usianya mungkin sebanding dengan JSON atau bahkan lebih tua.
    Setelah menelusuri sejarah aslinya, salah satu pencipta YAML, Ingy dot Net, menulis artikel menarik yang menempatkan asal-usulnya pada rentang November 1999 hingga Januari 2001.
    Lalu jika melihat artikel sejarah JSON, bentuk JSON yang masih primitif muncul pada April 2001 dari cara mengirim pesan dari server ke klien lewat iframe tersembunyi dan tag <script>, dan baru menjadi format tersendiri pada 2002 ketika Douglas Crockford merilis json.org.
    Jadi YAML sedikit mendahului JSON, atau setidaknya jika dilihat longgar, keduanya berkembang hampir bersamaan. Menjelaskannya sebagai reaksi terhadap JSON atau sebagai upaya menutup kekurangan JSON tidak tepat; YAML pada kenyataannya adalah reaksi terhadap XML. JSON juga berawal dari alasan praktis untuk menyisipkan data langsung ke dalam tag <script>, tetapi sulit disangkal bahwa ia kemudian populer sebagai alternatif yang lebih sederhana daripada XML.
    Tulisan aslinya sendiri juga tampak menunjukkan jejak seperti ditulis LLM, dan proyek yang diperkenalkan juga terasa seperti hasil vibe coding.

    • Benar jika dikatakan YAML pada awalnya adalah reaksi terhadap XML sekaligus alternatifnya.
    • Saat tulisan itu mengkritik kompleksitas YAML lalu belakangan memuji spesifikasi YAML baru, saya juga mencium aroma LLM. Ia mengkritik spesifikasi 1.2.2 karena panjang sampai kedalaman 4 tingkat, lalu di bagian belakang mengatakan bahwa 1.2.2 memang masih besar tetapi jauh kurang rumit dibanding 1.1.
      Tiap kalimatnya terdengar masuk akal, tetapi secara keseluruhan membingungkan. Selain itu, agak aneh juga membela TOML sebagai bahasa yang punya spesifikasi sambil mengkritik YAML karena punya spesifikasi yang kompleks. Jadi rasanya seperti, memangnya YAML dulu tidak punya spesifikasi dan TOML punya?
    • Menambahkan satu hal lagi ke sejarah itu: Crockford awalnya menangani Data-E, yang merupakan subset dari E, dan Data-E hanya mengekspresikan data sederhana. Para penulis E kemudian beralih dari mendorong bahasa mereka sendiri ke arah membuat ECMAScript aman secara capability-safe, dan hasilnya beberapa gagasan dari E seperti WeakMap masuk ke ECMAScript.
      JSON pada dasarnya lebih dekat ke Data-E bergaya ECMAScript. Jika melihat halaman arsip Data-E, terlihat bahwa mereka juga bereaksi terhadap XML.
    • Jika tulisan itu ditafsirkan ulang dengan niat baik, mungkin yang dimaksud bukan pengembangan YAML itu sendiri, melainkan adopsi YAML sebagai reaksi terhadap keterbatasan JSON. Secara pribadi saya juga baru mengenal YAML setelah JSON sudah tersebar luas. Hanya saja, tidak ada data yang mendukung persepsi ini.

  • Dengan memakai inline table, contoh TOML yang “buruk” bisa menjadi seperti ini:

    [services.web]  
image = "nginx:latest"

environment = {  
  DB_HOST = "postgres",  
  DB_PORT = 5432,  
}

resources.limits = {  
  memory = "512M",  
  cpu = "0.5",  
}

    Terlihat cukup baik, dan kalau sekadar menghitung jumlah karakter, malah tampak lebih pendek daripada contoh YAML.

  • Kalau tujuan tulisan ini memang membela YAML, mungkin ini di luar cakupan, tetapi saya tetap berharap ia juga membahas TOML 1.1 dan fitur inline table yang baru. Itu menyelesaikan tiga hal yang saya tidak suka dari JSON: nama key tanpa tanda kutip, string komentar, dan dukungan trailing comma.

    • Mengatakan bahwa “kritik terhadap YAML sekarang menyerang bentuk yang bermasalah dan sudah tidak benar-benar ada lagi” mungkin masuk akal, tetapi setelah itu malah membantah versi TOML yang lama, yang terasa agak janggal.
      Python 3.15 mendukung TOML 1.1, dan adopsi TOML 1.1 tampak jauh lebih baik daripada YAML 1.2. Memperbarui parser TOML 1.0 ke 1.1 kemungkinan hampir sepele, tetapi menaikkan YAML 1.1 ke 1.2 tampaknya tidak demikian. Di yaml.org saya juga sulit menemukan daftar perubahannya; yang terlihat hanya dua spesifikasi raksasa.
      Hal seperti “Norway Problem” hanya catatan kaki kecil di antara alasan saya tidak menyukai YAML; alasan utamanya justru karena sulit diedit, memakai whitespace yang bermakna, dan secara umum cukup kompleks.

  • Menurut saya YAML, JSON, dan TOML masing-masing punya wilayahnya sendiri. Ruang yang lama terasa kosong kini diisi oleh https://kdl.dev/
    JSON = pertukaran data dengan nested arbitrer
    YAML = format kontainer dangkal untuk menampung string multi-baris
    TOML = file konfigurasi yang hampir datar
    KDL = DSL bergaya Ruby yang direpresentasikan sebagai data

    • Untuk proyek baru yang butuh konfigurasi, saya juga sudah menetap memakai KDL. Alasannya, ia menghilangkan banyak sintaks pemisah dan aturan indentasi yang tidak relevan.
    • KDL memang sangat bagus. Saya terus mencari kesempatan untuk memakainya. Ada situasi seperti pada XML, ketika memiliki atribut dan node anak sekaligus membuat markup jauh lebih mudah dibaca, dan menyenangkan karena pilihan seperti itu tersedia dalam sintaks yang ringan.
    • Begitu melihat contohnya saya langsung berpikir, “ini mirip SDLang,” dan ternyata memang bukan kebetulan. Senang jadi tahu tentang KDL.

  • Saya tidak suka YAML karena hal-hal seperti Norway problem. YAML 1.2 memang sedikit menguranginya, tetapi karena ada string tanpa tanda kutip, string seperti "", "Null", "true", "FALSE" tetap bermasalah dan memerlukan encoder yang memahami YAML. Saya juga tidak suka kompleksitasnya secara umum, tetapi alasan sebenarnya saya membenci YAML adalah ini

    karakter tab tidak boleh digunakan untuk indentasi
    Jika indentasi memiliki makna, melarang pencampuran tab dan spasi atau penggunaan yang tidak konsisten itu masuk akal. Pendekatan Python 3 terlihat cukup bagus
    Indentation is rejected as inconsistent if a source file mixes tabs and spaces in a way that makes the meaning dependent on the worth of a tab in spaces; a TabError is raised in that case.
    Tetapi YAML tampaknya menjadi satu-satunya format berkas yang mengizinkan atau mewajibkan indentasi namun tidak mendukung tab dan spasi sekaligus
    Bisa saja dikatakan bahwa Make tidak mendukung spasi, tetapi .RECIPEPREFIX dapat diatur ke nilai selain tab. Bahkan, tab di Make juga bisa dipandang bukan sebagai indentasi melainkan penanda yang digunakan Make

    • Saya tidak bisa menemukannya sekarang, tetapi saya ingat pernah membaca kutipan Guido van Rossum yang mengatakan bahwa jika ia membuat Python lagi dari awal, salah satu hal yang pasti ingin ia ubah adalah melarang karakter tab asli untuk indentasi
      PEP-8 juga sangat menyarankan untuk tidak memakai tab untuk indentasi

      Tabs should be used solely to remain consistent with code that is already indented with tabs.
      -- https://peps.python.org/pep-0008/#tabs-or-spaces

    • Sebagai referensi, spesifikasi NestedText juga mengatakan ini

      Only ASCII spaces are allowed in the indentation. Specifically, tabs and the various Unicode spaces are not allowed.

  • Logika “yang buruk itu bukan YAML, melainkan YAML 1.1, tetapi kebanyakan yang dipakai adalah parser 1.1” menurut saya tidak seefektif yang diinginkan tulisan ini
    Saya suka YAML jika dipakai dengan disiplin, dan saya juga senang ada parser berkinerja tinggi baru untuk YAML 1.2, tetapi jika versi yang “buruk” masih dipakai oleh mayoritas, saya rasa saya akan memilih yang lain. Jika saya tidak bisa mengendalikan parser mana yang akan dipakai sehingga tidak bisa yakin YAML saya akan ditafsirkan dengan benar, maka YAML secara keseluruhan masih dalam keadaan “buruk”
    Semua orang memang perlu pindah ke 1.2, tetapi sampai itu terjadi, menurut saya bersikap hati-hati terhadap YAML itu wajar

  • Pada kalimat “perdebatan YAML vs TOML biasanya adalah perdebatan yang menyerang format yang dalam bentuk bermasalahnya sebenarnya sudah nyaris tidak ada lagi, jadi keluhannya nyata tetapi bersifat historis”, saya ingin menjerit di hadapan GitHub Actions dan Kubernetes

  • Argumen pembelaannya kuat. Namun, untuk dokumen yang sangat sederhana, TOML lebih mudah dibaca, dan lebih mudah membuat orang memakai TOML daripada YAML
    Sayangnya, mengubah persepsi publik para pengembang terhadap sebuah alat punya ekor inersia yang panjang. Orang membaca suatu cerita, mengambil keputusan, lalu pindah ke alat lain yang tidak pernah melakukan kesalahan secara publik

    • Ini tidak berlaku lagi begitu pengorganisasian, termasuk array, melampaui 2 tingkat. Pada titik itu, indentasi membuat struktur jauh lebih mudah dipahami

  • Saya berharap parser YAML yang disertakan dalam interpreter Ruby mendukung YAML 1.2.2
    Tetapi saya tidak tahu bagaimana cara mengganti versi default ke versi baru tanpa merusak ekosistem

  • Akan bagus jika format berkas konfigurasi bisa menentukan schema yang terstandardisasi. Dengan begitu editor bisa melihat berkas konfigurasi sembarang dan memberi tahu jika ada kunci salah ketik atau ketidakcocokan tipe
    Tujuan setiap kunci juga seharusnya bisa didokumentasikan lewat petunjuk “hover”, dan pelengkapan otomatis untuk kunci yang valid juga harus mudah disediakan. Akan lebih baik lagi jika ada dukungan untuk assertion atau contract sederhana guna menangkap nilai yang salah. Misalnya, kunci "color" harus cocok dengan /#[a-fA-F0-9]{6}/
    Idealnya, dari sini juga harus bisa dibuat otomatis struktur data berkas konfigurasi

    • Itu pada dasarnya hanya menjelaskan XML apa adanya
      Ada berbagai format spesifikasi validasi seperti XSD atau Relax NG, dan saya paling akrab dengan XML DTD, jadi saya sulit berbicara banyak tentang yang lain
    • Untuk berkas JSON, menaruh properti $schema pada kunci tingkat teratas lalu merujuk ke berkas JSON Schema yang mendefinisikan schema yang benar adalah praktik yang cukup umum. Pada dasarnya ini adalah XSD untuk JSON. Editor yang bagus biasanya bisa memakai ini untuk menyediakan pelengkapan otomatis dan garis bawah merah
      Hal yang bagus adalah TOML dan YAML kurang lebih hanyalah JSON dengan sintaks yang berbeda, sehingga biasanya berkas JSON Schema juga bisa dipakai bersama