you are viewing a single comment's thread
view the rest of the comments
[–] 48 points 6 months ago (28 children)

I like this. I also like yaml, I've had very few issues with it and it's nicer to work with than json.

Json's lack of support for trailing commas and comments makes it very annoying for everyday use.

  • source
  • hideshow 28 child comments
  • [–] 61 points 6 months ago (23 children)

    Significant white-space is bullshit and i will die on this hill.

  • source
  • parent
  • hideshow 23 child comments
  • [–] 20 points 6 months ago (4 children)

    Is there space left on the hill? I want to join you.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 25 points 6 months ago (3 children)

    I hear there's significant space left

  • source
  • parent
  • hideshow 3 child comments
  • [–] -2 points 6 months ago (12 children)
  • [–] 3 points 6 months ago (2 children)

    Because yaml is not a programming language, and debugging why your whatever you're configuring isn't working correctly can be a nightmare. It doesn't tell you you missed an indent on a block, it just assumes it should be there and changes the meaning.

    Braces are visually clear.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 6 months ago (1 child)

    I think YAML has its fair share of design flaws, but I don't think significant indentation is one of them. It may not be a programming language (which may be debatable), but there are plenty that use syntactic whitespace.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 6 months ago

    It's not debatable... You linked to a programming language that uses yaml syntax, that didn't make yaml itself a programming language... It's not.

    And I know there are plenty that use syntactic whitespace, and I hate that about all of them. Literally my only real frustration with python is due to the time of my life wasted debugging perfectly fine logic that fails because a few lines had incorrect indentation.

  • source
  • parent
  • [–] 2 points 6 months ago* (8 children)

    Because I am not counting white space when I read. Or should we just write machine code/assembler/pick something straight away?

  • source
  • parent
  • hideshow 8 child comments
  • [–] 1 point 6 months ago* (last edited 6 months ago) (7 children)

    Not sure I'm following the jump from significant whitespace to machine code. How are those related?

  • source
  • parent
  • hideshow 7 child comments
  • [–] 2 points 6 months ago* (6 children)

    Human and machine read differently. If you ignore that (in case with indentation), then why bother with writing human-friendly form of code, when what is going to be really executed is something else?

  • source
  • parent
  • hideshow 6 child comments
  • [–] 1 point 6 months ago (5 children)

    If anything, that sounds like an argument in favor of significant indentation, not against it. Humans and machines read differently, yes, which is why we tend to add whitespace and indentation to code even for programming languages where it's not significant. We do that expressly because it makes the code more human-friendly, so it's quite the opposite of ignoring their differences.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 1 point 6 months ago (4 children)

    No, it is an argument against it. We indent code so that it is more comfortable to read it, not in order to make it easier to understand

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 6 months ago (3 children)

    You're mistaken:

    Indentation is a secondary notation that is often intended to lower cognitive load for a programmer to understand the structure of the code.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 6 months ago (2 children)

    Lol. Go on, show me how it is easier to understand structure of the code when I am 3 levels down, first two are already out of sight

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 6 months ago (3 children)

    Just the other day I had a list show up as ["a", "b", "c", "d", "e", false, "g", "h", "i"].

    The issue was that, without me being overly aware of it, the data was going through a data -> yaml -> data step.

    Yes, the data -> yaml filter was broken for not putting general strings in quotes. But IMO the yaml design invites these odd "rare" bugs.

    I used to like yaml, but was happy to see Toml taking the niche of human-readable-JSON, but felt the format for nested key-value was a weird choice. However, I've always felt we could just have extended JSON a bit (allow line breaks, comments, if the outermost data type is an object, the curly brackets may be omitted).

  • source
  • parent
  • hideshow 3 child comments
  • [–] 3 points 6 months ago* (1 child)

    Using YAML as an intermediate format between steps of a process is a mistake. I love YAML for configuration but I’d never use it for machine-to-machine anything. If the tool you’re feeding data to requires YAML as input, just give it JSON. All JSON is valid YAML.

    Edit: I realize you weren’t the one who made that decision. I’m saying the problem isn’t YAML, the problem is someone using YAML inappropriately.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 6 months ago*

    I completely agree with the general assessment, but then there are always pesky exceptions. In this case the list entered a JavaScript frontend from the yaml header of machine generated content pages for the website framework Hugo. And, of course, after finding the bug, it is clear that things could have been done differently and the issue easily avoided, but I also don't think this was a completely unreasonable design. Since Hugo actually supports JSON headers (not just via the yaml parser, but thanks for that tip!), that was a quick fix. But I'm also somewhat amazed that it was possible for the strung-together fairly standard set of Python libraries (primarily pyyaml) to not get the strings properly quoted.

  • source
  • parent