14 ms·

One thing to remember is that YAML is about 20 years old. It was created when XML was at peak popularity. JSON didn't exist (YAML is a parallel, contemporary ef

One thing to remember is that YAML is about 20 years old. It was created when XML was at peak popularity. JSON didn't exist (YAML is a parallel, contemporary effort). Even articulating the problems with XML's approach was an uphill battle. What you would replace it with is also hard. What use cases matter? What is the core model? A simple hierarchy? Typed nodes? A graph? What sort of syntax is needed for it to be usable? These were all questions. Seen in context, we got quite a bit correct. And yes... it has a few embarrassing warts and a few deep problems. Ah well. A second thing to consider... YAML was created before it was common that tech companies actively contributed to open source development. There are lots of things we could have done differently if we had more than a few hours per week... even a tiny bit of financial support would have helped. Finally, YAML isn't just a spec, it has multiple implementations. Getting consensus among the excellent contributors is a team effort, and particularly challenging when no one is getting paid for the work. Once you have a few implementations and dependent applications, you're kinda stuck in time. It was an special pleasure for me to have had the opportunity to work with such amazing collaborators. We did it gratis. We are so glad that so many have found it useful.

ngrilly 8y ago
I didn't know this bit of history. You're right, context explains a lot of the design choices made at YAML birth. Thanks for sharing.
chx 8y ago
Drupal 8 uses YAML* as its configuration language because JSON doesn't support comments. That simple. Thank you for YAML, it does deliver for us: it's human readable and it's easy to parse (see below). * I mean, it uses an ill defined subset of YAML. The definition is "whatever the Symfony YAML parser supports".
- jiveturkey 8y ago
  > JSON doesn't support comments eh? { "firstName": "John", "lastName": "Smith", "comment": "foo", } I know it isn't the same as #comments, but who cares really.
  - hexane360 8y ago
    It seems the main difference is your comments are all parsed and loaded into memory with the file, while official comments aren't.
  - trynewideas 8y ago
    > who cares really the person who came up with HOCON, probably
  - Smaug123 8y ago
    The trouble there is that your comments come in-band. What if you're trying to serialise something and you don't have the power to insist that it's not a dictionary with "comment" as a key?
  - dharmab 8y ago
    How do I do something like: { # comment with a note about the value of foo "foo": "bar", # comment with a note about the value of baz "baz": "qux" } Without driving myself and future readers insane with fooComments and bazComments? What if I need a multiline comment explaining a yak-shaving story for why a key is set to a certain value? What if the object in question is a set of keyword arguments, and adding new fields changes the behavior of whaever is parsing the document?
    - mottosso 8y ago
      Ok, I'll bite. { "#": "A foo variable", "foo": true, "#": "A bar variable", "bar": false } Alternatively. { "# A foo variable": "", "foo": true, "# A multiline..": "", "# .. bar variable": "", "bar": false } Presto!
      - chx 8y ago
        Sigh. All I wanted to do is to say thanks for the YAML standard -- comments are important but not the only problem with JSON. And truly I can't be expected to remember all of this discussion from like six plus years ago. One thing I remember though, it the trailing comma problem -- we upstreamed a grammar change to Doctrine annotation so "foo, bar," is OK because PHP arrays accept that and it's bonkers trying to code a mostly PHP system without trailing comma support. Also, JSON is no fun to write , you need to have [] {} all correct where YAML is much easier. The less sigils the better and most of Drupal YAMLs only use the dash, the colon and the quote. This is the grave mistake Doctrine committed as well, instead of simple arithmetic (>=1.0) they used mysterious sigils in version specification (~1.0). Drupal is in the business of constantly accepting new contributors and (~R∊R∘.×R)/R←1↓ιR is not newbie friendly, no matter how you slice and dice it. There are certainly advantages of sigil heavy languages like APL and Perl but the scare factor is too high.
- merb 8y ago
  well there is also toml and hocon (json supersets) which are "yaml like"
  - chx 8y ago
    TOM: Initial release 23 February 2013; 5 years ago Drupal 8 file format discussion was in 2011, predating it by two years. https://groups.drupal.org/node/159044 https://groups.drupal.org/node/159044
  - benatkin 8y ago
    TOML is more like ini than YAML. I don't like it because it uses the = symbol which seems imperative rather than declarative. (Same with HCL, it might be a nitpick but these are languages I'm going to be using all the time.) HOCON is interesting but at first glance it seems it might be too ambiguous for my tastes, because like YAML, because it supports both js-style ("//") and shell-style ("#") comments. JSON plus comments is beautiful because it adds minimally to an unambiguous language which lends itself to automatic formatting (stringificiation).
    - colatkinson 8y ago
      I'd argue that = only feels imperative if you're used to imperative languages. Prolog and Haskell, both of which focus on being declarative, also both use the equals sign.
      - benatkin 8y ago
        Fair enough. It still seems overkill to me though. A ":" seems much more unassuming than an "=".
  - user5994461 8y ago
    Don't forget HJSON if you want a json clone with comments. https://hjson.org/ https://hjson.org/
