> Syntactic whitespace kills me.

Okay, I'm gonna be the asshole in the room, but how hard is it to just use consistent indentation? I can't count how many times I've heard people complain about significant whitespace in languages.

Not only is it not difficult to begin with, but every code editor and IDE will show you where there's a syntax error in your YAML. People are free to dislike YAML, even for its significant whitespace, but how does it "kill you"?

Look at this example from the article:

```

something: nothing

  hello: goodbye

```

This is pure sloppiness, and anyone who has trouble carelessly adding pointless bytes to code, no matter the language, is sloppy. I don't understand why people criticize YAML and Python because "whitespace is hard".

P.S.: There's a similar configuration language called ArchieML, which is similar to YAML but doesn't have significant whitespace.

http://archieml.org

Three big things that annoy me even though I'm happily writing Python:

- "cut and paste and edit" is broken. You can't autoformat the pasted code into the right place, you have to go back and fix the whitespace. Since whitespace is semantically significant, this can introduce bugs.

- visually identical whitespace may not be textually identical whitespace. Unless you go around breaking the tab key off your colleague's keyboards you'll trip over this. Especially (again) if you paste. Occasionally seen in merges too.

- editors can no longer give you 100% correct indentation.

> - "cut and paste and edit" is broken. You can't autoformat the pasted code into the right place, you have to go back and fix the whitespace. Since whitespace is semantically significant, this can introduce bugs.

Depends on how your editor is configured / it's feature set. Which makes me wonder how editorconfig would handle this when enabled. It seems like a insignificant issue to me, you can auto-PEP8 the code before pasting it. You should probably be following PEP8 anyway (as far as spacing is concerned at least).

> - visually identical whitespace may not be textually identical whitespace. Unless you go around breaking the tab key off your colleague's keyboards you'll trip over this. Especially (again) if you paste. Occasionally seen in merges too.

I turn on show all whitespace on my editors regardless of programming language. I've been burned by Sublime Text not just figuring out the already defined whitespace ruleset for a file by what it's using and just shoving in it's own defaults. I wish all editors would base whitespace on what the file's structure looks like, if there's mixed spaces, give me a warning.

> - editors can no longer give you 100% correct indentation.

I don't understand this, it sounds like you've got your editor configured poorly or something? But it goes back to how unintuitive the nice editors can be. You can use editorconfig to define the indentation project wide, then any editor should pick it up, of course if you define PEP8 at a minimum it guarantees spacing settings.

I'm not sure if PyCharm covers a few of those cases, since I use it so seamlessly I don't usually have complaints.

I’m on the opposite end. I just had to export a JSON based AWS CodePipeline configuration and had a hell of a time trying to edit it and paste things in the right place.

I ended up converting it to yaml, making the edits and converting it back to JSON.

Before anyone asks the obvious, how do I handle deeply nested code in brackets. Simple, I don’t. When things start getting nested deeply, I use my IDE to Extract Method.

In the YAML case: It's hard if you don't have editor support and good diagnostics. Not because you're unusually sloppy, but because you make human mistakes and because you don't know the syntax. (YAML syntax is surprisingly complex and poorly documented in the pedagogic sense). Also, the edit-debug cycle is slow with Ansible or YAML-using CI systems, so this is doubly painful.

In the Python case it's much better, because people less often casually edit .py files without editor support, and because Python has good diagnostics and it's much much harder to produce syntactically correct but semantically wrong Python by whitespace mixups.

Everything is hard when you don't have editor support and good diagnostics. Don't blame YAML because you prefer to use Notepad.exe

However, missing/extra whitespace is not "hard". You would be docked points in an English paper and you should be docked points as a programmer.

So, whitespace aside... Tell me what is easier to edit without built-in syntax support: JSON, or YAML?

If we define "easy" as "how long it takes to complete a task" or "how quickly you can grok the structure of a given block of code", then YAML beats out JSON every time.

I see you restate your argument for clarity, let me try the same :)

