YAML बहुत ज़्यादा है

• DevOps और CI कॉन्फ़िगरेशन में YAML लगभग एक standard की तरह इस्तेमाल होता है, लेकिन implicit type conversion और parser के फ़र्क की वजह से वही सेटिंग भी उम्मीद से अलग interpret हो सकती है
• YAML 1.1 में NO, 07, 08, 04:30, 0666 जैसे मान boolean·number·time·octal में बदल सकते हैं, इसलिए अगर इरादा string का है तो उसे साफ़ तौर पर दिखाना ज़रूरी है
• GitHub Actions, Kubernetes, CloudFormation और कई CI services के उदाहरण दिखाते हैं कि YAML syntax और service-specific structure की वजह से बार-बार commit, escape की nested परतें, और job representation में बिखराव पैदा हो सकता है
• संदर्भ लिंक executable YAML, parser के हिसाब से behavior का फ़र्क, multi-line string notation, version 1.70 का 1.7 के रूप में parse होने की समस्या, और StrictYAML के design rationale को साथ में जोड़ते हैं
• Nickel, Dhall, CUE, Jsonnet जैसे alternatives भी दिए गए हैं, लेकिन पेज खुद एक विशाल editable text field जैसा दिखता है और YAML की usability पर व्यंग्य को अंत तक बनाए रखता है

---

DevOps कॉन्फ़िगरेशन भाषा के रूप में YAML पर व्यंग्य

• YAML DevOps कॉन्फ़िगरेशन में आम है, लेकिन यह पेज “कोई भी YAML इस्तेमाल नहीं करना चाहता” जैसे वाक्यों के ज़रिए YAML थकान दिखाता है
• DevOps तकनीक के रूप में YAML इस्तेमाल करने की वजहों को उलटे ढंग से गिनाया गया है
  • जैसे यह हमेशा compile होकर deploy के लिए तैयार रहता है, इस तरह का व्यंग्य किया गया है
  • development के दौरान forced error handling न होने और production runtime में समस्या फटने वाली बात का मज़ाक उड़ाया गया है
  • line number वाले stack trace से बेहतर “कुछ टूट गया” जैसा message होने की बात कही गई है
  • नई CI pipeline बनाते समय समय जलाने की शिकायत शामिल है
  • Kubernetes इस्तेमाल करता है, इसलिए इसे safe choice मान लेने की स्थिति पर तंज़ है
  • JSON के विपरीत comments support करने वाला फायदा भी साथ में बताया गया है

implicit type conversion के जाल

• YAML 1.1 में NO boolean type के रूप में parse हो सकता है
  • NO: Norway country code के बजाय boolean interpretation की समस्या पैदा कर सकता है
  • अगर इरादा string का था, तो "NO" की तरह quotes में रखना चाहिए
  • YAML 1.1 spec में true या false लिखने के 22 तरीके होने की बात कही गई है
• number जैसे दिखने वाले मान भी parser के अनुसार अलग तरह से लिए जा सकते हैं
  • 07 और 08 का उदाहरण दिखाता है कि परिणाम [ 7, "08" ] जैसा अलग हो सकता है
  • इसे इस तरह व्यंग्य किया गया है कि Kubernetes cluster सातवें deploy तक चलता है और आठवें पर fail हो जाता है
• time जैसे दिखने वाली string भी auto-conversion का शिकार हो सकती है
  • 04:30 उपयोगकर्ता द्वारा लिखा गया समय न रहकर आधी रात के बाद के seconds 16200 में बदल सकता है
  • अगर इरादा string का है, तो !!str 04:30 की तरह explicitly लिखना होगा
• YAML की octal notation का फ़र्क भी भ्रम पैदा करता है
  • YAML 1.1 में 0666 notation इस्तेमाल होती है
  • YAML 1.2 में 0o666 notation इस्तेमाल होती है
  • Kubernetes के YAML 1.1 इस्तेमाल करने को “DevOps initiation ritual” जैसा दिखाया गया है

version·SHA·string handling की समस्याएँ

• package version floating-point की तरह parse हो सकते हैं
  • foo: 1.7 और bar: 1.70 एक ही version की तरह interpret हो सकते हैं
  • fizz: 1.7.0 और buzz: 1.70.0 अलग version strings की तरह handle हो सकते हैं
• CI में इस्तेमाल होने वाला छोटा Git SHA भी सुरक्षित नहीं हो सकता
  • 8-character SHA पूरी तरह digits का हो सकता है
  • बिना quotes डाला गया ${GIT_SHORT_SHA} वाला my.flaky_version string न रह जाए, ऐसा हो सकता है
  • इसे लगभग 98% मामलों में string बताया गया है, जबकि "${GIT_SHORT_SHA}" की तरह wrap करने पर 100% string माना गया है