- skybrian 8y ago
  VS Code uses JSON with comments for config files. [1] Technically, this is not JSON. You won't be able to use a standard JSON parser without stripping comments first. But you can use a simple, JSON-like language with comments for config. [1] https://code.visualstudio.com/docs/languages/json#_json-with-comments https://code.visualstudio.com/docs/languages/json#_json-with...
  - EamonnMR 8y ago
    > you can use a simple, JSON-like language with comments for config. YAML can be employed as a simple JSON-like language with comments.
    - crooked-v 8y ago
      > simple YAML is much, much more complicated than JSON.
      - hk__2 8y ago
        > simple YAML is much, much more complicated than JSON. Quoting a single word from the parent’s sentence is misleading. The sentence "YAML can be employed as a simple JSON-like language with comments." is true because JSON is YAML, so you can parse a JSON file with #-comments using a YAML parser.
        skybrian 8y ago
        The parser is not simple, though, and that's what counts.
        bdhess 8y ago
        Most YAML users don't need to look at the source for a YAML parser. I appreciate elegant simplicity, but I don't think parser complexity is the most important metric by which to judge a data interchange format.
- wwweston 8y ago
  You know what else is human readable, easy to parse if you're using PHP, and supports comments? PHP. I understand why some languages rely on common configuration file formats. I don't understand why the popular dynamic script-y languages don't more commonly use the natively-expressable associative/list data structures that they're famous for making convenient.
  - krapp 8y ago
    >I don't understand why the popular dynamic script-y languages don't more commonly use the natively-expressable associative/list data structures that they're famous for making convenient. You picked the wrong language... PHP comes with its own JSON parser. And INI and XML and even CSV. But, the reason is that, generally, you want config files to describe data or state only. Yes, you could just make your config native code, but then the temptation to add functions and methods and logic to that becomes irresistible and soon your config is an application that needs its own config. Config formats need to be simple, and preferably not Turing complete.
    - user5994461 8y ago
      Any configuration will eventually become a programming language. See The Configuration Complexity Clock. https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html https://mikehadlow.blogspot.com/2012/05/configuration-comple...
      - krapp 8y ago
        Just because it's common doesn't mean it should be encouraged by writing your config in native code to begin with. INI is still simple, and JSON doesn't support logic, so the madness can be held at bay at least for a time. XML and s-expressions are lost causes, though.
  - akavel 8y ago
    Interestingly, the Lua programming language actually evolved from configuration files: https://www.lua.org/history.html https://www.lua.org/history.html (and is still officially deemed useful for writing them)