1) YAML is a configuration file format, and it's targeting user groups and environments where people use ad hoc terminal based or os-bundled editors, such tools being nano or Notepad, and such users being sysadmins for example. 2) YAML implementations (=parsers) have poor diagnostics compared to Python, separate from the editor issue, and 3) YAML syntax is more prone than Python to parsing correctly but producing unwanted semantics when you make a mistake.

I think there is value in your English paper analogy: many/most people editing YAML files don't know YAML syntax very well compared to this scenario. If their knowledge of English was at the same level, misplaced whitespace would not be chief of their problems in a graded English paper.

It is of course a structurally valid (philosophically consistent) argument that people should not make mistakes and they should suffer when they do, but this goes generally against the consensus of configuration language usability thinking.

In my opinion no one should be using Notepad for programming work or configurations that are more than 1-2 dozen lines. Nano is about the same: It's a text editor with no inherent tooling for configuration files and syntax support.

A construction worker can't complain that nails are hard to use because they showed up to work with a baseball bat. Or that they're designed badly because they brought a soft aluminum hammer with a tiny head instead of one made with a stronger metal and large impact surface. Tooling is important. Vim and several graphical editors have syntax support. Notepad++ if you're on Windows.

> YAML syntax is more prone than Python to parsing correctly but producing unwanted semantics when you make a mistake.

If you made a mistake, you made a mistake. Why do you expect a program with a mistake to work correctly? Use tooling which prevents you from making mistakes. And the particulars of YAML semantics are orthogonal to how your editor handles it. Yes = True, No = False, etc., for better or worse, but that's got nothing to do with your editor.

> many/most people editing YAML files don't know YAML syntax very well compared to this scenario. If their knowledge of English was at the same level, misplaced whitespace would not be chief of their problems in a graded English paper.

I wholeheartedly agree. So if a programmer complained to me that they were having issues related to inconsistency with whitespace, I would be suspect of their general programming abilities and would start reading their code to determine if the problem lies deeper than just getting an extra space here or there: Incorrect tooling, linting, sloppiness, inattention to detail... All of these things get in the way of well-written software.

As for whitespace in general, and the fact that it's harder for linters to determine and highlight if a block is correctly scoped without enclosures... Python and others have this same issue.

> It is of course a structurally valid (philosophically consistent) argument that people should not make mistakes and they should suffer when they do, but this goes generally against the consensus of configuration language usability thinking.

True, and I agree. Everyone makes mistakes even with things as simple as rote data entry. This is why tooling is incredibly important.

Tightrope-walking at great heights is incredibly dangerous. Practitioners accept this danger. They typically wear harnesses to mitigate the danger of falling. Of course, some people like to live on the edge and set records involving no harnesses. If someone like Dean Potter fell while walking a tight-rope freeform with no harness and plunged to their death, their last thought wouldn't be, "Shit, I knew that tightrope was poorly designed and dangerous," it will be "Shit, I wish I'd been wearing a harness."

We can't remove our harnesses and then complain that mistakes are too frequent and costly.

Editing JSON is ok without specific format support, it just looks like any other C-like language. Editing YAML is basically impossible without specific support, your editor will almost certainly break any file you open and destroy relevant information on the process.

Care to elaborate? Your statement is hollow on its own.

How does your editor destroy information? What kind of information is destroyed? Why is your editor rearranging bits in validly encoded text files?

Most programming editors rearrange the white space of the files they open. Some do it more, some do it less.

Rearranging white space in a YAML file often destroys information.

Mine do no such thing. The only whitespace that gets stripped in /any/ editors I have are trailing whitespace and extra whitespace before the EOF, and that's only in certain IDEs where I have consciously enabled these options. They are disabled by default.

Removing trailing whitespace should never change the logic of a file in general, but as for YAML it certainly doesn't. And editors should never remove leading whitespace... who does that?

Can you name an offending editor as an example?

Press tab on a line in emacs, and the whitespace will get rearranged. It's more explicit in vi, but don't bother (un)indenting blocks there either.

Just writing characters anywhere a file on the MS IDEs I've tried is enough to rearrange the line's whitespace, while the Jetbrain's I've tried are more conservative and won't break lines you haven't changed somehow.