• Rust toolchain का मामला भी संदर्भ लिंक में शामिल है
  • Toolchain version 1.70 is parsed as 1.7

CI और infrastructure configuration में दिखने वाली लागत

• GitHub Actions सीखते समय एक घंटे में 8 बार commit/push करने और आख़िरी commit message “I don't really like yml” होने का उदाहरण शामिल है
  • लिंक: https://twitter.com/eric_sink/status/1430954572848287744
• SQL को YAML में लिखा जाए तो वह कैसा दिखेगा, इसका उदाहरण भी है
  • SELECT, FROM, WHERE EXISTS, AND, EQUALS, LT जैसी SQL संरचनाएँ YAML की nested संरचना में बदल जाती हैं
  • छोटे SQL expression का लंबा और बोझिल YAML रूप में बदल जाना व्यंग्य का हिस्सा है
• हर CI service में job और step दिखाने का तरीका भी अलग है
  • Azure DevOps में jobs के नीचे job, steps, script का रूप इस्तेमाल होता है
  • CircleCI में jobs, job1, steps, checkout, run का रूप इस्तेमाल होता है
  • “future CI system” का उदाहरण दिखाता है कि वही काम किसी और nested संरचना में फिर से लिखा जा सकता है
• CloudFormation में CloudWatch DashboardBody के अंदर SEARCH function डालने पर पहले से escaped सामग्री को फिर escape करना पड़ता है और पूरे JSON को double quotes से बंद करना पड़ता है, ऐसा उदाहरण शामिल है

executable YAML और parser के फ़र्क

• “executable yaml” अभिव्यक्ति security से जुड़ी YAML parsing समस्याओं से जोड़ी गई है
  • Ruby YAML Security
  • PHP yaml_parse notes
  • Swagger YAML parser vulnerability
  • PyYAML yaml.load(input) Deprecation-Deprecation)
• YAML parser compatibility की समस्या पर अलग सामग्री भी दी गई है
  • Every YAML parser is a custom YAML parser
  • इसे इस बात के उदाहरण के रूप में रखा गया है कि हर parser का behavior एक जैसा नहीं होता

संबंधित सामग्री और alternatives

• 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
• YAML-केंद्रित DevOps के alternatives के रूप में कई tools और approaches सूचीबद्ध हैं
  • Nickel
  • Dhall
  • CUE
  • Jsonnet
  • kubenix example
  • tree.d

पेज पर ही प्रतिक्रियाएँ

• Reddit प्रतिक्रियाओं का संग्रह पेज के design को भी आलोचना का निशाना बनाता है
  • वेबसाइट एक विशाल editable text field जैसी लगती है, ऐसी प्रतिक्रिया है
  • hyperlinks clickable नहीं हैं, ऐसी प्रतिक्रिया है
  • पूरे पेज के text को select करके delete कर देने से समस्या हल हो गई, ऐसा मज़ाक भी है
  • YAML से नफ़रत वाली भावना से सहमति है, लेकिन वेबसाइट design का फैसला समझ से बाहर है, ऐसी प्रतिक्रिया भी है
• आख़िरी पंक्ति कहती है कि पेज जानबूझकर “YAML जितना usable” बनाया गया है

[GN⁺]

Hacker News की राय

• मेरी सबसे पसंदीदा सिरदर्द वाली चीज़ यह है:
  07
08
  नतीजा [ 7, "08" ] बन जाता है
  वजह है octal और string के बारे में assumption
  यह assumption तीन स्तर नीचे template से बने YAML में मिला, और हमारी तरफ पूरे k8s cluster outage की वजह बना, लेकिन सिर्फ 08 cluster ही टूटा। पहले 7 ठीक चल रहे थे

  • यह website बनाने वाला मैं ही हूं। इसे pull request के तौर पर भेज दें तो अच्छा होगा
  • धत्, लगता है आजकल ज्यादातर developers को octal या 0 prefix से लिखे जाने वाले octal numeric literals के बारे में पता नहीं होगा
    इस comment पर मैं हंसा जरूर, लेकिन 2023 में config files में octal इस्तेमाल करने वाले लोग लगभग नहीं हैं, यह देखते हुए ऐसा behavior और assumption समझ में नहीं आता। hexadecimal हो तो फिर भी समझ आता है, decimal तो obvious है, लेकिन octal थोड़ा ज्यादा है
  • समझ नहीं आता कि यह सही behavior कैसे हो सकता है
  • उस assumption को “discover” किया, यानी क्या spec पढ़ने के बजाय behavior पता है ऐसा मानकर इस्तेमाल शुरू कर दिया था?
    जिसने वह generate किया उसने साफ तौर पर data को किसी library से serialize नहीं किया होगा। library इस्तेमाल की होती तो वह types को सही format में convert कर देती