- DonHopkins 8y ago
  I totally agree that in the ideal world, JSON should support comments. I yearn for them, and none of the in-band work-arounds or post-processing tools are acceptable substitutes. But to play the devil's advocate, how would JSON be able to support round-tripping comments like XML can, since  are part of the DOM model that you can read and write, while JSON // and /* comments */ are invisible to JavaScript programs. There's nowhere to store the comments in the JSON object model, which you would need to be able to write them back out later! On important feature of JSON is being able to read and write JSON files with full fidelity and not lose any information like comments. XML can do that, but JSON can't. To fix that you'd have to go back and redesign (and vastly complicate) fundamental JavaScript objects and arrays and values, to be as complex and byzantine as the DOM API. The less-than-ideal situation we're in isn't JSON's fault or JavaScript's fault, because JSON is just a post-hoc formalization of something that was designed for a different purpose. But JSON is rightly more popular than XML, because it's extremely simple, and nicely impedance matched with many popular languages. YAML suffers from the same problem as JSON that it can't round-trip comments like XML can, but it fails to be as simple as JSON, is almost as complex as XML, and doesn't even map directly to many popular languages (as the article points out, you can't use a list as a dict key in Python, PHP, JavaScript, or Go, etc). You can sidestep some of JSON's problems by representing JSON as outlines and tables in spreadsheets, without any need for syntax and sigils like brackets, braces, commas, no commas, quoting, escaping, tabs, spaces, etc, but in a way that supports rich formatted comments and content (you can even paste pictures and live charts into most spreadsheets if you like), and even dynamic transformations with spreadsheet expressions and JavaScript. See my comments about that in this and another article: https://news.ycombinator.com/item?id=17360071 https://news.ycombinator.com/item?id=17360071 https://news.ycombinator.com/item?id=17309132 https://news.ycombinator.com/item?id=17309132
  - rhacker 8y ago
    I'm kinda sad that JSON has been struggling for like 15 years to get comments. Is there like some kind of gestapo that's saying no or something? All it takes is for the maintainers of probably 15 popular libraries to start handling comments. At the end of the day I'm sure the reason we don't have JSON comments is somewhere listed in this page: xkcd.com/927/
- pacala 8y ago
  Try https://jsonnet.org/ https://jsonnet.org/. Supports comments, plus a handful of additional useful features.
  - nojvek 8y ago
    Jsonnet is awesome. We use it to generate our yaml files for kubernetes. YAML isn’t easy to parse, nor is it very flexible as a templating language. It gets cumbersome very quickly. Jsonnet is a relief. Kubernetes should have been a dumb json config from the get go. JSON is ridiculously simple to parse and emit. It has huge interoperability as well with lots of programming languages.
    - pests 8y ago
      Kubenetes never intended to get stuck on YAML. The CNCF is backing Ksonnet which is Jsonnet for k8s if you haven't seen it before.
  - alessioalex 8y ago
    Oh man, you just made my day. Comments, imports and mixins, I just had an 'evrika' moment. P.S. You Romanian by any chance?
- kpil 8y ago
  Is there a yaml parser that preserves comments and a writer that manages to write them back though?
  - TimZehta 8y ago
    The parser linked from the article does: https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml
woah 8y ago
It's not really a moral judgement, thanks for your contributions and your innovations, but I prefer not to use YAML if possible for the same reasons the author outlined.
bhaak 8y ago
> JSON didn't exist (YAML is a parallel, contemporary effort). Interesting. How did it happen then that, quoting the YAML 1.2 spec, that "every JSON file is also a valid YAML file"? Although the previous spec documents don't mention JSON. Was that an intentional design decision for 1.2 or was it some kind of convergent design due to Javascript?
- ngrilly 8y ago
  The answer is in version 1.2 of the spec: > The primary objective of this revision is to bring YAML into compliance with JSON as an official subset.