Ok, now show me a single editor that doesn't make whitespace changes when you press tab.

I've only ever had issues with vim messing up whitespace on the line I'm typing specifically with regard to YAML, and yes that's an issue but it has nothing to do with YAML. For example, Adding another colon to a string, wrapped in whitespace or not, will often reduce indentation. That's just plain bad behavior, but it's not intended behavior.

I largely agree with you, but:

How hard is it to use HN formatting? I can’t count how many times people screw it up.

It’s not difficult to begin with, the documentation is free, yet here I am reading your comment with broken formatting.

    something: nothing
      hello: goodbye

Anyone who has trouble with this is just being sloppy. No useless backticks! You might think you’re doing it right, but unless you check, maybe you’re not.

lol Well played.

Have a look at the CodeDeploy appspec.yml specification for whitespace [1].

  …
  [4]mode:[1]mode-specification
  [4]acls: 
  [6]-[1]acls-specification 
  [4]context:
  [6]user:[1]user-specification
  …

"AWS CodeDeploy will raise an error that might be difficult to debug if the locations and number of spaces in an AppSpec file are not correct."

Great. There couldn't possibly be an easier format to use, could there?

[1]: https://docs.aws.amazon.com/codedeploy/latest/userguide/refe...

In fairness, that documentation makes the process out to be far more complicated than it actually is in reality. Plus their point about errors being difficult to debug can be equally true with other data formats too (eg some JSON parses can throw really unhelpful errors if you accidentally include a comma at the end of list)

Please consider simply believing and trusting those who tell you they hate significant whitespace and that it is a real impediment to work.

Another take, perhaps: Assigning deep semantic significance to invisible symbols is simply stupid. It is stupid to a much greater degree than wanting to be free from having to care about the amount of invisible symbols is “sloppy”.

YAML is a generic format which leaves formatting as a result of effect to you. Ansible puts rules on top of it, which makes intendation not always trivial, it is easy to have an dangling key value pair which doesn't cause an error, but has only an effect with the right intendation.

> how hard is it to just use consistent indentation

It's pretty annoying when you don't have access to an IDE or decent editor.

YAML is a bit bonkers in that it's a superset of JSON (all valid JSON is valid YAML), so if you don't like the whitespace sensitivity, you can write your YAML like this:

  {
    a: 42,
    # But you can have comments!
    b: "hello world",
    c: "and
      multi-line
      strings!",  # and trailing commas!
  }

I wrote a pared down version of YAML because while I like the basic structure I hated the complicated bullshit like the "we also parse JSON" layered on top:

https://github.com/crdoconnor/strictyaml

Worse than JSON though, is the Norway problem.

If you remove this stuff and start validating it properly it becomes much easier to maintain.

> the Norway problem

Huh:

https://hitchdev.com/strictyaml/why/implicit-typing-removed/

I've always liked YAML, it's always seemed pretty intuitive to me coming from Python, and I like human-readable resource files, but those are some pretty damning counterexamples.

JSON.NET has an insane default "smart deserialization" mode which checks if string values are valid ISO dates, and if so, deserializes them to DateTime. The result is that your typical unsuspecting app works fine for a long time, until the user just happens to throw data at it that has a date-like string in it somewhere - and so the app code gets a DateTime instance where it expected a string.

And depending on how exactly it was accessed, this can go two ways. The best case is that the app just gets the value via the untyped API, casts it to string, and blows up with an invalid cast - best because you actually know what went wrong.

The worst case is when the app specifically tells JSON.NET that it wants a string value (via generic type parameters), at which point it will helpfully implicitly convert the actual date value back to a string... except it can reformat it, and even helpfully adjust it from one timezone to another. Semantically it's the same date, of course, but it's not at all the same string, and sometimes that matters a lot. So this is the worst case because it's just silent data corruption.

For some mysterious reason, the author believes that this is acceptable default behavior - i.e. "it's a feature, not a bug". It's especially ironic to look at all the mentions in GitHub ticket, as various projects that rely on the library run into this issue (one of them is mine):

https://github.com/JamesNK/Newtonsoft.Json/issues/862

