12 ms·

YAML: It's Time to Move On

• ribit 5y ago
  One step forward, one step back, one step sideways. It's a great idea to have line types, but the treatment of block text is terrible... at least with YAML I can embed markdown and have the paragraphs come out correctly. Multiline keys... are they really that important so that we have to jump through awkward looking syntax hoops to get them? And please, why keep inline object definitions? Nobody needs them! It won't kill you to write a list over multiple lines. Some verboseness is good if it enforces structure. I use YAML quite extensively for an internal tool, since it's pretty much the only human-useable format out there. But the weirdness of the language makes it error-prone while the quality of available parsers is simply unacceptable. I ended up writing my own parser for a subset of unambiguous YAML (not unlike StrictYAML, but even simpler) that offers nice error messages etc. and it works very well for us.
• 8lall0 5y ago
  1) No, no, no, please avoid stuff that needs to be indented in 2021. YAML is more than enough to prove that is a silly thing to do. 2) If your configuration file is too big, maybe you're doing it wrong. 3) TOML is by far the less ugly format for configurations that i've ever used. Far from perfect, but it's predictable and doesn't require indentation.
• Areading314 5y ago
  Surprised they didn't call it YAYAML
• deknos 5y ago
  what's wrong with dhall?
  • de_keyboard 5y ago
    Does Dhall have a .NET implementation yet?
    • Smaug123 5y ago
      You can always convert it to JSON before consumption.
      • endgame 5y ago
        I've been doing this when writing CloudFormation, and it helps a lot.
    • FridgeSeal 5y ago
      I’m confused: why would Dhall need a specific .net implementation?
      • dmitriid 5y ago
        Because you don't want to bring in a separate language with a separate runtime with unknown interop story just to read config files?
        • FridgeSeal 5y ago
          You don’t do that pre-launch? I use it to generate the config files, and pass the generated config to the application the same way you’d pass any other json/yaml/etc to your app. Neither ever talk to each other, and Dhall doesn’t exist within our runtime environment.
      • pharmakom 5y ago
        Dhall must be interpreted to find the finished config, correct? I would like to do that inside my application if possible.
• whynotmaybe 5y ago
  Mandatory xkcd https://xkcd.com/927/ https://xkcd.com/927/
• IceWreck 5y ago
  Huh, no. YAML is a superset of JSON. So valid JSON is valid YAML. This is sometimes suprisingly useful. Also, YAML is used everywhere and like the other user pointed out, has mature well tested libs for almost every language.
  • bmn__ 5y ago
    > YAML is a superset of JSON. That's false. http://p3rl.org/JSON::XS#JSON-and-YAML http://p3rl.org/JSON::XS#JSON-and-YAML
  • imglorp 5y ago
    Another JSON superset is HOCON. The H is for human.
    • speed_spread 5y ago
      HOCON is pretty good. Probably the sanest format for config files.
  • tuukkah 5y ago
    Indeed: "YAML version 1.2 is a superset of JSON" https://en.m.wikipedia.org/wiki/JSON#YAML https://en.m.wikipedia.org/wiki/JSON#YAML
  • TedDoesntTalk 5y ago
    How is YAML a superset of JSON? never heard that claim before.
    • BiteCode_dev 5y ago
      Any valid json can be parsed by any 1.2 yaml parser. That's how it gained popularity in the first place: you didn't have to migrate. Like ascii and utf8.
      • riffraff 5y ago
        When YAML came out there was no large JSON usage to migrate from, the incumbent in configuration was "human readable serialization" was XML.
• the_duke 5y ago
  Two interesting configuration language alternatives: https://dhall-lang.org/ https://dhall-lang.org/ https://cuelang.org/ https://cuelang.org/
  • BiteCode_dev 5y ago
    I've tried dhall, cue and jsonet, and cue is so far my fav. It's very well designed, expressive, but restrictive enough so that config files don't look like scripts. The way it blend types and values makes learning it super easy, yet you can do complex things with few lines. But the main implementation exports to yaml without quoting the strings, which kinda defeat the purpose :(
    • mananaysiempre 5y ago
      I’m kind of unsure about the way CUE achieves reuse: if I understand correctly, you have files in a directory tree and the (result of processing the) bottommost files are the things you’re supposed to point your consuming tools at. So there’s no way to share structure among a collection of items if that collection is nested inside your config, the only operation available is essentially the generation of a set of similar but separate configs. Or am I wrong here? I’d very much like to be. (Also, the type system is absolutely delicious, but it badly needs a paper with a complete description. I’m extremely interested in how it works, but fragmentary “notes on the formalism underlying” CUE are not enough.)
      • BiteCode_dev 5y ago
        You do have imports and functions so you can reuse what you want. The doc is also quite clear and rich, but the way it's organized means I have to read it entirely before writting my first CUE file. It also lacks IRL examples so trials and errors were my best friends. It can be discouraging.
        • yawnxyz 5y ago
          cuetorials.com really helped me get there
• stillicidious 5y ago
  Author seems to use misfeatures of a particular implementation to tar all implementations with. The round-tripping issue is not a statement about YAML as a markup language, much in the way a rendering bug in Firefox is not a statement about the web. Stepping back a bit, YAML is good enough, and this problem has been incrementally bikeshedded since at least the 1970s, it is time to move on. Human-convenient interfaces (like YAML, bash, perl) are fundamentally messy because we are messy. They're prone to opinion and style, as if replacing some part or other will make the high level problem (that's us) go away. Fretting over perfection in UI is an utterly pointless waste of time. I don't know what NestedText is and find it very difficulty to care, there are far more important problems in life to be concerned with than yet another incremental retake on serialization. I find it hard to consider contributions like this to be helpful or represent progress in any way.
  • tannhaeuser 5y ago
    > YAML as a markup language YAML ain't markup language.
  • Banana699 5y ago
    >Human-convenient interfaces (like YAML, bash, perl) are fundamentally messy because we are messy I don't know what to make of this statment, it has so much handwaving built-in. The most charitable interpretation I can find is that by 'Human-convenient' you simply meant the quick-and-dirty ideology expressed in Worse Is Better: Does job, makes users contemplate suicide only once per month, isn't too boat-rocking for current infrastructure and tooling. Taken at face value (without special charitable parsing), this statement is trivially false. Python is often used as a paragon of 'Human-convenience', I sometimes find this trope tiring but whatever Python's merits and vices its _definitely_ NOT messy in design. Perl is the C++ of scripting languages, it's a very [badly|un] designed language widely mocked by both language designers and users. Lua and tcl instead are languages literally created for the sole exact purpose of (non-) programmers expressing configuration inside of a fixed kernel of code created by other programmers, and look at their design : the whole of tcl's syntax and semantics is a single human-readable sentence, while lua thought it would be funny if 70% of the language involved dictionaries for some reason. These are extremely elegant and minimal designs, and they are brutally efficient and successful at their niches : tcl is EDA's and Network Administration's darling, and lua is used by game artists utterly uninterested in programming to express level design. 'Humans are messy' isn't a satisfactory way to put it. 'Humans love simple rules that get the job done' is more like it. But because the world is very complex and exception-laden, though, simple rules don't hug its contours well. There are two responses to this: - you can declare it a free-for-all and just have people make up simple rules on the fly as situations come up, that's the Worse Is Better approach. It doesn't work for long because very soon the sheer mountain of simple rules interact and create lovecraftian horrors more complex than anything the world would have thrown at you. Remember that the world itself is animated by extremely simple rules (Maxwell's equations, Evolution by Natural Selection, etc...), it's the multitude and interaction of those simple rules that give it its gargantuan complexity and variety. - you stop and think about The One Simple Rule To Rule All Rules, a kernel of order that can be extended and added to gradually, consistently and beautifully. The first approach can be called the 'raster ideology', it's a way of approximating reality by dividing it into a huge part of small, simple 'pixels' and describing each one seperately by simple rules. I'm not sure it's 'easy' or 'convenient', maybe seductive. It promises you can always come up with more rules to describe new patterns and situations, and never ever throw away the old rules. This doesn't work if your problem is the sheer multitude and inconsistency of rules. The second approach is the 'vector ideology', it promises you that there is a small basis of simple rules that will describe your pattern in entirety, and can always be tweaked or added to (consistently!) when new patterns arise, the only catch is that you have to think hard about it first.