- clarkevans 8y ago
  I have admired Douglas Crawford's excellent JSON from the moment I saw it, it is a model of simplicity. I also like TOML and wish it all the best. By contrast, YAML is complex and could use a hair cut. When I say "JSON didn't exist", what I mean is that it wasn't popular or known to us when we were working on YAML. So, please excuse my sloppy wording. For me, the work on what would become YAML started with a few of us in 1999 (from SML-DEV list). In January of 2001 we picked the name and had early releases. It took a few years of iteration before we had a specification the collaborators (Perl, Python, and Ruby) could all bless. Anyway, with regard to Crawford's excellent work, JSON. It is a coincidence that YAML's in-line format happened to align. Although, it's probably because of a "C" ancestor, not JavaScript. The main influence on the YAML syntax was RFC0822 (e-mail), only that from my perspective, it needed to be a typed graph. In fact, we documented where we stole ideas from, to the best we could recall at that time: http://yaml.org/spec/1.0/#id2488920 http://yaml.org/spec/1.0/#id2488920.
  - crdoconnor 8y ago
    >YAML is complex and could use a hair cut. Out of curiosity, did you see the parser linked to at the end of the article? ( https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml ) That was my attempt at giving YAML a haircut. I'd be curious to know what you thought. Thank you for creating YAML, by the way. Even though part of that rant was quoted from me, I'm not negative on it like the author - I think the core was brilliantly designed. If you put two hierarchical documents side by side - one in TOML and another in YAML the YAML one is much, much clearer and cleaner.
ebikelaw 8y ago
JSON definitely did exist 20 years ago.
- xnxn 8y ago
  > Douglas Crockford originally specified the JSON format in the early 2000s
  - frou_dh 8y ago
    > I discovered JSON. I do not claim to have invented JSON because it already existed in nature. What I did was I found it, I named it, I described how it was useful. I don’t claim to be the first person to have discovered it. I know that there are other people who discovered it, at least, a year before I did. The earliest occurrence I found was there was someone at Netscape who was using JavaScript array literals for doing data communication as early as 1996, which was at least 5 years before I stumbled onto the idea. https://www.youtube.com/watch?v=-C-JoyNuQJs https://www.youtube.com/watch?v=-C-JoyNuQJs
    - deleted 8y ago
      [deleted]
    - xnxn 8y ago
      According to Platonism, JSON has no spatiotemporal or causal properties (like a datetime format) and thus has existed and will exist eternally. All hail JSON.
    - btilly 8y ago
      I can independently confirm that people were using JSON before he named it JSON. I was dumping data in JSON in 2000 for dynamically displayed reports. But then again I was already used to using Perl data structures as dumped by Data::Dumper for config, because I was taught a lot about Perl by a Lisp programmer who had used Lisp data structures for the same purpose since the 1980s. So using JSON didn't feel original or clever. It seemed like I was simply using a well-known technique in yet another dynamic language. Then again our reaction to XML was the stupid thing other people were doing that you had to do to interact with the rest of the world. I got used to holding my tongue until I went to Google a decade later and found that my attitude was common wisdom there...