I'll be honest, I didn't believe you at first so I went and tested some JSON against a few YAML parsers and it's completely true.

This is insane. I already knew writing a YAML unmashaller was a needlessly complicated affair - and that was before I realised this could happen.

Oh hey, a Python dictionary that throws an error. Just kidding -- faced a JSON parsing issue today and this made me smile.

It's a step up from XML though.

For me lack of validation and comments are many steps down, not up.

Lack of validation?

JSON files don't have validation support like XML schema does.

Maybe not built in like DTD, closer to XML Schema in its laid-on-top manner, but I would argue that JSON Schema is fairly good, and on its way to becoming an IETF standard: http://json-schema.org/ and https://tools.ietf.org/html/draft-handrews-json-schema-01 (et al)

The lack of obvious namespace management is suboptimal, but so far I thankfully haven't encountered a situation where it was a show-stopper.

IntelliJ and related tools also allow associating a json schema with a YAML file, which I have found infinitely handy

JSON Schema is actually pretty great.

I find YAML to be almost unusable. IMO it's just not intuitive. If I get to choose a format for my config files I would only use TOML, it's just better (again IMO).

All these comments amuse me, because I feel the opposite. YAML has always made immediate intuitive sense to me. Meanwhile TOML feels like a terrible hack.

Also, I'm guessing I'm in a tiny minority who loves YAML but hates Python's semantic indentation...

I like YAML but it has some minor quirks and it feels overused in domains in which it simply doesn't make sense to use YAML. I can think of ansible or complex dynamic configurations that depend on external values as mentioned in the article. If simple merging of a base file + dev, staging, prod files isn't enough for the task at hand then YAML is a bad fit.

I'm the same way. I think it's a difference in my expectations of a programming language versus a hierarchical data storage format. I'm fine with (and even prefer) enforced whitespace in data formats. That makes it easier to view and edit.

In programming languages, it makes me twitch. I don't have any problem with "accepted" formatting styles (i.e. linux kernel c style), but for the language itself to enforce that for some reason feels like it's adding perpetual cognitive overhead (like whenever I use python). I don't know why; it shouldn't be any different than using a particular formatting style voluntarily in a more flexible language, but somehow, it feels different.

This is strange. The thing I most like about YAML is how intuitive and human readable it is.

One thing that is rarely pointed is that one of the advantages of TOML is that it allows to write dictionaries/tables not as trees.

Agreed. From readability perspective, I started out with INI, which I ditched partially due to having no standard on the format and skipped JSON when it can't add comments, skipped YAML for not looking too intuitive, considered JSON5 but skipped for being not popular enough and landed on TOML.

And I skipped toml for an object-array syntax that makes baby Jesus cry.

None of these problems are hard, why are all the solutions so awful?

What are you using now?

XML, generally. I hate it but I've given up on its "successors".

Hocon for me, if I get to choose.

I don't mind YAML. I dislike that something things become strings and sometimes they become other types:

   foo: bar   # {"foo":"bar"}
   foo: "bar" # {"foo":"bar"}
   foo: 42    # {"foo":42}
   foo: "42"  # {"foo":"42"} 

Other than that, no major complaints. My editor understands YAML and shows the indentation level in the background (highlight-indentation-mode) and auto-formats files so they all have consistent indentation (prettier-mode). As a result, it is not much of a nightmare to edit, despite the fact that semantic whitespace COULD cause you a lot of problems.

How about...

    foo: yes  # "foo": true
    bar: YEs  # "bar": "YEs"
    baz: YES  # "baz": true

Yeah, that's a little crazy. It's the classic case of in-band signalling. It never works. I wish quotes around strings were mandatory, then having 83 ways to say "true" would be OK. But when strings randomly get upgraded to other primitive types... it's a little weird.

I like looking at YAML when it doesn't use any of the insane YAML features. Even so I'm not convinced it should be used (at least not as widely as it is) for one big reason: it can be truncated almost anywhere and still be valid. This causes way more issues than you might think. JSON has no such issue - the only case I can think of where you can truncate JSON into valid JSON is if your JSON is just a number.