• _bsless 5y ago
  Modest proposal - The real problem I see with JSON is it's not rich enough. Not a problem if you're using EDN https://github.com/edn-format/edn https://github.com/edn-format/edn
• account-5 5y ago
  I like INI. It's simple it's readable and it leaves the data types up to the application to interpret. It's also really easy to parse, I can work out how to do it and JSON is beyond me. I like CSV (and similar delimited files) it's less verbose than anything else for tabular data. I like JSON for data transfer, you know the data types, it's succinct, and readable. I personally don't need anything else.
  • aspaceman 5y ago
    This is the right answer in my view. If you need something structured use XML, otherwise INI. I'm more likely to Yacc my own config format than use YAML or JSON personally. JSON is great as an output format for data though.
  • zz865 5y ago
    INI is my favorite. I dont understand why it isn't the automatic default for everything.
    • gray_-_wolf 5y ago
      As far as I know there is no standard for INI. There is a TOML that looks close enough I guess?
      • zz865 5y ago
        TOML looks good. I'd rather it be call the ini standard but.
    • chii 5y ago
      iirc, it's hard to do any nested structure in INI - you'd have to do a convention like putting prefixes and dots in the name of the entry to denote hierarchy.
  • FpUser 5y ago
    Exactly what I think about the matter. Sometimes I use proprietary binary formats together with UDP where performance is critical (game servers for example).
• rendall 5y ago
  I don't understand this. YAML has limitations. All formats have limitations. If a format is too limiting, don't use it. Pick one more suitable, or come up with another one, like NestedText (or whatever). What is this need to tell everyone else to "move on" from using some format because it doesn't sit your specific preferences or use case?
  • tannhaeuser 5y ago
    Especially since the post title doesn't match the linked article's heading.
    • rendall 5y ago
      Yes! Thanks for pointing that out! You're right!
  • remram 5y ago
    I don't understand this. Opinions are not universal, every blogger has limitations. If you don't agree with a HN title, don't read it. Pick the next one or read another site. What is this need to tell everyone that you don't like them to tell everyone to "move on" just because it doesn't sit your specific preferences in formulation?
    • rendall 5y ago
      I see what you did there, but it comes off as mocking and not so clever. The difference between my post and that blog, and your reply for that matter, is that I'm not telling anyone not to read it. I'm inviting you to comment on why people feel the need to tell others to move on. Here's a good example of how to respectfully disagree: https://news.ycombinator.com/item?id=29220994 https://news.ycombinator.com/item?id=29220994
  • firearm-halter 5y ago
    The person that creates the config file does not necessarily choose the config file format. In the example, github chose YAML and everyone using github actions must use it. YAML is error prone, as everyone that tests with Python is finding out as the add Python 3.10 to their regression tests. This is a plea to organizations like github to stop choosing YAML.
• midasuni 5y ago
  Not a fan of Yaml. An ini file (no space problems) for simple config, json for more complex structure, csv for multiple entries with the same fields
• dylan604 5y ago
  I have a client that uses a CMS of unknown origins. I just get stuff placed in an s3 bucket, and then attempt to parse what was provided. 100% of their YAML files are invalid by every single linter I have found/tried. Not one of them understands where the error is occuring to help debug. It litterally just says invalid. I'm at a total loss. My head doesn't think YAML. Does a string need quoting or not? trailing spaces at the end causes problems? my personal experience in YAML is limited, but it hasn't been pleasant.
• _8j50 5y ago
  My opinion: I can live with yaml and json. Toml,tjson if I have to. Xml with a gun to my head. But I don't want yet another markup language (ironically that's what YAML stands for)
  • adorton 5y ago
    YAML stands for "YAML Ain't Markup Language"
    • ashtonkem 5y ago
      Which is more than a tad bit ironic, in retrospect.
      • lawtalkinghuman 5y ago
        Not really since it's true. It isn't markup, it's a configuration file format. "<em>This</em> is a markup language" since there is text which is marked up. YAML/JSON is a way to serialise fairly common data structures (arrays/lists, hashes/dictionaries, numbers, strings, bools, etc.) Incidentally, if you can seamlessly replace XML with something like JSON, then you probably aren't using the 'markup' bit of XML.
        • ashtonkem 5y ago
          Ah, yes, that’s totally correct. I was mentally glossing over the difference between markup and configuration languages.
    • DonHopkins 5y ago
      There was a previous discussion about YAML: YAML: Probably not so great after all (arp242.net) https://news.ycombinator.com/item?id=20731160 https://news.ycombinator.com/item?id=20731160 https://www.arp242.net/yaml-config.html https://www.arp242.net/yaml-config.html To which I posted: https://news.ycombinator.com/item?id=20735231 https://news.ycombinator.com/item?id=20735231 I was suspicious of YAML from day one, when they announced "Yet Another Markup Language (YAML) 1.0", because it obviously WASN'T a markup language. Who did they think they were fooling? https://yaml.org/spec/history/2001-08-01.html https://yaml.org/spec/history/2001-08-01.html XML and HTML are markup languages. JSON and YAML are not markup languages. So when they finally realized their mistake, they had to retroactively do an about-face and rename it "YAML Ain’t Markup Language". That didn't inspire my confidence or look to me like they did their research and learned the lessons (and definitions) of other previous markup and non-markup languages, to avoid repeating old mistakes. If YAML is defined by what it Ain't, instead of what it Is, then why is it so specifically obsessed with not being a Markup Language, when there are so many other more terrible kinds of languages it could focus on not being, like YATL Ain't Templating Language or YAPL Ain't Programming Language? https://en.wikipedia.org/wiki/YAML#History_and_name https://en.wikipedia.org/wiki/YAML#History_and_name >YAML (/ˈjæməl/, rhymes with camel) was first proposed by Clark Evans in 2001, who designed it together with Ingy döt Net and Oren Ben-Kiki. Originally YAML was said to mean Yet Another Markup Language, referencing its purpose as a markup language with the yet another construct, but it was then repurposed as YAML Ain't Markup Language, a recursive acronym, to distinguish its purpose as data-oriented, rather than document markup. https://en.wikipedia.org/wiki/Markup_language https://en.wikipedia.org/wiki/Markup_language >In computer text processing, a markup language is a system for annotating a document in a way that is syntactically distinguishable from the text. The idea and terminology evolved from the "marking up" of paper manuscripts (i.e., the revision instructions by editors), which is traditionally written with a red or blue pencil on authors' manuscripts. In digital media, this "blue pencil instruction text" was replaced by tags, which indicate what the parts of the document are, rather than details of how they might be shown on some display. This lets authors avoid formatting every instance of the same kind of thing redundantly (and possibly inconsistently). It also avoids the specification of fonts and dimensions which may not apply to many users (such as those with varying-size displays, impaired vision and screen-reading software).
