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.