• YAML में समस्याएं बहुत हैं, लेकिन मुझे लगता है असली core problem config के अंदर logic डालने की कोशिश है
  अगर YAML को सिर्फ data के लिए इस्तेमाल करें, logic के लिए नहीं, तो यह इंसानों के पढ़ने-लिखने लायक अच्छे data formats में से एक है
  CI/CD में हमेशा कुछ न कुछ logic होता है, और सिर्फ pure YAML से बात शायद ही कभी खत्म होती है; ऊपर से अजीब templates भी मिल जाते हैं। सोचता हूं कि इसके बजाय असली programming language के लिए real API क्यों नहीं देते

  • वह YAML की समस्या नहीं, बल्कि ज्यादा करीब से YAML का misuse है। accidental Turing completeness हर जगह समस्या है
    15 साल पहले XML-based Ant इस्तेमाल करते समय भी यही समस्या थी, और वह XML की गलती नहीं थी
    मेरे हिसाब से YAML की मुख्य समस्या type safety की कमी है। गलत indentation, key typos, boolean के रूप में parse होने वाली strings जैसी चीजें
    बाकी मामलों में यह concise है और दूसरे formats की तुलना में syntax noise काफी कम है, इसलिए मुझे यह अच्छा format लगता है। इसी वजह से मैंने https://github.com/crdoconnor/strictyaml बनाया, ताकि लोग type-safe YAML इस्तेमाल करें और ऐसी समस्याओं पर तुरंत, साफ error messages पाएं
  • मेरे अनुभव में language जितनी ज्यादा चीजें कर सकती है, लोग उसे उतने ही ज्यादा जटिल तरीके से इस्तेमाल करने लगते हैं
    क्योंकि उन्हें लगता है कि जरूरत है, और वे abstractions ले आते हैं। इसलिए config format के रूप में Turing-complete programming language इस्तेमाल करने से मैं हमेशा बचता हूं
    AWS CDK को JavaScript debugger में line-by-line follow करते हुए मैंने कई घंटे बिताए हैं। अगर वह कोई simple और dumb yaml/Json/कुछ भी file होती, तो ऐसी समस्या नहीं होती। छोटा project था और complexity की जरूरत नहीं थी
    इसलिए JS tools की config में भी मैं JS के बजाय JSON पसंद करता हूं। webpack config के mess होने की वजह भी यही है। जब real language इस्तेमाल करने की सुविधा मिलती है, लोगों के “DRY sensors” चालू हो जाते हैं और वे इसे और complex बना देते हैं
    अगर यह declarative हो तो standard practices follow करना आसान होता है और tooling support भी बेहतर होता है। अगर package.json सच में build.gradle जैसा बन जाए, तो वह कहीं ज्यादा खराब होगा
  • Executable config बड़ा फायदा दे सकती है। Python साफ विकल्प है
    बस यह तय कर दें कि “script को कड़े limits वाले cgroup के अंदर Python interpreter में चलाया जाए, और उसके परिणाम में CONFIG नाम का dictionary आना चाहिए।” wrapper logic उसे target program के लिए convenient तरीके से serialize कर दे
  • खराब schema design YAML की गलती क्यों है, schema designer की नहीं, यह समझ नहीं आता
    यह helm की complexity या rigidity पर शिकायत करने जैसा है। Helm charts खुद नहीं लिखे जाते। शायद वजह यह है कि problem को समझकर implement करने के बजाय complain करना और ignore करना आसान है
  • 100% सहमत। जब लोग कहते हैं कि उन्हें YAML से नफरत है, तो कई मामलों में असल मतलब “मुझे YAML में pipeline describe करना पसंद नहीं” के करीब होता है। मैं भी वह feeling समझता हूं
    file format के रूप में YAML के pros और cons हैं। लेकिन असली समस्या conditionals, loops, functions, templates के जरिए classes/subclasses जैसी चीजों को JSON-equivalent file format में express करने की कोशिश में है
    YAML छोटे configs के लिए ठीक है। लेकिन जैसे ही किसी भी तरह का control flow चाहिए होता है, यह vendor-specific spaghetti में बहुत तेजी से बढ़ जाता है