• posharma 5y ago
  It's really sad to see the pervasiveness of JSON. For one thing its usage as a config file is disturbing. Config files need to have comments. Second, even as a data transfer format the lack of schema is even more disturbing. I really wish JSON didn't happen and now these malpractices are so widespread that it's hurting everyone.
  • benibela 5y ago
    And I am just writing a JSON de/serializer to move my config from the current system to JSON. I worked on it today and yesterday and several days some time ago. This situation makes me feel rather silly
  • umvi 5y ago
    So you prefer the "good old" XML days? I'll take comment-less JSON over XML any day (and it doesn't have to be comment-less... JSON with comments is a thing and VSCode has syntax highlighting for it - just strip out the comments before parsing).
    • posharma 5y ago
      It's simple. For config files, choose the format that has the best tooling in your company and that supports comments. For data transfer, choose that supports schemas, backwards compatibility and good tooling (protobufs is just one e.g. that I'm most familiar with).
    • deleted 5y ago
      [deleted]
    • stavros 5y ago
      > So you prefer the "good old" XML days? I'll take comment-less JSON over XML any day Aren't we past basic false dichotomies?
      • saurik 5y ago
        Nope: basic false dichotomies and JSON are both pervasive.
• shruubi 5y ago
  Looking at the comparison examples between TOML and YAML/NestedText, I fail to see how anyone can look at the YAML/NestedText and think "yeah, this is way easier to read and reason about than TOML". I'm not even a Rust person. I've never worked in Rust in my life, so there is no "preference bias" in my comparing the two. I just don't find YAML, or this "improvement" as "human-readable" as people make out to be.
  • BluSyn 5y ago
    I'm also confused. The TOML example is way easier for me to understand. It's clearly very subjective.
• throwaway984393 5y ago
  Most people that complain about YAML are like a person complaining that tennis shoes are terrible because when you try to rock climb in them, they don't have traction and you slip and fall. Tennis shoes are garbage! ..... Or maybe tennis shoes are good for what they were designed for, and you need a different kind of shoe for rock climbing. YAML is a human-readable data-serialization language. Note the word readable, and that it's for data serialization. It's not intended to be human-writeable. It's not intended to configure an application (unless that configuration is the result of serializing the data object created after someone configures the app). Since programmers don't really understand the different types/classes of file formats and what they're for, they choose the wrong formats for the wrong tasks. And then the people who are forced into using those formats for those programs find it's highly problematic - but they get pissed off at the formats and not the programmer! I'm perfectly happy for people to create new data serialization formats, new configuration formats, new markup formats. But please avoid the trap of thinking "this format or that format sucks". None of them suck for what they were created for, when used correctly. YAML, for example, has huge advantages over most common data serialization formats. But those advantages fly out the window as soon as humans start writing YAML by hand, and then bolting on weird custom logic, as if this data serialization format were a higher-level language.
• bussierem 5y ago
  As a fun overview of the problem we're discussing, here's a rough list of the various mentioned languages in this comment section: - YAML - JSON - JSONC - XML - TOML - INI - CSV - NestedText - Starlark - Python - Dhall - Cue - Jsonnet - DADL - EDN - HCL
  • culi 5y ago
    surprised JSON5 didn't show up
  • krapp 5y ago
    And Lua. I'm mentioning Lua, right now.
  • vlmutolo 5y ago
    RON (Rusty Object Notation) is another good one. The name is slightly unfortunate, since it seems applicable outside Rust projects.
• smitty1e 5y ago
  I, for one, prefer to write python that generates JSON. - All the flexibility of python, plus commenting! - json module can test or dump as a flat blob o' text or pretty-printed #ProblemSolved #OKjustMoved
