Once you can't reliably read or edit the source, you lose the original reason to use plain text -- binary representations tend to be smaller, after you've given up on the idea of hand-editing or interepreting by eye.
This, by the way, is a defect shared by Python source code, one of the few drawbacks to a very productive language. In Python, if a single space gets removed from a source file, the consequences can be severe and difficult to either detect or correct.
The other side of this is that in syntaxes which have some other hierarchical delimiter (such as curly braces), it is quite a common mistake for a human to see one thing, and for the computer to interpret another.
In such a syntax, if a single semicolon or curly brace is missing or misplaced, the consequences can be severe and difficult to either detect or correct.
At least with whitespace, what you see is what the computer also sees.
Yes, but in the case of explicit delimiters, the situation can be resolved fully and automatically by counting delimiters -- either there are an equal number of delimiters (i.e. N('{') - N('}') == 0) or there aren't. The computer can be relied on to discover this simple relationship and raise an alarm, one that puts the error before the programmer in unambiguous form.
By contrast, in Python, in many cases the program compiles, runs, and produces a different result than if the error were not present. The program is syntactically correct in both forms, but its meaning has changed. In the Python case, the program may have a different meaning, and produce a different result, than the human intended without an alarm being raised.
> At least with whitespace, what you see is what the computer also sees.
Depending on what you mean by "see", not necessarily so. The programmer may intend something that that program, as written, cannot produce, because of an ambiguity related to the lack of formal delimiters, an ambiguity that causes the computer to understand the program differently than the human, and produce results that the human didn't intend.
All this apart from the nightmare produced by mixing tabs and spaces in the same source file. This may seem an unrelated issue at first glance, but mixing tabs and spaces in a language that uses explicit delimiters is just bad practice, but in Python (and in YAML) it can be a very serious problem. It's why Google's published syntax guidelines forbid use of tabs.
When tabs are used, two standard tabs produce a 16-character-space indentation and two syntactic indentations. When spaces are used, two spaces produce two character-space indentations and one syntactic indentation (by Google's standards, i.e. two-space indentations). Unless the programmer is using an editor that prevents insertion of tabs into the source, this is an accident waiting to happen -- but only in the case that whitespace is syntactically significant.
Further (entertaining) reading:
You seem to focusing on one set, and ignoring the other.
I find it instructive that you weren't able to think of an example.
"For real"? I write Python constantly. Speaking from a purely statistical and probabilistic standpoint, it's very likely that I've written more Python code than you have. And I don't have whitespace issues in my own code. But by reading the Web I find that it's a problem for many.
Find an example where some student's C or C++ program fails because, as the following examples proclaim, the source file contains a mixture of tabs and spaces.
True in a sense, but false in a more important one. JSON removes the syntactic dependence on whitespace -- one can parse JSON unambiguously while ignoring the whitespace that separates sections, relying only on explicit delimiters:
{"menu": {
"id": "file",
"value": "File",
"popup": {
"menuitem": [
{"value": "New", "onclick": "CreateNewDoc()"},
{"value": "Open", "onclick": "OpenDoc()"},
{"value": "Close", "onclick": "CloseDoc()"}
]
}
}}
This makes JSON a superset of YAML, not a subset. JSON has properties that YAML doesn't, properties that remove the ambiguity in YAML's syntax, properties that answer my original objection.> so if you want to use a more well defined format, you can.
Indeed, I agree. It's true because JSON corrects the primary defect in YAML. YAML was originally designed to be terse and human-readable and -editable, but at the cost of syntactic ambiguity when scanned. JSON solves the problem by reintroducing the delimiters that YAML removed.