• YAML के अंदर Jinja मुझे साफ़ तौर पर एक anti-pattern लगता है
  शुरुआत में पर्याप्त programmability के लिए design नहीं किया गया था, और बाद में शायद लोगों ने उन projects की नकल की जो इसी रास्ते पर जाकर सफल हुए
  लेख में Dhall और Jsonnet जैसे विकल्पों का ज़िक्र है, लेकिन दो और बातों पर सोचा जा सकता है
  पहला, असली programming languages के लिए configuration library बनाना और इस library से JSON config file generate करवाना। उस JSON को हाथ से edit करने की चीज़ नहीं, बल्कि केवल inspect/check किए जा सकने वाले artifact की तरह treat किया जाए। user tool support वाले code-form config को version control में डालता है। server पर सीधे emergency fix करना मुश्किल हो जाना इसकी कमी भी है और खूबी भी
  दूसरा, Starlark है। यह Python से निकली non-Turing-complete language है, जिसे पहले Bazel build system के लिए develop किया गया था। इसके कई implementations हैं और compatibility कितनी गहरी है, यह नहीं पता, लेकिन Python bindings भी हैं: https://github.com/caketop/python-starlark-go, https://github.com/inducer/starlark-pyo3

  • मैं इस बात से सहमत हूँ कि YAML के अंदर Jinja anti-pattern है, लेकिन खासकर इसलिए कि default block/expression characters {% और {{ दोनों YAML characters हैं, इसलिए हर use point को quotes में wrap करना पड़ता है
    GitHub Actions का ${{ या <%, << जैसे तरीके मुझे कहीं बेहतर लगते हैं। बेशक <<: के YAML syntax होने का जोखिम है, लेकिन वह legal Jinja नहीं है
    अगर मतलब यह है कि YAML के अंदर कुछ भी executable नहीं डालना चाहिए, तो मुझे लगता है वह ship already sail कर चुकी है। क्योंकि लोगों को समझ आ गया है कि literal हिस्से को default रखकर कभी-कभी executable हिस्सा डालना ASP/JSP/PHP की तरह content बनाने के लिए अच्छा है
    अगर इस thread में sibling flamewar शुरू करनी हो तो HCL और for_each की बात कर सकते हैं, लेकिन कम-से-कम यहाँ ऐसा न करना बेहतर होगा
  • CDK में Amazon ने यही रास्ता चुना है। कुछ हद तक यह काम करता है, लेकिन कोई भी non-trivial काम करने के लिए Rube Goldberg machine बनाने जैसा काफ़ी महसूस होता है
    इसमें कितना दोष CDK का है और कितना CloudFormation के मूल रूप से खराब होने का, यह नहीं पता
  • सहमत हूँ। templated YAML के साथ काम करना इतना झंझट भरा था कि आखिरकार इसी वजह से मैंने Cels नाम का tool बनाया: https://github.com/pacha/cels
    Jsonnet और Starlark मुझे पसंद हैं, लेकिन असल में ज़्यादातर use cases में नई programming language की ज़रूरत नहीं होती। आमतौर पर आप बस base document बनाकर patches apply करके उसे बदलना चाहते हैं। इससे सब कुछ बहुत सरल हो जाता है
    pure YAML इस्तेमाल करने का experience अपने-आप में इतना बुरा नहीं है। format में कुछ काफ़ी संदिग्ध हिस्से हैं, लेकिन यह usable है। मेरे हिसाब से समस्या उन workarounds की complexity में दिखती है जिन्हें document को कई environments के हिसाब से ढालने के लिए जोड़ना पड़ता है
  • इसी वजह से Ansible पर फिर से काम करने के बारे में सोचना भी nightmare है
    सुना था कि पहले YAML की जगह इस्तेमाल करने के लिए एक real Python DSL था, लेकिन लगता है बंद कर दिया गया। इसलिए अब loops और if-then YAML में लंबी-चौड़ी डरावनी गांठ बन जाते हैं, और Jinja को पूरी तरह unpredictable तरीके से interpret करता है
  • सोच रहा हूँ कि क्या jsonnet की तरह कोई standalone tool है जो Starlark code execute करके JSON या YAML generate कर सके

• मुझे लगता है YAML अपने-आप में बढ़िया है। जो बढ़िया नहीं है, वह यह कि हमने CD के deployment वाले हिस्से को बहुत ज़्यादा मुश्किल बना दिया है
  मैं मानता हूँ कि Azure DevOps में हमारी setup कोई बहुत शानदार नहीं है, लेकिन यह बात हैरान करती है कि ऐसी organizations हैं जहाँ कई teams या 5–6 operators को ऐसे tools संभालने पड़ते हैं। Google जैसी जगहों की बात अलग है, लेकिन किसी सामान्य enterprise में, जहाँ maximum concurrent users 50,000 हों या अक्सर उससे बहुत कम, यह जरूरत से ज्यादा लगता है
  2000s की शुरुआत में load balancing, networking वगैरह सब कुछ 0.25 full-time व्यक्ति से भी कम effort में संभालने वाले on-premises IIS पर enterprise web app deploy करना, आज की “modern” setup में वही चीज़ deploy करने से आसान था
  बेशक modern pipelines के फायदे हैं। “मेरे computer पर तो चलता है” वाली problem से हम काफी आगे बढ़े हैं, और बेहतर approval gates से quality control काफी बढ़ा है। लेकिन असली deployment 2023 में भी एक nightmare है
  यह असली technology companies या अच्छी dedicated DevOps team वाली companies के HN programmers के लिए शायद problem न हो। लेकिन non-technical enterprise दुनिया में CI/CD मेरे career में कभी इतना खराब नहीं रहा
  आप YAML को दोष दे सकते हैं, या इस बात को कि कुछ भी करने के लिए बहुत ज़्यादा YAML चाहिए और templates मुश्किल हैं। लेकिन मेरी राय में यह technical problem से कहीं ज्यादा organizational problem है। CD tools को कहीं ज्यादा automated होना चाहिए, ताकि developers को infrastructure को code के रूप में describe न करना पड़े
  यह अच्छी बात है कि ऐसा किया जा सकता है, लेकिन reality यह है कि लाखों developers से ऐसा infrastructure deploy करने को कहा जा रहा है जिसे वे शायद मुश्किल से समझते हों। मैंने ऐसा कोई developer नहीं देखा जो सिर्फ container देकर networking और “server-side चीज़ें” अपने-आप handle हो जाने की उम्मीद न करता हो
  ऐसा न करने पर ढेर सारे VNET और subnets बन जाते हैं जिनका काम कैसे चलता है, यह किसी को ठीक से नहीं पता होता, और developers को यह न पता होने की वजह से कि /x से किया जा सकता है, organization को बहुत पैसा गंवाना पड़ता है

  • cloud नया mainframe है
    आप किसी तरह की “job definition” offline लिखते हैं, उसे किसी proprietary shared system में submit करते हैं, queue में इंतजार करते हैं, और फिर ऐसे system द्वारा बनाए गए log files पाते हैं जिसे आप control नहीं करते। proprietary system code को workstation पर locally run नहीं कर सकते, इसलिए internal iteration cycle छोटी हो तो भी दसियों मिनट, और लंबी हो तो कई घंटे या कई दिन हो जाती है
    कोई preview या “what if” mode, “dry run” भी नहीं। भले ही इसे “test” कहा जाए, system सिर्फ एक ही होता है, इसलिए असल में आप production में ही काम कर रहे होते हैं
    असली problem YAML नहीं है। pipelines अगर ईश्वर की programming language में भी scripted हों, तो भी फर्क नहीं पड़ेगा
    centralized time-sharing mainframe के बजाय workstation पर software develop करने का तरीका इतना popular इसलिए हुआ था, क्योंकि उसने internal iteration को नाटकीय रूप से तेज किया, production environment से isolation दिया, और control वापस developer के हाथ में दिया
    मौजूदा generation की CI/CD pipelines आम तौर पर यह सब वापस उलट देती हैं
    single-machine Kubernetes workstation-based development के ज्यादातर फायदे वापस ला देता है, लेकिन यह अभी बहुत नया system है, इसलिए इसमें growth pains बहुत हैं
    इसी से जुड़ी problem यह है कि अकेले click-based काम से एक app चलाने वाले developer के लिए बढ़िया solutions हैं, और हजारों developers के लिए बड़े पैमाने की automation करने वाली बहुत बड़ी companies के लिए भी बढ़िया solutions हैं। लेकिन इनके बीच का इलाका—जहाँ कुछ enterprise developers दर्जनों apps manage करते हैं—बस chaos है
  • मुझे नहीं पता कि हम “मेरे computer पर तो चलता है” से पूरी तरह आगे निकल पाए हैं या नहीं
    मेरी Docker image में कई बार सब ठीक चला, लेकिन deployed image में चीजें टूट चुकी हैं
    यह ऐसी problem है जिसे पार करने के लिए पूरा build और deployment pipeline पूरी तरह transparent होना चाहिए, image repository की पूरी access होनी चाहिए, और build instructions पर सच में control होना चाहिए। यह local operating system को control करने जितना ही restrictive है, और मुझे लगता है कि जितनी organizations में दूसरे machine पर ले जाते समय code टूटता था, उतनी ही जगह यह भी fail होगा
  • मुझे समझ नहीं आता deployment में problem क्या है। मैंने जो चीजें setup कीं, उनमें बस commit पर tag लगाकर push करने से वही commit deploy हो जाता था
    किसी भी CI/CD system में ऐसा setup करना काफी intuitive लगता है

• अगर हर कोई सिर्फ एक नियम को सार्वभौमिक रूप से मान ले, तो शांति बनाए रखने का समाधान है: Python ecosystem के बाहर YAML का इस्तेमाल न करें
  तब वे लोग जिन्हें पठनीयता को शुद्धता, टिकाऊपन और maintainability से ऊपर रखने वाला गूढ़ scripting format पसंद है, tabs, loose types और गूढ़ syntax का इस्तेमाल जारी रख सकते हैं। बाकी लोगों को ऐसा करने की ज़रूरत नहीं रहेगी। C-style syntax पसंद करने वाले लोग अपना मानसिक संतुलन बनाए रख सकेंगे
  लगता है अब जाकर समस्या की जड़ पकड़ी है। C syntax developer होने के नाते मेरे लिए syntactic whitespace शुद्ध पागलपन है। whitespace जानकारी या command नहीं, formatting है। अच्छी formatting मददगार और उपयोगी होती है, और अच्छे C syntax developer भी पढ़ने लायक formatting की परवाह करते हैं
  Python और YAML में formatting ही निर्देशात्मक जानकारी है। इसका फायदा यह है कि हर काम करने वाला code पढ़ने में आसान हो जाता है। लेकिन code के काम करने के लिए उसका पढ़ने में आसान होना अनिवार्य क्यों हो?
  YAML जैसे सहकर्मी के साथ काम करने की कल्पना करें। आपने लंबा message भेजा और उसने जवाब दिया, “क्या? इसका कोई मतलब नहीं बनता।” पता चला कि आपने paragraphs के बीच खाली लाइनें नहीं डालीं, इसलिए अर्थ टूट गया। खाली लाइनें वापस डालकर message भेजते हैं तो वह आखिरकार पढ़ पाता है। यानी syntactically सही formatting के बिना भेजी गई जानकारी निरर्थक थी

  • software के रूप में code का एक और उद्देश्य execute होने के अलावा पढ़ा जा सकना भी है
    formatting करने के अनगिनत तरीके हैं, और मैं पसंद करता हूं कि लोग code लिखते समय linter इस्तेमाल करें। हो सके तो वही linter जो मैं इस्तेमाल करता हूं
    ऐसी languages standard syntax structure enforce करती हैं। पढ़ने में मुश्किल code लिखने के तरीके कम हो जाते हैं, इसलिए यह अच्छी बात है
  • आम तौर पर meaningful whitespace को दार्शनिक या धार्मिक मुद्दा माना जाता है। कुछ लोग इसे पसंद करते हैं, कुछ नापसंद; दोनों पक्ष अपनी पसंद को तर्कसंगत बताते हैं, लेकिन आखिर में यह मजबूत preference का मामला माना जाता है
    लेकिन अब मुझे लगने लगा है कि यह अंतर दर्शन का नहीं, tooling का मुद्दा है। कुछ tools, जैसे text editors या email programs, meaningful whitespace को अच्छी तरह support करते हैं, और कुछ नहीं करते
    जिन text editors का मैं इस्तेमाल करता हूं, वे सभी spaces और tabs दिखाने के लिए configured हैं, और दोनों को अलग-अलग दिखाते हैं। आम तौर पर हल्के dots और हल्के dashes जैसे। इसकी आदत है, इसलिए बिल्कुल खटकता नहीं
    मेरे नज़रिए से code कोई arbitrary text नहीं है। हम fixed-width font इस्तेमाल करते हैं जिसे किताब में नहीं इस्तेमाल करेंगे, और syntax को रंगों से अलग करते हैं। whitespace को visible न बनाने की भी कोई वजह नहीं
    फिर भी मैं meaningful whitespace न रखने वाली languages को थोड़ा ज्यादा पसंद करता हूं, लेकिन ऐसी languages से नफरत नहीं करता। मेरे लिए यह बिल्कुल समस्या नहीं है
    लेकिन अगर आपका पसंदीदा tool meaningful whitespace को अच्छी तरह support नहीं करता, whitespace को visible नहीं बनाता, या आप variable-width font में coding करते हैं, तो आप meaningful whitespace से जोरदार नफरत करेंगे और उसे शुद्ध पागलपन मानेंगे
  • C background होने की वजह से मैं भी यही सोचता था कि whitespace जानकारी या command नहीं है। Python के शुरुआती दिनों में इसी वजह से उसे थोड़ा कमतर भी समझता था
    मेरा नजरिया अप्रत्याशित रूप से CoffeeScript इस्तेमाल करते हुए बदला। मुझे JavaScript खास पसंद नहीं है, लेकिन CoffeeScript इस्तेमाल करना Crockford की The Good Parts का refined रूप जैसा लगा। खराब हिस्सों को गलती से बना देना संभव नहीं था
    ऊपर से indentation का code बन जाना काफी सुखद था। एकमात्र असुविधा यह थी कि Vi में opening brace या closing brace पर % दबाकर block का दूसरा सिरा नहीं खोज सकते। उल्टा, indentation की वजह से अगर code अजीब दिखता था तो अक्सर सच में अजीब होता था
    फिर भी Python अभी ज्यादा नहीं सीखा है। आजकल TypeScript इस्तेमाल करता हूं, लेकिन कभी CoffeeTypeScript आ जाए तो…
  • यह थोड़ा अजीब है कि TOML standard library में है लेकिन YAML नहीं। और TOML बदसूरत है
  • Kubernetes community दिलचस्प नज़रों से देख रही है

• इसलिए मैंने खुद BCL नाम का format बनाना शुरू किया: https://github.com/wkhere/bcl
  यह सभी YAML use cases में तुरंत मदद नहीं करेगा, लेकिन कम से कम Terraform जैसी style में resources define करने का ज्यादा अच्छा तरीका बन सकता है। असल में एक internal project में HCL replacement के तौर पर पहले से मदद कर रहा है, और वही इसे बनाने की आखिरी प्रेरणा थी
  बड़े स्तर पर देखें तो Kubernetes में YAML के हर जगह होने की समस्या में यह कैसे मदद करेगा, पता नहीं। मेरी $daily_job समस्या का आधे से ज्यादा हिस्सा यह है कि कई sources से final Helm chart जोड़ना बहुत ही भद्दा है
  इसका मतलब यह नहीं कि Helm मूल रूप से खराब tool है या हमारी company ने Helm को काफी खराब तरीके से चुना। मुझे लगता है सभी लोग परिस्थितियों को देखते हुए अपना सर्वश्रेष्ठ कर रहे हैं
  लेकिन meaningful whitespace वाले text templates को manipulate करना बहुत error-prone है, और errors भी बहुत देर से मिलते हैं। Kubernetes को YAML कितना शानदार है यह साबित करने की कोशिश करने के बजाय, C-style syntax पर आधारित custom format इस्तेमाल करना कहीं बेहतर होता। खासकर क्योंकि YAML शानदार भी नहीं है

  • YAML में दो अच्छी features हैं। multi-line strings और यह कि YAML, JSON का superset है
    JSON generate करने वाली कोई भी चीज़ YAML generate करने में इस्तेमाल की जा सकती है
    Nickel को JSON में evaluate किया जा सकता है: https://nickel-lang.org/
  • यह Nixcon talk प्रभावशाली थी
    https://youtu.be/SEA1Qm8K4gY?feature=shared
  • जानना चाहूंगा कि ucl देखा है क्या: https://github.com/vstakhov/libucl
    काफी similar लगता है

• यह internal platform effect है। application जितनी बड़ी होती है, configuration भी फैलती जाती है और आखिरकार programming language बन जाती है—लेकिन ऐसी language जिसमें bugs ज्यादा, specification कम और usability बेहद खराब होती है
  configuration bankruptcy घोषित करते हैं और नया configuration format चुनते हैं। फिर वही दोहराया जाता है
  बेशक format खुद भी पूरी तरह निर्दोष नहीं है। जितना ज्यादा flexible होगा, उतनी आसानी से खराब programming language के रूप में reuse होगा
  यह गलती बार-बार करने के बाद, आजकल मैं default configuration के लिए जितना संभव हो उतना सरल configuration format चुनूंगा। .ini भी बहुत शक्तिशाली हो सकता है। अधिक जटिल “configuration” को असली programming language को सौंपूंगा, संभव हो तो उसी language को जिसमें application लिखी गई है

• “YAML अच्छा नहीं है” वाले उदाहरणों में भारी बहुमत अजीब literals को पूरा quotes में डाल देने से हल हो जाता है
  यह सच है कि YAML कभी-कभी परेशान करता है। उदाहरण के लिए maps की list जल्दी ही अजीब हो जाती है, और meaningful whitespace लगभग तय है कि कभी न कभी अड़ंगा लगाएगा। लेकिन ऐसे लेख, अच्छे से अच्छा मानें तो भी, थोड़े लापरवाह लगते हैं

  • लेकिन उन उदाहरणों में से कोई भी quotes इस्तेमाल नहीं करता, और tools भी ऐसा नहीं करते
    पूरा YAML ecosystem values को बिना quotes लिखने की ओर धकेलता है। ज़्यादातर समय यह ठीक चलता है, फिर बस कभी-कभार इतना टूटता है कि production में ठोकर लग जाए

• EDN Clojure का subset है: https://github.com/edn-format/edn
  स्पष्ट, streamable, extensible, और whitespace-sensitive नहीं है। हालांकि readability के लिए formatting conventions हैं

  • यह पहली बार देखा कि कोई data format list और set को explicit तौर पर अलग करता है, और यह अच्छी बात है
    लेकिन list और vector के semantic difference क्या हैं, यह मुझे ठीक से समझ नहीं आता। मेरे दिमाग में arrays और linked lists code के अंदर data structures की implementation details हैं, data format का फर्क नहीं
  • alternatives से काफी बेहतर है। सच में उम्मीद है कि यह Clojure ecosystem के बाहर भी इस्तेमाल होना शुरू हो
  • सटीक रूप से कहें तो इसे whitespace-independent कहना मुश्किल है, क्योंकि elements की boundary या separation के लिए whitespace चाहिए
    फिर भी semantic indentation वाली चालबाज़ी बिल्कुल नहीं है। यह बात खूबसूरत है कि comma को whitespace माना जाता है और उसकी जरूरत नहीं होती

• जब छात्र e-learning platform से assignments submit करते हैं, तो हमें सभी submissions एक काफी बड़ी XML file के रूप में मिलती हैं
  submissions पढ़कर, static analysis और example execution को पास करने के बाद, हम हर assignment के लिए एक YAML file लिखते हैं जिसमें सभी submissions, grading hints, comments और score input fields वगैरह होते हैं
  फिर YAML file से markdown+processing (Pandoc) के जरिए reports, statistics, और feedback PDFs generate करते हैं
  हमारे लिए YAML बहुत अच्छी तरह fit बैठता है। क्योंकि Markdown syntax में extra feedback डालना आसान है। जैसे सही indentation के साथ - you missed a \NOT` here` जैसा कुछ
  block text के कई escaping तरीकों की वजह से, छात्र अलग-अलग SQL delimiters इस्तेमाल करें तो भी SQL submissions को escape characters के बिना अच्छे से output किया जा सकता है
  सब कुछ plain text है, इसलिए सिर्फ text editor इस्तेमाल करते हैं, और grading accountability के लिए git में store करते हैं। हर चीज़ machine-readable रखी जाती है, इसलिए पुराने submissions पर नए static analysis tools भी test कर सकते हैं
  लेकिन CI pipelines और home automation settings भी YAML में ही लिखनी पड़ती हैं, इसलिए वह दर्द समझ आता है

  • embedded text का indentation हटाना शायद YAML की सबसे अच्छी feature है
    TOML में या तो multi-line string indentation छोड़कर readability घटानी पड़ती है, या हर line के अंत में backslash डालना पड़ता है। दोनों में से कोई भी ideal नहीं
    इसलिए जिन DSLs या settings में Markdown या कोई दूसरा text format शामिल करना हो, उनके लिए YAML काफी अच्छा है, और TOML जैसी चीज़ों पर बढ़त रखता है
    लेकिन “YAML fatigue” की पूरी जिम्मेदारी सिर्फ उन CI और DevOps tools पर नहीं डालूंगा जिन्होंने DSL के carrier format के रूप में YAML चुना। जैसा original post ने अच्छी तरह summarized किया है, YAML में खुद भी बड़ी समस्याएं हैं
    मशहूर “Norway problem” YAML 1.2 में हल हो गई थी, और leading 0 को octal के रूप में parse करने वाली समस्या भी YAML 1.2 में हल हुई थी। numbers, dates, times आदि पर excessive type coercion confusing हो सकता है। multi-line string handling modes भी काफी confusing हो सकते हैं। unsafe serialization modern parsers में समस्या नहीं है, लेकिन Ruby, Python, Java जैसी dynamic features वाली पुरानी languages में YAML इस्तेमाल करते समय सावधान रहना चाहिए
    यह सब YAML specification की ही समस्याएं हैं