• keymone 5y ago
  Just learn about EDN already.
  • kaliszad 5y ago
    We need a lot more tooling to support EDN everywhere well enough though. If you use Clojure(Script) it is absolutely natural to use EDN everywhere. (We do just that at OrgPad.com which you can see in the OrgPage about Clojure: https://www.orgpad.com/o/D6TrZny7tNhYqWygzax7Wx https://www.orgpad.com/o/D6TrZny7tNhYqWygzax7Wx and for the EDN just add download: https://www.orgpad.com/o/D6TrZny7tNhYqWygzax7Wx/download https://www.orgpad.com/o/D6TrZny7tNhYqWygzax7Wx/download) EDN is less ideal for Python and other similarly somewhat high-level languages and there just aren't any libraries for C/C++ from what I have seen. In general, XML/ JSON/ YAML/ custom binary or text formats it is in that order for most software from what I can guess. Remember, .docx, .xlsx and other document formats are also basically just XML-based configurations for programs/ interchange formats.
• transfire 5y ago
  Im sorry, But the issues raise have more to do with a particular implemention -- that is outdated -- then YAML in general. E.g. "on" should no longer be treated a true. Thats a 1.1 version archaism. And 3.10 is going to have the same issue in JSON. No doubt YAML could still be improved and maybe we'll get there eventually. 2.0 is a long discussed goal, but the creators of YAML (who I have talked to extensively) are cautious, thoughtful and methodic and won't make that jump until they are sure of it. Meanwhile 1.2 is a fairly good spec, and difficulties largely lie with implementors and users.
• endigma 5y ago
  HCL anyone? It does everything right in my experience (nomad, using it as a format for my own apps)
• bschwindHN 5y ago
  I post this pretty much every time this topic comes up: JSON5 exists, and is quite nice. I've picked it up for configs on a work project and haven't once had an issue due to misconfiguration, unexpected parsing, or friction with leaving a trailing comma or a comment. The nesting in JSON5 is simple and familiar to pretty much all programmers, unlike deep nesting in TOML which is a huge pain.
  • zkldi 5y ago
    JSON5 keeps coming up in these discussions, and I've personally had a great time with it. Hopefully some larger projects pick it up and it eventually becomes a common occurance, or something.
    • bschwindHN 5y ago
      I like it so much I got motivated enough to start making a sublime text highlighter for it. I got a bit lost though, having never made one before. And then I tried to use a tool called SBNF to write the grammar for the language at a high level and have it spit out Sublime Text syntax highlighting code. Didn't quite work yet unfortunately. https://github.com/bschwind/sublime-json5 https://github.com/bschwind/sublime-json5 https://github.com/BenjaminSchaaf/sbnf https://github.com/BenjaminSchaaf/sbnf
• andrei_says_ 5y ago
  Here’s a popular opinion: YAML, used sparingly, without too much complexity, is fine, and provides a great balance of legibility and data density. There are a few gotchas that are easy to catch with validations. The end.
  • bmn__ 5y ago
    > YAML, used sparingly, without too much complexity, is fine It's wishful thinking because the complexity is inherent, unfortunately. That's analogue to saying "programmers should not write bugs". Humans are fallible and error prone, it's not going to happen unless a language is restricted in such a way that a category of bugs is not possible by design. However, YAML's design is sprawling, so despite best intentions people will run into the problems caused by the complexity. Possible ways out are restrictions of the design (e.g. Strict YAML) or whole replacements (e.g. NestedText). > There are a few gotchas that are easy to catch with validations. Does this actually exist? If not, who's writing the code for these validations? How can we make sure everyone who needs to use them is using them? The idea sounds good on paper, but not workable in practice because "patching after the spec problems" requires global coordination.
  • imtringued 5y ago
    I use yaml as an alternative to .properties files. It's boring. Yes, quote your strings. Know the damn config language. It's not going to kill you like a table saw.
• BerislavLopac 5y ago
  I've always been wondering why is Ion so unknown... https://amzn.github.io/ion-docs/ https://amzn.github.io/ion-docs/
• fastball 5y ago
  I feel like there should be a data format that supports typing. Basically just a Typescript object where types are defined on the key somehow. Because JS/TS objects are basically JSON with a bunch of annoyances (too particular about commas, always-quoted keys, no comments) removed.
  • bmn__ 5y ago
    https://hn.algolia.com/?query=cuelang+types https://hn.algolia.com/?query=cuelang+types
• resonious 5y ago
  A lot of people have really strong opinions towards syntax things like YAML vs JSON vs XML, HTML, even programming languages. I think at some point we assign way too much importance to this kind of stuff. I recently read a piece by Joel Spolsky that resonated with me (even though my career is not nearly as long as his). > I took a few stupid years trying to be the CEO of a growing company during which I didn’t have time to code, and when I came back to web programming, after a break of about 10 years, I found Node, React, and other goodies, which are, don’t get me wrong, amazing? Really really great? But I also found that it took approximately the same amount of work to make a CRUD web app as it always has, and that there were some things (like handing a file upload, or centering) that were, shockingly, still just as randomly difficult as they were in VBScript twenty years ago. [0] It makes me wonder if we're really focusing on the right stuff. Maybe there's lower hanging fruit somewhere that's more valuable than focusing on fundamentally subjective things like syntax. [0]: https://www.joelonsoftware.com/2021/06/02/kinda-a-big-announcement/ https://www.joelonsoftware.com/2021/06/02/kinda-a-big-announ...
• didibus 5y ago
  EDN is the best I've used, I dream for it to become wildly adopted. It has powerful types, can be extended, clean explicit syntax, whitespace independent, easy for humans and machines to read. It's like JSON done right.
• fake-name 5y ago
  If your project is in python, the only correct file format to use for the config file is python. If your project is in ruby, the config file should be ruby. If you're in $SCRIPTING_LANGUAGE, your config file should be implemented in $SCRIPTING_LANGUAGE. You can use `literal_eval()` (in python, there are similar constructs in basically every scripting language) to prevent prevent people from putting code in the config, but really, it's the person writing the config file's computer, let them do what they want. For compiled languages, it's a bit harder, but there are zero cases where a separate "configuration language" should exist.
• deleted 5y ago
  [deleted]
• rolandog 5y ago
  Isn't NestedText similar to using recfiles[0]? [0]: https://www.gnu.org/software/recutils/ https://www.gnu.org/software/recutils/
• albertopv 5y ago
  I really don't know where all this XML hate comes from, it has everything I need and I don't find hard to read, maybe I'm just used to it. How often do you change your configuration files? My projects pom.xml change only occasionally, version upgrade or new dependencies, that's it.
• flohofwoe 5y ago
  YAML has problems (mainly that it requires an overly complex parser), but the alternatives presented here look like a step backward. Easier for the parser, but less flexible for the human (one nitpick with NestedText that stood out immediately: can I collapse arrays and dictionaries into a single line like in YAML with [] and {}?)
  • firearm-halter 5y ago
    yep python-version: - 3.8 - 3.9 - 3.10 can be written: python-version: [3.8, 3.9, 3.10] same is true for dictionaries.
• diob 5y ago
  What is the obsession with removing braces? I will never find the lack of clear demarcations (relying on indent) easier than braces.
  • andybak 5y ago
    Visual clutter, familiarity to non-coders. Curly braces are almost never used outside of programming and are ugly to boot. My benchmark for yaml/JSON alternatives is "how would I feel explaining it to a busy, sceptical client?" If the intended audience is purely developers, then sure. JSON (with the addition of comments and trailing commas) is just fine. White space has the additional advantage of agreeing with itself. Other demarcations can have issues where the indentation and the structure contradict each other.
    • zippergz 5y ago
      I haven't found "this needs to be indented exactly the right amount or it won't work" to be much easier for non-programmers than "this needs to be enclosed in braces or it won't work." Most people have at least experienced parentheses in math (albeit maybe decades ago), so it's not an entirely foreign concept. Either one requires a bit of learning, but I think most people are capable of it, so any improvement in non-coder familiarity seems minor at best, vs. the very real costs.
      • andybak 5y ago
        Counter-argument - why do programmers insist on clear indentation if it doesn't aid readability? The indentation is there for humans and the braces are there for the compiler.
        • mike_hock 5y ago
          That's why you have both and lint against inconsistencies. This catches errors.
    • diob 5y ago
      That's just display though, if you have to show it to a skeptical client, why not run it through a browser that shows it without braces? It's the same as showing a webpage instead of the html.
• deleted 5y ago
  [deleted]
• woodruffw 5y ago
  I'm glad to see people experimenting with alternative document/object representations, but this one might be a hard sell: based on the README[1], it only has Python, Zig and Janet implementations so far. One of the nice things about YAML (and JSON, TOML, etc.) is that they have decently mature C, C++, or Rust libraries that other languages bind to. [1]: https://github.com/KenKundert/nestedtext https://github.com/KenKundert/nestedtext
• evanmoran 5y ago
  Keeping leaf values as strings is quite elegant. I’ve found the auto conversion to be inconsistent across yaml implementations in different languages.
• Waterluvian 5y ago
  My opinion only: I love JSON because it lacks so many foot guns of yaml. If you’re doing lots of clever stuff with yaml you probably want a scripting language instead. Django using Python for configs made me fall in love with this. Spending years with the unmitigated disaster that is ROS xml launchfiles and rosparams makes me love it even more. Yaml and toml are fine if you keep it simple. JSON direly needs comments support (but of course wasn’t designed to be used as a human config file format so that’s kind of on us). And not just “Jsonc that sometimes might work in places.” Beyond that, I think we generally have all the things we need and I don’t personally think we need yet another yaml. =)
  • BugsJustFindMe 5y ago
    > Django using Python for configs made me fall in love with this. I also started advocating in-language configuration files (Python for Python, but also Lua for Lua, etc) a number of years ago because it lets you do really useful things (like functionally generating values, importing shared subsets of data, storing executable references, and ensuring that two keys return the same values without manual copy/paste) all without needing to spec and use Yet Another Thing™ that does only a fraction of what the programming language you're already using already does.
    • pjmlp 5y ago
      That is how our Tcl based application server was, the configuration files were a Tcl DSL.
    • eptcyka 5y ago
      That also implies that you can't just test a foreign config file without first reading and understanding what it does, as just using one would imply arbitrary code execution.
      • kevin_thibedeau 5y ago
        This is a place where Tcl excels. You can easily create restricted sub-interpreters that can't do anything dangerous. If you need more power for trusted scripts you just reenable selected commands.