The simple parts of YAML are great for simple applications. The complicated parts of YAML are not great for complicated applications.

>> I really dislike YAML

I wasn’t aware anyone liked it

I have a feeling that it is/was preferred in rails/ruby community.

Tools keep using it even where it's the wrong tool for the job, so someone must like it, surely?

I'm sure it will be just like XML where it's the trendy thing for a while in the early days, then everyone stops and hates it for a while. Except XML at least has a handful of applications where it's the right tool for the job (it has a nice streaming mode), YAML doesn't even have that.

YAML is great for simple human-editable configuration files. Its very easy to write, and can be picked up quite quickly.

Opting for YAML over XML/JSON/whatever doesn't make me a tool. It made life much easier for myself & my colleagues.

I think they meant tools like docker or npm and stuff. Not calling people tools.

heh, I didn't even consider this interpretation of the above; sorry about that. I meant "tools like Docker keep using it", not people. But I still don't know what you're talking about; YAML has an 83 page spec that includes pointers, and uses tons of random confusing symbols. I say "maybe it's just me" in some of these posts, but I know it's not: I've watched many of my coworkers get it wrong the first time for years and then have to be corrected. A quick common example I see in CI config all the time: If I write version: 1.10, that's a number, then I decide to move to latest so I write version: 1.10.x, that's a string. Oops, we were never using version "1.10" we were using "1.1". Everything about it is implicit and bad. Now, it's easy to say "always use quoted strings", and I agree, but then why the hell does it have bare strings in the first place? That seems like an easy enough oversight or typo to make, and it will be made.

I generally dislike languages like YAML or Python where whitespace matters, and can break your code, however, YAML is way more easily human readable than JSON, so I started to appreciate it for readability purposes.

I guess YMMV, but after you've used both YAML and JSON for a while, you might appreciate YAML a little bit more.

The killer feature for me over JSON is comment support, it's definitely useful to add todo comments etc.

Yep, so true. Any decent config file that will be seen/edited by a human needs comment support. And any file that will not be seen by a human could be json (or whatever).

Yeah this is a huge selling point of YAML. JSON should have comments added to the spec. The other benefit to YAML is human readability, which is usually better in YAML compared to JSON. A specific glaring example of this is when there are long string-literal snippets inside the document, in YAML this is massively more readable than in JSON.

JSON shouldn't have comments added to the spec, because people shouldn't be trying to read or write JSON. It's an application interchange language, meant to be written and read by machines. YAML is a markup language, meant to be written and read by people. Ever notice how most YAML libraries don't even have a "dump" function?

>It's an application interchange language, meant to be written and read by machines.

Not entirely true, JSON is based on Javascript objects, it was meant to be written and read by humans just like Javascript, INI or any other basic serialized data format, or text-based programming language. If JSON were truly never meant to never be viewed or edited by human beings, it would have been published as bytecode.

>> Ever notice how most YAML libraries don't even have a "dump" function?

No. I guess unless you’re using something half-baked, I suppose. Machines need to be able to edit configs either way.

Hum... We have a bad historic of success in deciding that this or that stuff is for machine consumption only.

> JSON should have comments added to the spec.

See also ~5 years ago: https://news.ycombinator.com/item?id=7325735

You can just use JSON with comments though. If you have sufficient control over the technology in question to be able to completely change it to a YAML parser, surely you can change it to be a JSON+Comment parser too. See: VS Code's config files.

But you can restrict yourself to JSON+Comments and call it YAML; it isn't idiomatic YAML, but it's still valid YAML.

> You can just use JSON with comments though.

Then it's not valid JSON, and if you try to treat it as such bad things will happen.

My point is that if you're in sufficient control of the stack to be able to convert the whole thing over to YAML, you could just as easily convert the whole thing over to JSON+Comments. And of course bad things would happen if you treat JSON+Comments as JSON, but similar bad things would happen if you treat YAML as JSON, so I don't see your point. It's not like people are trying to send their tsconfig's on the wire as "application/json" and expecting arbitrary parsers to support it.

