4 ms·

> YAML is to config syntaxes what Python is to programming languages. Seriously, significant whitespaces? That's his critique of YAML? That it is too pythonic?

> YAML is to config syntaxes what Python is to programming languages. Seriously, significant whitespaces? That's his critique of YAML? That it is too pythonic? You're not getting far in convincing people of something being bad, if your top argument is "It is like python".

franga2000 6y ago
It sounds like they dislike the fact that indentation matters. I see a lot of people who get mad about that in Python and YAML has the added annoyance of not allowing tabs. Personally, I love both Python and YAML for this exact reason (among others). Explaining a hierarchical system using indentation to an average person isn't too difficult, but even very smart non-tech people will get confused by explicitly opened and closed blocks (if-endif or { }). Without proper indentation, the code is unreadable anyway, so why not actually take advantage of that and get rid of the bracket soup that means nothing to you anyways.
- tasogare 6y ago
  It’s not the concept of indentation that’s the problem, it’s the implementation. Tabs vs space, smart editors, auto-linters all make it easier or more difficult depending on the situation, which created insecurities by constantly breaking expectations. In case of code, the fact there is not visible difference (most of the time) between tabs and space make it quite easy for bugs to creep in.
  - unionpivo 6y ago
    that's why it's spaces only. If you mix you are asking for trouble, and if you allow to be configured, half will pick one the other will pick other. So the only sane choice is to just pick one and enforce it. And by now most of the editors have python rules baled in, so it's not big problem in practice. By python standard one level is exactly 4 spaces
    - thechao 6y ago
      Right. Also, for those language designers trying to figure out if the right white space is 'tab' or 'space', just do a quick DDG for 'tab' and 'Makefile'. The answer is space.
      - franga2000 6y ago
        Are your referring to the fact that Make requires tabs to indent blocks of commands? It's not even whitespace in that case - Makefile treats the character as a prefix. Sounds like it would be even worse if it required 4 spaces... I actually see Make's use of tabs a great example of why they make more sense for indentation, especially when it matters. 1 \t => +1 level of indentation. No guessing the number of spaces and praying it stays consistent throughout the file.
        thechao 6y ago
        I don't disagree with you from a language-designer point-of-view: it's an elegant, indentation-agnostic solution. The problem is that after explaining -- for the 50 gajillionth time -- that "it's a tab, not X spaces", I get a little frustrated.
- deleted 6y ago
  [deleted]
ziotom78 6y ago
I was skeptical too of this sentence, but then I realized that I have never used YAML for files that were more than ~200 lines long. What happens for huge configuration files with lots of sub-trees? (Comparison with indent-based program programming languages like Python and Haskell is not completely appropriate, because one typically avoids too many nesting levels when writing code. But in a large YAML file you might just need to go deep.)
- piaste 6y ago
  YAML anchors allow a basic level of reorganization and DRY within your file, not unlike functions in code. I'm sure that some people will scoff and point to anchors as exactly the kind of complexity a configuration format shouldn't have. But I've personally found them extremely useful and straightforward.