• morelisp 5y ago
  The introduction keeps citing "no need for escaping or quoting" as a major advantage, but provides no examples of what a key with a colon, or value beginning with "[", or any datum with leading or trailing whitespace would look like. Also, the changelog is quite frightening! > [In 3.0], `[ ]` now represents a list that contains an empty string, whereas previously it represented an empty list.
  • matzf 5y ago
    This made my curious to find out. The "Language introduction" docs [1] answers these points; * keys containing leading spaces, newlines or colons can be represented with the multiline key form, where each line of the key starts with `: `. * leading or trailing space is not complicated; the string values are just the rest of the line after the separator from the key, `: `. The values are not trimmed. * a string value beginning with `[` just works in most places. This would not be confused with list values, as these would only start after a new line. Only in the compact inline list and inline dict form there are restricted characters for syntax. It seems that their claim, no escaping required, holds. The slightly more verbose form of the language constructs may be required to represent special values though. [1]: https://nestedtext.org/en/stable/basic_syntax.html https://nestedtext.org/en/stable/basic_syntax.html
• georgewfraser 5y ago
  A radically different alternative with a lot going for it is Starlark: https://github.com/bazelbuild/starlark https://github.com/bazelbuild/starlark It’s a deterministic subset of Python. This means that if you have complex or repetitive configurations, you can use loops and functions to structure them. But it’s impossible to write an infinite loop or recursion.
  • civilized 5y ago
    Not a bad idea but only implemented in Rust, Go, and Java so far. Meanwhile, all sorts of languages can interpret JSON and YAML. It's a cool idea to do configuration in a subset of Python but now you have to go implement that subset in every language.
  • remram 5y ago
    Interesting! I started using jsonnet this year, but found that the language was needlessly quirky (e.g. the `::`, purely functional aspect, and no one wants to learn a new language to write configuration in the first place). More importantly, it is extremely slow (lazy evaluation without memoization...): rendering the Kubernetes YAML of my 5-container app taking over 10 seconds... I will look into this further.
  • slowmovintarget 5y ago
    EDN [1] and Transit [2]... Elegant weapons for a more civilized system. [1] https://github.com/edn-format/edn https://github.com/edn-format/edn [2] https://github.com/cognitect/transit-format https://github.com/cognitect/transit-format
    • kaliszad 5y ago
      Really came here to search why EDN wasn't mentioned. It is used in Clojure/ ClojureScript/ hylang ... projects a lot. It is a superset of JSON, is in my opinion a lot more readable than JSON but familiar enough too. It has native sets e.g. #{1 2 "three" '("four element list with a string inside")} and keywords. Tagged elements can be used for extending e.g. with a timestamp (such as the built-in #inst) or #uuid. And it also supports comments and discards for stuff, that should be omitted in evaluation. As a sysadmin, YAML seems nice until you have actually done anything more advanced with it. See Julien Pivotto's presentation about some of its pitfalls: https://www.slideshare.net/roidelapluie/yaml-magic?next_slideshow=1 https://www.slideshare.net/roidelapluie/yaml-magic?next_slid... Btw. Jsonnet doesn't seem too bad either: https://www.youtube.com/watch?v=LiQnSZ4SOnw https://www.youtube.com/watch?v=LiQnSZ4SOnw and here some examples: https://jsonnet.org/ https://jsonnet.org/ but in my book, EDN still wins.
• Drdrdrq 5y ago
  > NestedText only supports three data types (strings, lists and dictionaries)... No numbers? Looks nice otherwise, but this seems like a very weird decision. That said, JSON with its "I might overflow your number" attitude is not much better in this regard.
  • mongol 5y ago
    Yes but I can understand the rationale. There are many numeric types and settling on some excludes use with others. If letting the application handle that, the configuration language can remain simple. His example where a version number 1.10 was round trip converted to 1.1 was enlightening.
  • firearm-halter 5y ago
    The issue with YAML is that it does not unambiguously distinguish between number/booleans and strings. JSON does, but only for numbers, booleans, and nulls. But there are many data types that need to be conveyed. For example, dates and quantities (numbers with units, such as $3.14 or 47kΩ). Such things are left to the application to interpret. Even JSON does not unambiguously distinguish between integers and reals. Even so, JSON pays for its lack of ambiguity by requiring all strings to be quoted, which adds clutter and the requirement for quoting and escaping. Thus, supporting those extra types comes at a cost. I think NestedText is unique in leaving all leaf values as strings, so it does not need quoting or escaping. Everything involves a compromise. YAML provides a lack of clutter at the cost of ambiguity. JSON is unambiguous, but comes with visual clutter. In both cases there are still lots of types they cannot handle and so must be passed on to the application. The compromise with NestedText is that it provides simplicity and a lack of clutter by not supporting any data types for leaf values other than string. Thus, all interpretation of the text is deferred to the application. But fundamentally that is the best place for it, because only the application understands the context and knows what is expected.
• zmmmmm 5y ago
  I have to say I hate the fact that I have low confidence when editing YAML that the result will be what I intend. It's kind of the number one job of such a format. And I routinely run into people using advanced features and then I have no idea at all how to safely edit it. It is interesting that it seems so difficult to pick a good tradeoff between flexibility and complexity with these kinds of languages.
• sl0w0rm 5y ago
  I'm working on my own (you can start the attack hahaha). I feel there's not many simple, generic languages that allow to write simple DSLs with embedded documentation. The self documenting part is still missing but you can take a look and say what you think. It's kind of like yaml format (a bit TOML) with schema and possibility to merge multiple files with smaller chanks of the data. With export to json and yaml. https://github.com/dadlang/dadl https://github.com/dadlang/dadl
  • MH15 5y ago
    This looks pretty cool
• lox 5y ago
  Have spent many years developing dev tools that use YAML and alternatives and I still think YAML wins because of its ubiquity relative interop with JSON. I’d pick HCL as an alternative if I was going to, as it’s been widely battle tested in Terraform.
  • encryptluks2 5y ago
    Agree, HCL resembles JSON but handles comments/nested data/etc really well.
• andrewdubinsky 5y ago
  JSON is often so hard to read I have to open a file in a formatting tool. It's also hard to tell if there's a simple missing quote or brace. Those are extra steps I don't have with YAML. For many things, JSON is great. For simple loaders, YAML gets it done quick and easy. They are functionally interoperable for the most part so I use what's best. I'd also add the author has a competing framework so maybe there's a bit of pre-existing bias.
  • initplus 5y ago
    When you miss a quote or a brace in JSON, the JSON fails to parse. When you make a similar minor mistake in YAML, you often end up with a valid but nonsensical document with completely incorrect structure. I don't want the language to be flexible enough that simple common errors go unnoticed - I WANT the parser to tell me at parse time if I screwed something up. It's a similar dynamic to dynamic/static typing.
  • zamadatix 5y ago
    I'm not sure I'd trust manually editing either in a plain text editor. YAML cares about whitespace yet will silently make most combinations valid and it also has surprising pitfalls on type interpretation if one isn't consistently on top of it when entering data. JSON has a bunch of additional characters but at least if you forget them you have a higher chance of it just telling you it's wrong when you try to use it. Thankfully it's very rare I ever have to open any config file in a text editor that isn't aware of dozens of formats so things like a missing brace are always suggested anyways and it isn't much a problem regardless of format.
• kesor 5y ago
  927
• arpa 5y ago
  XML above all!
  • Spivak 5y ago
    XML in theory is a great format for what it represents — a tree of heterogeneous typed simple key/value pairs. The problem is almost no data that people want to actually represent has this form and every way people have tried to beat XML into representing other things (i.e. lists and dicts) is kludgy is awkward.
• twobitshifter 5y ago
  I wrote a program at a corporate job where all the configuration is in Excel files. Tables are just fed into a dictionary and columns on each worksheet are predefined to hold the keys. People loved it because they know how to use excel and “text” is scary. (This is all very strange because they are just entering text in Excel, but the familiarity goes a long way)
  • bluedino 5y ago
    Same but ms access
  • foepys 5y ago
    I _recently_ suffered through a meeting where we developers were told to use the _new_ testing framework some team at our corp created. It's written in Java (we use .NET exclusively in our branch), configured via Excel sheets and Java, and exports results also as Excel sheets. Whoever thought this was a good idea in 2021 has to be braindead. But the CEO was pleased. Probably because they know Excel.
    • pjmlp 5y ago
      I give you Robot, originally created at Nokia. https://robotframework.org https://robotframework.org Back in 2006, the testing was written in HTML tables, no idea how it manage to still be around.
• Animats 5y ago
  The trouble is that people insist in writing trees using plain text editors. Trees should be written in tree editors. Then you can't get the delimiters wrong. "NestedText was inspired by YAML, but eschews its complexity. " Mandatory XKCD: https://xkcd.com/927/ https://xkcd.com/927/ Fun fact: HTML was invented because SGML was "too complicated".
  • mongol 5y ago
    What is a tree editor?
    • Animats 5y ago
      There are lots of them. Here are two: http://treeeditor.com/ http://treeeditor.com/ https://github.com/josdejong/jsoneditor/ https://github.com/josdejong/jsoneditor/
• iamleppert 5y ago
  I’ve never liked YAML. For whatever reason, it always feels like working in a mine field. It comes from the same cargo cult of people who think the problem with human machine formats is that it needs to be “clean”. Clean, of course to them means some bizarre aesthetic notion of removing as much as possible. Only it’s taken to an extreme. I wonder if the same people also think books would be better with all punctuation be removed to make it look “clean”? It’s unhealthy minimalism, causes more problems than it solves. As soon as I see a project using YAML I cringe and try to find an alternative because god knows what other poor choices the developer has made. In that sense, YAML can be considered a red herring and I’m usually right. The last project I used that adopted an overly complex and build-breaking YAML configuration syntax had other problems hiding under the covers, and in some cases couldn’t parse it’s own syntax due to YAML’s overly broad but at the same time opinionated syntax. Just say no to YAML.
  • politelemon 5y ago
    I've often heard this argument about YAML being "clean", but over time I have realized that they are conflating minimalism with cleaninless, when they are two different things. That realization is what it took for me to realize why I didn't like it. I did _not_ find it clean, I found it "messy" by virtue of the increased cognitive overhead. But it is minimal at least compared to other formats. Other formats appear cleaner to me.
  • DonHopkins 5y ago
    By its very name (and the fact that the MEANING of the name flip-flopped in mid-flight after launch) you can tell that the designers of YAML had no clue what they were doing, because originally they named it "YAML" for "Yet Another Markup Language", when it clearly was NOT a markup language. Only AFTER YAML had been around and in use for a few years did those geniuses actually realize that they had made a mistake in naming it something that it's not, and retroactively changed the name "YAML" to mean "YAML Ain't Markup Language", which was a too clever by half way of whitewashing the fact that they originally CLAIMED it was "Yet Another Markup Language", since they had no idea what a markup language actually was. I prefer to use markup languages and data definition languages that were designed by people who are situationally aware enough to know what the difference between a markup language and a data definition language is, please. Hard pass on YAML, whatever it stands for this week.
• forrestthewoods 5y ago
  Here's my dream config language: * start with JSON * add comments (obviously) * allow trailing commas (obviously) * allow left-side and right-side to be independently and explicitly typed * extensible type support (JSON's lack of u64 is absurd) For example the following are all equivalent: * "foo" : f32 = 13.37 * "bar" : f32 = "13.37" * "baz" : f32 = 0x4155eb85 : hex And extensibility to allow: * "ham" : u64 = 123456789123 I would also be inclined to allow explicit config file hierarchy by allowing: * configs can specify their base * configs can specify their child * must be acylic I've thought about implementing this myself. But I've never written a real lexer or parser. It's on my side-project TODO list.
  • amai 5y ago
    https://json5.org/ https://json5.org/ maybe?
  • heinrich5991 5y ago
    JSON has integer types/literals AFAIK, it's just that the Javascript implementation doesn't support them.
    • forrestthewoods 5y ago
      It has numeric literals. But all JSON number types are f64. Which is sufficient to represent every 32-bit integer, but it can not represent all 64-bit integers. For code that needs a 64-bit integer, which is quite a lot, you have to encode the integer in a string. Lack of 64-bit integer (either signed or unsigned) is a pretty common and well understood pain point when using JSON as an interchange format.
      • RedNifre 5y ago
        No, that's just how JavaScript reads them, because JavaScript only has float64. JSON itself allows arbitrary large decimal numbers, including uint64.
        • 5y ago