When you think about it, JSON lacks so much (check JSON5 for what it's lacking), it's hard to believe even a comment is not allowed when pretty much anything else allows, which is a showstopper by itself.

> YAML is way more easily human readable than JSON, so I started to appreciate it for readability purposes.

> I guess YMMV, but after you've used both YAML and JSON for a while, you might appreciate YAML a little bit more.

I've used JSON a lot, and XML and s-expressions and MessagePack and ini and YAML and a whole bunch of other formats.

I usually have to fire up Google to read YAML. YAML is the only one where I routinely have to Google for a syntax cheatsheet and wade through tables of redundancy and edge-cases.

YAML made sense before JSON became a thing. Why people persist with it in new projects is baffling to me.

a raw YAML file is readable with your eyes. A Json file needs to be prettified before you go thru it. Json is good for APIs but is not made for readibility.

We must disagree with what "readable" means then. I find JSON readable (as long as it's nicely layed out, e.g. by piping through 'jq "."'), in the sense that I can skim over the structure looking for [/]/{/}/". If I want to read some of the content, like a string, I just need to read '\"' as '"' and '\\' as '\', which is a small constant cost per (usually rare) occurrence.

With YAML it's difficult to even know the structure of what I'm looking at, due to anchors and extensions. It's also hard to discern structure from skimming, since strings can appear unquoted, and may contain unescaped lexical tokens (depending on which particular symbols it started with); hence we must carefully consider each and every character, rather than just skimming for the next token.

If I know I'm looking at a perfect YAML file, than I should be able to guess the gist of what it says, since I can make assumptions about what the syntax means. If I want to be sure, I'd be Googling for cheatsheets. Yet as a programmer, I mostly look at files when they're buggy, meaning I can't just assume that, say, an unescaped quotation mark won't terminate the string; or that a certain piece of text is allowed to run across multiple lines; or that the indentation corresponds to the nesting; etc.

That's what syntax highlighting is for.

I use notepad++ for YAML. Besides coloring what it thinks I'm thinking, it displays vertical lines corresponding to the indentation levels.

(I prefer INI/TOML whenever I can help it; hierarchies in TOML are so counterintuitive that it incentivizes a simple flat structure. But then, some things are irremediably hierarchical)

Is it really though? The implicit typecasting gives rise to very unexpected results, that you'd never get with JSON. See: https://hitchdev.com/strictyaml/why/implicit-typing-removed/

Have you considered alternatives like TOML or JSON5?

Writing YAML is easily the part I hate most about writing/deploying software. It's unstructured, feedback cycles tend to be slow (e.g. when deploying k8s configs into prod), and you can't possibly write something useful without documentation pulled up. It's definitely easier to implement than purpose built DSLs, but it's not a good experience.

Python has better IDE support and, maybe more importantly, python does not completely disallow any indentation style so it handles unsupported IDEs better. But it's essentially an IDE support problem.

My life improved a lot since I got an YAML mode for emacs. Now things would be just perfect if haskell's cabal migrated to dhall...

I know you only said Python is better, not great, but you might want to check out OpsMop: https://medium.com/@michaeldehaan/opsmop-building-the-next-g... . By the creator of Ansible, in pure Python, including the config.

Is there a reason http://opsmop.io/ and http://vespene.io/ are both down and their Github's both say "DISCONTINUED"?

https://github.com/opsmop/opsmop

https://github.com/vespene-io/vespene

Michael DeHaan threw his toys out of the pram because he wasn’t getting the user numbers he wanted and discontinued them

Looks like it happened a few days ago: https://threadreaderapp.com/thread/1091710068234641408.html

> In this case, lots of discussions show everyone is busy, has no time, and also ... increasingly they have interest in low-code/no-code type solutions. This is not open source as whole, just the IT ops vertical

Looks like he doesn’t believe the code approach is viable as much as other people are claiming in this thread.

I... No. The OpsMop Twitter has a tweet from January 31, so it seems like if the project had died it would have to be really recent. That would be sad.

YAML is useless because it replaces JSON (tree structure that is minimally verbose to not be confusing) with something worse (a tree structure that is just less verbose than JSON to be slightly confusing)