deleted 8y ago
[deleted]
arp242 8y ago
I am the author of this article. Apparently people read my website (how they get there, I don't know?) At any rate, it's worth mentioning that in the conclusion I wrote: > Don’t get me wrong, it’s not like YAML is absolutely terrible but it’s not exactly great either. I still use YAML myself even when I have the freedom to use something else simply because – for better or worse – it's very widespread, and for many tasks it's "good enough". For other tasks, I prefer to avoid it. I think that a stricter version of YAML (such as StrictYAML) would make a lot of people's lives easier though.
- sandov 8y ago
  I love the clean style of your website.
  - Carpetsmoker 8y ago
    Thanks! Last time I checked my domain got penalized for having abnormal low markup or some such, which apparently makes it look like a spam site. I am proud of this.
    - coherentpony 8y ago
      Penalised? By whom?
      - kurthr 8y ago
        I would assume tehGoog. Just to make it hard to find low impact sites that aren't AMP.
        coherentpony 8y ago
        Oh I see. Thanks.
      - loeg 8y ago
        The only search engine in town. You already know its name.
jv22222 8y ago
I love YAML, thanks for creating it, it's saved me a lot of time over the years.
winkeltripel 8y ago
Unity3D uses YAML for it's serialization engine. Thank you.
redsymbol 8y ago
Clark, thanks so much for YAML. I love it and use it a lot. It actually increases the day-to-day joy of the work I do as a developer. (While constructive criticism is fine, those rare people who trash it are... nonsensical to me. I'd like to see them do one-tenth as good under the same conditions!)
jbverschoor 8y ago
"JSON" became popular in the 90s. They were http requests which returned javascript which you would simply eval(). No need to write or import a parser, and it is the same syntax as the language you're using, because it is the same language. In technology many things become popular not because how good (or bad) things are, but how easy to use something is.
- JTbane 8y ago
  Can't agree more. In tech, the prime mover often becomes the standard.
homero 8y ago
I love json but despise the fact it doesn't support comments

ngrilly 8y ago

I didn't know this bit of history. You're right, context explains a lot of the design choices made at YAML birth. Thanks for sharing.

chx 8y ago

Drupal 8 uses YAML* as its configuration language because JSON doesn't support comments. That simple. Thank you for YAML, it does deliver for us: it's human readable and it's easy to parse (see below). * I mean, it uses an ill defined subset of YAML. The definition is "whatever the Symfony YAML parser supports".

jiveturkey 8y ago
> JSON doesn't support comments eh? { "firstName": "John", "lastName": "Smith", "comment": "foo", } I know it isn't the same as #comments, but who cares really.
- hexane360 8y ago
  It seems the main difference is your comments are all parsed and loaded into memory with the file, while official comments aren't.
- trynewideas 8y ago
  > who cares really the person who came up with HOCON, probably
- Smaug123 8y ago
  The trouble there is that your comments come in-band. What if you're trying to serialise something and you don't have the power to insist that it's not a dictionary with "comment" as a key?
- dharmab 8y ago
  How do I do something like: { # comment with a note about the value of foo "foo": "bar", # comment with a note about the value of baz "baz": "qux" } Without driving myself and future readers insane with fooComments and bazComments? What if I need a multiline comment explaining a yak-shaving story for why a key is set to a certain value? What if the object in question is a set of keyword arguments, and adding new fields changes the behavior of whaever is parsing the document?
  - mottosso 8y ago
    Ok, I'll bite. { "#": "A foo variable", "foo": true, "#": "A bar variable", "bar": false } Alternatively. { "# A foo variable": "", "foo": true, "# A multiline..": "", "# .. bar variable": "", "bar": false } Presto!
    - chx 8y ago
      Sigh. All I wanted to do is to say thanks for the YAML standard -- comments are important but not the only problem with JSON. And truly I can't be expected to remember all of this discussion from like six plus years ago. One thing I remember though, it the trailing comma problem -- we upstreamed a grammar change to Doctrine annotation so "foo, bar," is OK because PHP arrays accept that and it's bonkers trying to code a mostly PHP system without trailing comma support. Also, JSON is no fun to write , you need to have [] {} all correct where YAML is much easier. The less sigils the better and most of Drupal YAMLs only use the dash, the colon and the quote. This is the grave mistake Doctrine committed as well, instead of simple arithmetic (>=1.0) they used mysterious sigils in version specification (~1.0). Drupal is in the business of constantly accepting new contributors and (~R∊R∘.×R)/R←1↓ιR is not newbie friendly, no matter how you slice and dice it. There are certainly advantages of sigil heavy languages like APL and Perl but the scare factor is too high.
merb 8y ago
well there is also toml and hocon (json supersets) which are "yaml like"
- chx 8y ago
  TOM: Initial release 23 February 2013; 5 years ago Drupal 8 file format discussion was in 2011, predating it by two years. https://groups.drupal.org/node/159044 https://groups.drupal.org/node/159044
- benatkin 8y ago
  TOML is more like ini than YAML. I don't like it because it uses the = symbol which seems imperative rather than declarative. (Same with HCL, it might be a nitpick but these are languages I'm going to be using all the time.) HOCON is interesting but at first glance it seems it might be too ambiguous for my tastes, because like YAML, because it supports both js-style ("//") and shell-style ("#") comments. JSON plus comments is beautiful because it adds minimally to an unambiguous language which lends itself to automatic formatting (stringificiation).
  - colatkinson 8y ago
    I'd argue that = only feels imperative if you're used to imperative languages. Prolog and Haskell, both of which focus on being declarative, also both use the equals sign.
    - benatkin 8y ago
      Fair enough. It still seems overkill to me though. A ":" seems much more unassuming than an "=".
- user5994461 8y ago
  Don't forget HJSON if you want a json clone with comments. https://hjson.org/ https://hjson.org/
skybrian 8y ago
VS Code uses JSON with comments for config files. [1] Technically, this is not JSON. You won't be able to use a standard JSON parser without stripping comments first. But you can use a simple, JSON-like language with comments for config. [1] https://code.visualstudio.com/docs/languages/json#_json-with-comments https://code.visualstudio.com/docs/languages/json#_json-with...
- EamonnMR 8y ago
  > you can use a simple, JSON-like language with comments for config. YAML can be employed as a simple JSON-like language with comments.
  - crooked-v 8y ago
    > simple YAML is much, much more complicated than JSON.
    - hk__2 8y ago
      > simple YAML is much, much more complicated than JSON. Quoting a single word from the parent’s sentence is misleading. The sentence "YAML can be employed as a simple JSON-like language with comments." is true because JSON is YAML, so you can parse a JSON file with #-comments using a YAML parser.
      - skybrian 8y ago
        The parser is not simple, though, and that's what counts.
        bdhess 8y ago
        Most YAML users don't need to look at the source for a YAML parser. I appreciate elegant simplicity, but I don't think parser complexity is the most important metric by which to judge a data interchange format.
wwweston 8y ago
You know what else is human readable, easy to parse if you're using PHP, and supports comments? PHP. I understand why some languages rely on common configuration file formats. I don't understand why the popular dynamic script-y languages don't more commonly use the natively-expressable associative/list data structures that they're famous for making convenient.
- krapp 8y ago
  >I don't understand why the popular dynamic script-y languages don't more commonly use the natively-expressable associative/list data structures that they're famous for making convenient. You picked the wrong language... PHP comes with its own JSON parser. And INI and XML and even CSV. But, the reason is that, generally, you want config files to describe data or state only. Yes, you could just make your config native code, but then the temptation to add functions and methods and logic to that becomes irresistible and soon your config is an application that needs its own config. Config formats need to be simple, and preferably not Turing complete.
  - user5994461 8y ago
    Any configuration will eventually become a programming language. See The Configuration Complexity Clock. https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html https://mikehadlow.blogspot.com/2012/05/configuration-comple...
    - krapp 8y ago
      Just because it's common doesn't mean it should be encouraged by writing your config in native code to begin with. INI is still simple, and JSON doesn't support logic, so the madness can be held at bay at least for a time. XML and s-expressions are lost causes, though.
- akavel 8y ago
  Interestingly, the Lua programming language actually evolved from configuration files: https://www.lua.org/history.html https://www.lua.org/history.html (and is still officially deemed useful for writing them)
DonHopkins 8y ago
I totally agree that in the ideal world, JSON should support comments. I yearn for them, and none of the in-band work-arounds or post-processing tools are acceptable substitutes. But to play the devil's advocate, how would JSON be able to support round-tripping comments like XML can, since  are part of the DOM model that you can read and write, while JSON // and /* comments */ are invisible to JavaScript programs. There's nowhere to store the comments in the JSON object model, which you would need to be able to write them back out later! On important feature of JSON is being able to read and write JSON files with full fidelity and not lose any information like comments. XML can do that, but JSON can't. To fix that you'd have to go back and redesign (and vastly complicate) fundamental JavaScript objects and arrays and values, to be as complex and byzantine as the DOM API. The less-than-ideal situation we're in isn't JSON's fault or JavaScript's fault, because JSON is just a post-hoc formalization of something that was designed for a different purpose. But JSON is rightly more popular than XML, because it's extremely simple, and nicely impedance matched with many popular languages. YAML suffers from the same problem as JSON that it can't round-trip comments like XML can, but it fails to be as simple as JSON, is almost as complex as XML, and doesn't even map directly to many popular languages (as the article points out, you can't use a list as a dict key in Python, PHP, JavaScript, or Go, etc). You can sidestep some of JSON's problems by representing JSON as outlines and tables in spreadsheets, without any need for syntax and sigils like brackets, braces, commas, no commas, quoting, escaping, tabs, spaces, etc, but in a way that supports rich formatted comments and content (you can even paste pictures and live charts into most spreadsheets if you like), and even dynamic transformations with spreadsheet expressions and JavaScript. See my comments about that in this and another article: https://news.ycombinator.com/item?id=17360071 https://news.ycombinator.com/item?id=17360071 https://news.ycombinator.com/item?id=17309132 https://news.ycombinator.com/item?id=17309132
- rhacker 8y ago
  I'm kinda sad that JSON has been struggling for like 15 years to get comments. Is there like some kind of gestapo that's saying no or something? All it takes is for the maintainers of probably 15 popular libraries to start handling comments. At the end of the day I'm sure the reason we don't have JSON comments is somewhere listed in this page: xkcd.com/927/
pacala 8y ago
Try https://jsonnet.org/ https://jsonnet.org/. Supports comments, plus a handful of additional useful features.
- nojvek 8y ago
  Jsonnet is awesome. We use it to generate our yaml files for kubernetes. YAML isn’t easy to parse, nor is it very flexible as a templating language. It gets cumbersome very quickly. Jsonnet is a relief. Kubernetes should have been a dumb json config from the get go. JSON is ridiculously simple to parse and emit. It has huge interoperability as well with lots of programming languages.
  - pests 8y ago
    Kubenetes never intended to get stuck on YAML. The CNCF is backing Ksonnet which is Jsonnet for k8s if you haven't seen it before.
- alessioalex 8y ago
  Oh man, you just made my day. Comments, imports and mixins, I just had an 'evrika' moment. P.S. You Romanian by any chance?
kpil 8y ago
Is there a yaml parser that preserves comments and a writer that manages to write them back though?
- TimZehta 8y ago
  The parser linked from the article does: https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml

woah 8y ago

It's not really a moral judgement, thanks for your contributions and your innovations, but I prefer not to use YAML if possible for the same reasons the author outlined.

bhaak 8y ago

> JSON didn't exist (YAML is a parallel, contemporary effort). Interesting. How did it happen then that, quoting the YAML 1.2 spec, that "every JSON file is also a valid YAML file"? Although the previous spec documents don't mention JSON. Was that an intentional design decision for 1.2 or was it some kind of convergent design due to Javascript?

ngrilly 8y ago
The answer is in version 1.2 of the spec: > The primary objective of this revision is to bring YAML into compliance with JSON as an official subset.
clarkevans 8y ago
I have admired Douglas Crawford's excellent JSON from the moment I saw it, it is a model of simplicity. I also like TOML and wish it all the best. By contrast, YAML is complex and could use a hair cut. When I say "JSON didn't exist", what I mean is that it wasn't popular or known to us when we were working on YAML. So, please excuse my sloppy wording. For me, the work on what would become YAML started with a few of us in 1999 (from SML-DEV list). In January of 2001 we picked the name and had early releases. It took a few years of iteration before we had a specification the collaborators (Perl, Python, and Ruby) could all bless. Anyway, with regard to Crawford's excellent work, JSON. It is a coincidence that YAML's in-line format happened to align. Although, it's probably because of a "C" ancestor, not JavaScript. The main influence on the YAML syntax was RFC0822 (e-mail), only that from my perspective, it needed to be a typed graph. In fact, we documented where we stole ideas from, to the best we could recall at that time: http://yaml.org/spec/1.0/#id2488920 http://yaml.org/spec/1.0/#id2488920.
- crdoconnor 8y ago
  >YAML is complex and could use a hair cut. Out of curiosity, did you see the parser linked to at the end of the article? ( https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml ) That was my attempt at giving YAML a haircut. I'd be curious to know what you thought. Thank you for creating YAML, by the way. Even though part of that rant was quoted from me, I'm not negative on it like the author - I think the core was brilliantly designed. If you put two hierarchical documents side by side - one in TOML and another in YAML the YAML one is much, much clearer and cleaner.

ebikelaw 8y ago

JSON definitely did exist 20 years ago.

xnxn 8y ago
> Douglas Crockford originally specified the JSON format in the early 2000s
- frou_dh 8y ago
  > I discovered JSON. I do not claim to have invented JSON because it already existed in nature. What I did was I found it, I named it, I described how it was useful. I don’t claim to be the first person to have discovered it. I know that there are other people who discovered it, at least, a year before I did. The earliest occurrence I found was there was someone at Netscape who was using JavaScript array literals for doing data communication as early as 1996, which was at least 5 years before I stumbled onto the idea. https://www.youtube.com/watch?v=-C-JoyNuQJs https://www.youtube.com/watch?v=-C-JoyNuQJs
  - deleted 8y ago
    [deleted]
  - xnxn 8y ago
    According to Platonism, JSON has no spatiotemporal or causal properties (like a datetime format) and thus has existed and will exist eternally. All hail JSON.
  - btilly 8y ago
    I can independently confirm that people were using JSON before he named it JSON. I was dumping data in JSON in 2000 for dynamically displayed reports. But then again I was already used to using Perl data structures as dumped by Data::Dumper for config, because I was taught a lot about Perl by a Lisp programmer who had used Lisp data structures for the same purpose since the 1980s. So using JSON didn't feel original or clever. It seemed like I was simply using a well-known technique in yet another dynamic language. Then again our reaction to XML was the stupid thing other people were doing that you had to do to interact with the rest of the world. I got used to holding my tongue until I went to Google a decade later and found that my attitude was common wisdom there...

deleted 8y ago

[deleted]

arp242 8y ago

I am the author of this article. Apparently people read my website (how they get there, I don't know?) At any rate, it's worth mentioning that in the conclusion I wrote: > Don’t get me wrong, it’s not like YAML is absolutely terrible but it’s not exactly great either. I still use YAML myself even when I have the freedom to use something else simply because – for better or worse – it's very widespread, and for many tasks it's "good enough". For other tasks, I prefer to avoid it. I think that a stricter version of YAML (such as StrictYAML) would make a lot of people's lives easier though.

sandov 8y ago
I love the clean style of your website.
- Carpetsmoker 8y ago
  Thanks! Last time I checked my domain got penalized for having abnormal low markup or some such, which apparently makes it look like a spam site. I am proud of this.
  - coherentpony 8y ago
    Penalised? By whom?
    - kurthr 8y ago
      I would assume tehGoog. Just to make it hard to find low impact sites that aren't AMP.
      - coherentpony 8y ago
        Oh I see. Thanks.
    - loeg 8y ago
      The only search engine in town. You already know its name.

jv22222 8y ago

I love YAML, thanks for creating it, it's saved me a lot of time over the years.

winkeltripel 8y ago

Unity3D uses YAML for it's serialization engine. Thank you.

redsymbol 8y ago

Clark, thanks so much for YAML. I love it and use it a lot. It actually increases the day-to-day joy of the work I do as a developer. (While constructive criticism is fine, those rare people who trash it are... nonsensical to me. I'd like to see them do one-tenth as good under the same conditions!)

jbverschoor 8y ago

"JSON" became popular in the 90s. They were http requests which returned javascript which you would simply eval(). No need to write or import a parser, and it is the same syntax as the language you're using, because it is the same language. In technology many things become popular not because how good (or bad) things are, but how easy to use something is.

JTbane 8y ago
Can't agree more. In tech, the prime mover often becomes the standard.

homero 8y ago

I love json but despise the fact it doesn't support comments