• pjmlp 5y ago
  I just stick to XML unless forced to use something else. Schema validation, code completion on IDEs, endless amount of tooling including graphical visualisation, a language for data transformation and queries, and.... wait for it... comments!
  • miffy900 5y ago
    If you're going to use XML, I would consider it mandatory to also use XSDs (W3C XML Schemas). XSDs is something I think people need to pay more attention to when dealing with XML; the type system that the W3C XSD standard lays out (when used effectively) really does relieve much of the pain that people experience with XML.
• it_does_follow 5y ago
  > YAML is considered by many to be a human friendly alternative to JSON I'm not disagreeing with the author here, but as someone old enough to remember the rise of XML as a data transmission format (and Erik Naggum's masterful rant against it[0]), it's strange because historically speaking both XML and JSON were also popularized as more "human readable". I would be curious how many HNers (and even more so newer developers outside the HN-o-sphere) have worked extensively with or even written parsers for binary (or otherwise non-human readable) file formats. Writing an MP3 metadata parser used to be a standard exercise for devs looking to level up their programming skills a bit. It personally feels weird to me that we would keep pushing for more "human readable" data formats when the world is increasingly removed from one where non-programmer humans need to read data. Keep your data in whatever format make sense and let software handle transforming it to a more readable or more efficient format depending on the needs, even if humans can't read it (they shouldn't need to!). On top of all that my experience has been that JSON leads to more atrocities than XML (while fully agreeing with all of Erik Naggum's points about that) and YAML creates even worse horrors than JSON. It seems we'll soon be approaching eldritch horrors if we continue to pursue human readable data exchange formats. 0. https://www.schnada.de/grapt/eriknaggum-xmlrant.html https://www.schnada.de/grapt/eriknaggum-xmlrant.html
  • foxfluff 5y ago
    As an embedded sw dev working on things that interface with legacy devices, I have written lots and lots of binary parsers (as well as serial, net, and ipc protocols). I've also reversed some binary formats used by games, etc. I like binary formats for things that are simple and don't change too often. However, I still love not having to waste days on studying yet another bespoke binary format & parser for things that are complex and don't work right for whatever reason. So when performance isn't a concern and you aren't working in a size-constrained environment, I do find that "human readable" formats are often worth it. As a practical example, I recently hit a bug where KiCad moved some custom footprints' pad shapes around after saving & reloading. And I quickly discovered that the footprint files are just S-expressions and relatively self-descriptive so I fixed my issue in five minutes with vim without ever needing to look at docs or code. That kind of thing is super convenient. Later I discovered that other users are likewise working around the program's limitations using a text editor or custom scripts to manipulate things KiCad won't do for you; for example, to create a repetitive pattern of components in a layout more complicated than a grid.