- chinigo 6y ago
  I'm working with a 12k-line YML file with lots of sub-trees right now, and let me tell you, it's a gigantic pain in the butt. If it were JSON, I could navigate within a subtree by selecting & searching the text between the `{}` delimiters. But instead, I have to gently scroll downwards, keeping a careful eye on the indentation, to see whether I've moved into the adjacent subtree.
  - SahAssar 6y ago
    A 12kLOC YML sounds like it's always going to be a pain in the butt, but the specific problem you mention should be solvable by any editor that can collapse blocks, right? Most editors I've used (vscode, vim, phpstorm, intellij, even notepad++) have that feature built in or supplied by a pretty standard plugin.
    - chinigo 6y ago
      Yeah code folding works for the visual scrub, but it's the "search within" feature that's missing. An example of my common use case is digging through a Bosh manifest file for a resource with a particular name, then finding, say, the VM type associated with that resource. The name and vm_type fields may be separated by hundreds of lines (it's a machine-generated file that does not retain element order), but they're siblings of each other. In vim, I could land on the first { and then hit: v% (extend selection to matching delimiter) /\%Vvmtype: (to search for "vmtype:" within the selection). In IntelliJ I could similarly extend a selection between delimiters and then search within it. It's absolutely correct that this is a tooling problem. You could imagine a YML plugin for IntelliJ or vim smart enough to offer a motion for "select all the children of this block," but AFAICT no such tool exists.
flohofwoe 6y ago
A valid criticism of YAML is that it requires a very complex parser compared to XML or JSON. E.g. there's plenty of JSON and XML parsers to choose from for each language, but either none or only one YAML parser, and those add a non-trivial complexity to projects. (XML and JSON are in the same bucket for me, both are simple to create and simple to parse, YAML on the other hand...)
- cpuguy83 6y ago
  How is xml simple to parse? It is difficult for both humans and machines. Just because there are libraries doesn't mean it is simple. It's a minefield, with security implications. To be fair... so is yaml.
bishalb 6y ago
That's a pretty valid criticism. I am wary of significant whitespaces too as are many people(and one of the reasons I use Ruby for scripting rather than python.)
Xelbair 6y ago
Yes it is. Especially after you tried configuring an application which has pages-long comments with commented out examples that are misaligned to indentation, and an app takes few minutes to show you an config error. It is completely impractical - it looks nice - but we aren't writing for YAML for non-technical users, we are writing it for machines and other technical users. I seriously wonder why TOML isn't popular.
- IshKebab 6y ago
  I think YAML is popular because it has a non-noisy way of including multi-line strings, which are very common in CI /DevOps type things (where YAML is most popular). All of the other features and insanities of YAML don't really matter compared to that. TOML is good, but it quickly gets confusing when you have object hierarchies / nested tables. I feel like json5 is probably the best option at this point.
MaxBarraclough 6y ago
That stood out to me too. A good article, but a bit unwise to include a dig at the Python language. At the very least we can all agree it's a very successful language. Beyond that, it's the kind of thing people have strong feelings on. If you want to make the case against a major programming language, that should be done in an article of its own.
thinkharderdev 6y ago
Agree that invoking Python is probably counter-productive but I think the basic point is correct. I've banged my head against the wall many times trying to figure out which line in my 500 line YAML document is not indented correctly. Bonus point when Helm generates an invalid YAML document but because it is interpreted, the line number spit out by the parser is not a line number in your actual source template.
- cageface 6y ago
  Significant white space is one of those ideas that’s very appealing in small examples and demos but falls apart in production. I was a big proponent of it myself until I saw it cause some very subtle production bugs. Now I’m more than happy to endure a little extra typing in order to be able to defer code formatting in complete confidence to prettier.
  - acdha 6y ago
    This highlights the importance of implementation: this is not a problem in Python because the language prevents those subtle inconsistencies whereas YAML tries too hard to accept anything and has a lot of magic syntax which makes it hard for tools to determine intent.
    - cageface 6y ago
      It's less of a problem in Python but it still exists. A lot of the day to day work of programming is moving and refactoring chunks of code around. Having to pay careful attention to white space the whole time makes this a lot more tedious and error prone than it is in languages without this feature.
      - acdha 6y ago
        Having spent the last couple decades writing Python professionally, it definitely happens but it’s rare outside of people using Notepad. The major programmers editors have been able to adjust indentation on paste for many, many years and, unlike YAML, that will get an immediate syntax error rather than parsing to something unexpected.
Lio 6y ago
Saying YAML is too pythonic when really you're talking about a file format used by other languages too is a bit cheesy but I get the criticism. Semantic white space (originally called "The Offside Rule") predates Python. I believe it was originally invented by Peter J. Landin[1], and yes the name is a joke about football. The main problem for me is that it makes copy and paste more difficult. You can't just let the editor reformat for you and you have to be more careful with what you comment out. Python devs seem to live with that OK though (I'm told) so maybe it's not such a big deal. 1. https://en.wikipedia.org/wiki/Off-side_rule https://en.wikipedia.org/wiki/Off-side_rule
- SiempreViernes 6y ago
  > The main problem for me is that it makes copy and paste more difficult. Heh, that makes for a good snark for dismissing the white space complaint, it's all from copy-paste programmers! (Or is more properly black space for all you darkmode lovers) > [...] you have to be more careful with what you comment out. Not sure if I get what you mean? I think python lacking proper multi-line comments (making things you want to ignore a multi-line string isn't as neat) is an irritant, but I don't get how semantic white space impacts the complexity of commenting?
- collyw 6y ago
  I didn't like Pythons whitespace when I first started using it after years of Perl and Java. Then after maybe 6 months I went back to writing some Perl code. I moved some blocks of code around, then got the dreaded missing brace problem where they didn't match up and I couldn't which brace wasn't matching up. I realized that I never encountered that problem in Python. That was enough to convince me of the benefits.
- zaphar 6y ago
  Python has the advantage that it is easier to control the level of indentation by breaking things out into functions without compromising the readability of the code. YAML sort of allows you to do the same using anchors but I find it doesn't help readability as much and sometimes hinders it. I think this might be because in yaml you are describing a data structure and it's far easier to understand that data structure if you can see the whole thing at once. In python you are describing code and for some reason in my head functions as an abstraction in code make it more not less readable.

franga2000 6y ago

It sounds like they dislike the fact that indentation matters. I see a lot of people who get mad about that in Python and YAML has the added annoyance of not allowing tabs. Personally, I love both Python and YAML for this exact reason (among others). Explaining a hierarchical system using indentation to an average person isn't too difficult, but even very smart non-tech people will get confused by explicitly opened and closed blocks (if-endif or { }). Without proper indentation, the code is unreadable anyway, so why not actually take advantage of that and get rid of the bracket soup that means nothing to you anyways.

tasogare 6y ago
It’s not the concept of indentation that’s the problem, it’s the implementation. Tabs vs space, smart editors, auto-linters all make it easier or more difficult depending on the situation, which created insecurities by constantly breaking expectations. In case of code, the fact there is not visible difference (most of the time) between tabs and space make it quite easy for bugs to creep in.
- unionpivo 6y ago
  that's why it's spaces only. If you mix you are asking for trouble, and if you allow to be configured, half will pick one the other will pick other. So the only sane choice is to just pick one and enforce it. And by now most of the editors have python rules baled in, so it's not big problem in practice. By python standard one level is exactly 4 spaces
  - thechao 6y ago
    Right. Also, for those language designers trying to figure out if the right white space is 'tab' or 'space', just do a quick DDG for 'tab' and 'Makefile'. The answer is space.
    - franga2000 6y ago
      Are your referring to the fact that Make requires tabs to indent blocks of commands? It's not even whitespace in that case - Makefile treats the character as a prefix. Sounds like it would be even worse if it required 4 spaces... I actually see Make's use of tabs a great example of why they make more sense for indentation, especially when it matters. 1 \t => +1 level of indentation. No guessing the number of spaces and praying it stays consistent throughout the file.
      - thechao 6y ago
        I don't disagree with you from a language-designer point-of-view: it's an elegant, indentation-agnostic solution. The problem is that after explaining -- for the 50 gajillionth time -- that "it's a tab, not X spaces", I get a little frustrated.
deleted 6y ago
[deleted]

ziotom78 6y ago

I was skeptical too of this sentence, but then I realized that I have never used YAML for files that were more than ~200 lines long. What happens for huge configuration files with lots of sub-trees? (Comparison with indent-based program programming languages like Python and Haskell is not completely appropriate, because one typically avoids too many nesting levels when writing code. But in a large YAML file you might just need to go deep.)

piaste 6y ago
YAML anchors allow a basic level of reorganization and DRY within your file, not unlike functions in code. I'm sure that some people will scoff and point to anchors as exactly the kind of complexity a configuration format shouldn't have. But I've personally found them extremely useful and straightforward.
chinigo 6y ago
I'm working with a 12k-line YML file with lots of sub-trees right now, and let me tell you, it's a gigantic pain in the butt. If it were JSON, I could navigate within a subtree by selecting & searching the text between the `{}` delimiters. But instead, I have to gently scroll downwards, keeping a careful eye on the indentation, to see whether I've moved into the adjacent subtree.
- SahAssar 6y ago
  A 12kLOC YML sounds like it's always going to be a pain in the butt, but the specific problem you mention should be solvable by any editor that can collapse blocks, right? Most editors I've used (vscode, vim, phpstorm, intellij, even notepad++) have that feature built in or supplied by a pretty standard plugin.
  - chinigo 6y ago
    Yeah code folding works for the visual scrub, but it's the "search within" feature that's missing. An example of my common use case is digging through a Bosh manifest file for a resource with a particular name, then finding, say, the VM type associated with that resource. The name and vm_type fields may be separated by hundreds of lines (it's a machine-generated file that does not retain element order), but they're siblings of each other. In vim, I could land on the first { and then hit: v% (extend selection to matching delimiter) /\%Vvmtype: (to search for "vmtype:" within the selection). In IntelliJ I could similarly extend a selection between delimiters and then search within it. It's absolutely correct that this is a tooling problem. You could imagine a YML plugin for IntelliJ or vim smart enough to offer a motion for "select all the children of this block," but AFAICT no such tool exists.

flohofwoe 6y ago

A valid criticism of YAML is that it requires a very complex parser compared to XML or JSON. E.g. there's plenty of JSON and XML parsers to choose from for each language, but either none or only one YAML parser, and those add a non-trivial complexity to projects. (XML and JSON are in the same bucket for me, both are simple to create and simple to parse, YAML on the other hand...)

cpuguy83 6y ago
How is xml simple to parse? It is difficult for both humans and machines. Just because there are libraries doesn't mean it is simple. It's a minefield, with security implications. To be fair... so is yaml.

bishalb 6y ago

That's a pretty valid criticism. I am wary of significant whitespaces too as are many people(and one of the reasons I use Ruby for scripting rather than python.)

Xelbair 6y ago

Yes it is. Especially after you tried configuring an application which has pages-long comments with commented out examples that are misaligned to indentation, and an app takes few minutes to show you an config error. It is completely impractical - it looks nice - but we aren't writing for YAML for non-technical users, we are writing it for machines and other technical users. I seriously wonder why TOML isn't popular.

IshKebab 6y ago
I think YAML is popular because it has a non-noisy way of including multi-line strings, which are very common in CI /DevOps type things (where YAML is most popular). All of the other features and insanities of YAML don't really matter compared to that. TOML is good, but it quickly gets confusing when you have object hierarchies / nested tables. I feel like json5 is probably the best option at this point.

MaxBarraclough 6y ago

That stood out to me too. A good article, but a bit unwise to include a dig at the Python language. At the very least we can all agree it's a very successful language. Beyond that, it's the kind of thing people have strong feelings on. If you want to make the case against a major programming language, that should be done in an article of its own.

thinkharderdev 6y ago

Agree that invoking Python is probably counter-productive but I think the basic point is correct. I've banged my head against the wall many times trying to figure out which line in my 500 line YAML document is not indented correctly. Bonus point when Helm generates an invalid YAML document but because it is interpreted, the line number spit out by the parser is not a line number in your actual source template.

cageface 6y ago
Significant white space is one of those ideas that’s very appealing in small examples and demos but falls apart in production. I was a big proponent of it myself until I saw it cause some very subtle production bugs. Now I’m more than happy to endure a little extra typing in order to be able to defer code formatting in complete confidence to prettier.
- acdha 6y ago
  This highlights the importance of implementation: this is not a problem in Python because the language prevents those subtle inconsistencies whereas YAML tries too hard to accept anything and has a lot of magic syntax which makes it hard for tools to determine intent.
  - cageface 6y ago
    It's less of a problem in Python but it still exists. A lot of the day to day work of programming is moving and refactoring chunks of code around. Having to pay careful attention to white space the whole time makes this a lot more tedious and error prone than it is in languages without this feature.
    - acdha 6y ago
      Having spent the last couple decades writing Python professionally, it definitely happens but it’s rare outside of people using Notepad. The major programmers editors have been able to adjust indentation on paste for many, many years and, unlike YAML, that will get an immediate syntax error rather than parsing to something unexpected.

Lio 6y ago

Saying YAML is too pythonic when really you're talking about a file format used by other languages too is a bit cheesy but I get the criticism. Semantic white space (originally called "The Offside Rule") predates Python. I believe it was originally invented by Peter J. Landin[1], and yes the name is a joke about football. The main problem for me is that it makes copy and paste more difficult. You can't just let the editor reformat for you and you have to be more careful with what you comment out. Python devs seem to live with that OK though (I'm told) so maybe it's not such a big deal. 1. https://en.wikipedia.org/wiki/Off-side_rule https://en.wikipedia.org/wiki/Off-side_rule

SiempreViernes 6y ago
> The main problem for me is that it makes copy and paste more difficult. Heh, that makes for a good snark for dismissing the white space complaint, it's all from copy-paste programmers! (Or is more properly black space for all you darkmode lovers) > [...] you have to be more careful with what you comment out. Not sure if I get what you mean? I think python lacking proper multi-line comments (making things you want to ignore a multi-line string isn't as neat) is an irritant, but I don't get how semantic white space impacts the complexity of commenting?
collyw 6y ago
I didn't like Pythons whitespace when I first started using it after years of Perl and Java. Then after maybe 6 months I went back to writing some Perl code. I moved some blocks of code around, then got the dreaded missing brace problem where they didn't match up and I couldn't which brace wasn't matching up. I realized that I never encountered that problem in Python. That was enough to convince me of the benefits.
zaphar 6y ago
Python has the advantage that it is easier to control the level of indentation by breaking things out into functions without compromising the readability of the code. YAML sort of allows you to do the same using anchors but I find it doesn't help readability as much and sometimes hinders it. I think this might be because in yaml you are describing a data structure and it's far easier to understand that data structure if you can see the whole thing at once. In python you are describing code and for some reason in my head functions as an abstraction in code make it more not less readable.