• thefifthsetpin 5y ago
  I don't like YAML and would like to move on, but I hope we don't move onto this. I think it's crazy that when I add a string to an inline list, I may need to convert that inline list to a list because this string needs different handling. I think it's crazy that "convert an inline list to a list" is a coherent statement, but that is the nomenclature that they chose. I don't like that a truncated document is a complete and valid document. But what is most unappealing is their whitespace handling. I couldn't even figure out how to encode a string with CR line endings. So, I downloaded their python client to see how it did it. Turns out, they couldn't figure it out either: >>> nt.loads(nt.dumps("\r"),top="str") '\n'
  • tialaramex 5y ago
    > I don't like that a truncated document is a complete and valid document. Me either. If your documents have this property you're likely to tempt people to start trying to process partial documents. When they do that, they violate Full Recognition Before Processing and likely there's a latent security bug as a result.
  • ljm 5y ago
    It would be nice if YAML wasn't horrendously abused the way it is. You have CI pipelines that let you construct DAGs to represent your builds, but you need several thousand lines of YAML and a load of custom parsing to get programming constructs in the string types, for example. And then each provider has its own way of providing those. I don't have to re-read manuals describing how to do if/else in Ruby or Java or Lisp, but as soon as yaml and some 'devops' tooling is involved, I have to constantly jump back and forth between the reference and my config. The main point being that the problem isn't the file format but the products that continue to push it, presumably because hacking stuff on top of `YAML.parse` is less effort than designing something that fits the purpose.
    • Lhiw 5y ago
      I'm pretty sure the format is the issue. I still don't know how to do arrays in yaml. Is it new line, tab to same indent or same indent + one space, do I need a dash? Does a dash make it an array or an object? It's just simply not that big of a deal to add a few quotes and braces to make everything make sense. The only real issue with Json is the lack of comments and strictness about extra commas.
• mongol 5y ago
  There was an interesting project showcased here a while ago, it was some kind of very minimal language, almost the most minimal theoretically possible, but with some interesting properties. Does anyone remember it?
  • kps 5y ago
    I can't tell whether you're making a LISP joke.
    • mongol 5y ago
      Actually not.
• avsteele 5y ago
  I'll give my opinion as someone who has to choose among JSON, XML, TOML, and YAML about two years ago for a new project. Whatever I chose had to be easy for end-users who don't know the specification to to understand later. Here were my thoughts on the options. JSON - No comments -> impossible XML - Unreadable YAML - 2nd place. Meaningful indentation also made me worried someone was going to not understand why their file didn't work. The lack of quotes around strings was frustrating. TOML - 1st place. Simpler than YAML to read & parse. It truly seems 'obvious' like the name says. I haven't encountered any situations where I wish I had more than TOML offers.
  • signal11 5y ago
    There’s properties files too, but TOML is my “format of choice” as well for a bunch of use-cases where human readability is important. More people should give it a try. Very reminiscent of old Windows INI files and Java properties.
  • mindcrime 5y ago
    I guess it's just matter of personal taste, but I don't see how XML is any more "unreadable" than any of the other options mention here.
  • speed_spread 5y ago
    TOML can't decide if it's a super INI file or a JSON cousin. You can represent the same information using two completely different representations and you can mix both styles in the same document. Manually navigating and editing values is error prone and hard to automate.
  • DethNinja 5y ago
    TOML is pretty good but it gets too verbose when you add bunch of arrays. All we need is to revise official JSON standard(ECMA 404) to include comments.
    • benatkin 5y ago
      > All we need is to revise official JSON standard(ECMA 404) to include comments. That would be a step back for GitLab CI, GitHub Actions, Kubernetes, Google App Engine, and a bunch of other projects which use YAML and seldom encounter the Norway problem. https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/
• pdimitar 5y ago
  Naive question: is it viable if we started using Lua[JIT] for configuration, like NeoVim and likely others do? Can Lua's interpreter be compiled without some "dangerous" APIs enabled (whichever those might be) and thus be made viable as an embeddable and isolated configuration engine? I'm just getting sick and tired of all the half-baked configuration formats and want to look for something that's both more flexible but still strict and unambiguous. I wonder if it's possible? As I said, naive question.
  • bmn__ 5y ago
    > Naive question: is it viable if we started using [a Turing-complete programming language] This is actually a good question. The people who are not asking and going right ahead with that plan are doing a dangerous thing. <https://www.cs.dartmouth.edu/~sergey/langsec/occupy/ https://www.cs.dartmouth.edu/~sergey/langsec/occupy/> It's not viable because a subset of people would like to have the following properties upheld: • Parsing configuration should be decidable and finish in finite time. • Parsing configuration should not be a security exploit. • I should not have to implement the Emacs runtime just to parse its configuration file. > something that's both more flexible but still strict and unambiguous. I wonder if it's possible? This really depends on what you mean by these words; I'm interested to hear your idea in detail. Meanwhile, have a look at Dhall <https://dhall-lang.org/ https://dhall-lang.org/> and the other languages mentioned in <https://news.ycombinator.com/item?id=29221643 https://news.ycombinator.com/item?id=29221643> and compare.
• nsonha 5y ago
  the boolean thing is dumb, otherwise yaml is a fine format
  • kzrdude 5y ago
    The boolean thing with "on" also is not a problem that exists in the current version of yaml.
• avidphantasm 5y ago
  eff it, let’s use XML…
• deleted 5y ago
  [deleted]
• gouggoug 5y ago
  In the first example: Do people really represent software versions as floats? 3.10 being converted to 3.1 makes sense. Use a string instead.
• jstrieb 5y ago
  One interesting demonstration of YAML's complexity relative to JSON is that YAML is almost a complete superset of JSON. This is acknowledged by the authors of the YAML spec.[0] For example, the following code translates JSON to YAML using only the Python yaml library: import yaml data = yaml.load(""" { "firstName": "John", "lastName": "Smith", "isAlive": true, "age": 27, "address": { "streetAddress": "21 2nd Street", "city": "New York", "state": "NY", "postalCode": "10021-3100" }, "phoneNumbers": [ { "type": "home", "number": "212 555-1234" }, { "type": "office", "number": "646 555-4567" }, { "type": "mobile", "number": "123 456-7890" } ], "children": [], "spouse": null } """) print(yaml.dump(data)) Prints: address: city: New York postalCode: 10021-3100 state: NY streetAddress: 21 2nd Street age: 27 children: [] firstName: John isAlive: true lastName: Smith phoneNumbers: - number: 212 555-1234 type: home - number: 646 555-4567 type: office - number: 123 456-7890 type: mobile spouse: null 0: https://yaml.org/spec/1.2.2/#12-yaml-history https://yaml.org/spec/1.2.2/#12-yaml-history
  • jborean93 5y ago
    Further to this you can even include the trailing commas and hack in comments in the yaml-like json value: import yaml data = yaml.load(""" { "firstName": "John", # Woah comments "lastName": "Smith", } """, yaml.SafeLoader) Granted I still like YAML when it sticks to the basics and avoid some of the messier aspects, like anchors, when I can.
• alphachloride 5y ago
  I think the advantages over the csv example are not quite advantages. "tall and skinny". Well it looks skinny, but in bytes is actually fatter than the csv. Similarly, for comparing stuff, the columnar display works better. My go-to is ini. Simple. Everything is a string. No assumed hierarchy in section naming. Just key/value pairs under sections. It is up to the using application to parse them how it sees fit.
• todd8 5y ago
  I was surprised the first time I saw Daniel J. Bernstein's qmail configuration. Qmail uses separate configuration files for each parameter being set. The directory /var/qmail/control contains most of these files. For example, to set the maximum message size to by 10Mb and to set the timeout to be 30 seconds: echo 10000000 > /var/qmail/control/databytes echo 30 > /var/qmail/control/timeoutsmtpd There are many more files like this that hold simple values. /var/qmail/control/locals is a file that is a list of domain names, one per line. Dictionaries are just subdirectories with one file per entry, for example this is how aliases are defined to qmail: echo fred > /var/qmail/alias/.qmail-postmaster echo fred > /var/qmail/alias/.qmail-mailer-daemon See [1] for more about qmail. DJB also created a simple, portable encoding for serializing data called netstrings, see [2]. XML, YAML, JSON, TOML, and INI files all have some advantages over netstrings, but netstrings are simple to understand and simple to parse correctly. [1] https://www.oreilly.com/library/view/qmail/1565926285/ch04.html https://www.oreilly.com/library/view/qmail/1565926285/ch04.h... [2] https://en.wikipedia.org/wiki/Netstring https://en.wikipedia.org/wiki/Netstring
  • transfire 5y ago
    I used this system myself for a project. It has some downsides, but overall it worked pretty dang well.
• inshadows 5y ago
  I like complexity of YAML. When people choose YAML as driver for their shitty tools I'm forced to use, at least I can use YAML features to cope with this braindamage. Of course, you can go only so far with e.g. anchors. Stop using configuration languages as programming languages and leave YAML alone as configuration language. If you know about dangers of unsafe YAML, why don't you just replace load() with safe_load()??
• adolph 5y ago
  Is there a yaml cli equiv to jq for json? https://stedolan.github.io/jq/ https://stedolan.github.io/jq/ Is there a syntax for specifying yaml schema like coach?
  • bmn__ 5y ago
    > Is there a yaml cli equiv to jq for json? You could have found this by searching the Web for "jq for yaml". <https://kislyuk.github.io/yq/ https://kislyuk.github.io/yq/> > yaml schema You could have found this by searching the Web for "yaml schema". <https://rx.codesimply.com/ https://rx.codesimply.com/> <https://web.archive.org/web/2021/http://www.kuwata-lab.com/kwalify/ https://web.archive.org/web/2021/http://www.kuwata-lab.com/k...> In practice, schemas designed for operating on the JSON infoset (not the serialisation) will also work.
• cpeterso 5y ago
  Yet another alternative format to JSON or YAML is Rust Object Notation (RON or RSON), which is a lot like JSON but more expressive: https://github.com/ron-rs/ron https://github.com/ron-rs/ron
• billconan 5y ago
  also don't like yaml. hjson is an obvious better choice https://hjson.github.io/ https://hjson.github.io/
• mcot2 5y ago
  What does everyone think of prototext format.
• lamontcg 5y ago
  please dog, end this plague of whitespace sensitive parsers.
• danieltanfh95 5y ago
  seriously why dont people just use EDN and move on. Rich types, proper key value pairs, keywords instead of strings everywhere, support for fractions and comments...
• paholg 5y ago
  I wish we could use [nix](https://nixery.dev/nix-1p.html https://nixery.dev/nix-1p.html) for config files. It's nice, simple, and allows variables and functions. Jsonnet has a similar feature set, but I find it nigh unreadable.
• vegai_ 5y ago
  Sure, but why move to an alternative that's almost as bad? YAML's problem is that whitespace is significant. TOML could be superior to it if it weren't for the fact that they forgot to forbid indentation. And now indented TOML is everywhere, including its wikipedia page. If we have to make a change, why not finally bite the bullet and go to the form that has existed for decades and is obviously superior to all of these formats? S-expressions. There's even been a standard for data notation brewing for some time: https://github.com/edn-format/edn https://github.com/edn-format/edn Then we can actually forego http://xkcd.com/927 http://xkcd.com/927 and do something useful with our significantly saved mental energy. edit I see that I'm not at all alone in wanting edn to replace all this crap. So some action points on how to actually make that happen, in order of preference: - write or improve robust edn parsers for your ecosystem - write or improve robust x => edn converters for your ecosystems (x=yaml,json,toml,whateverpoisontheyuserightnow) - use edn in your projects - advocate the use of edn
• throwaway192810 5y ago
  The worst config files I've ever encountered are dynamic YAML templates for Kubernetes. Mind boggling to figure out with crazy indentation rules and for loops. Kill me now. Seriously, the more time I spend with other configuration formats the more I start appreciating JSON. It is a simple array and object format. Nothing can go wrong with it. No indentation rules. Easy to encode and decode. Easy to turn into actual arrays and objects in your programming language. Lack of types is not great, but use a type checker in your parser that throws exceptions and you are fine. JSON is simple and that is why it is successful.
• LinAGKar 5y ago
  The problem with the version numbers here seems like it's because they've inappropriately written them as numbers rather than as strings, so 3.1 and 3.10 are equal. It's not the languages fault if the author chooses the wrong datatype.