This is the main reason why YAML and Python are bad. Give us CLEAR beginnings and ends to code statements and blocks, not these dubious beginnings and ends. Ignore white space and use clear EOL delineation. Clearly, XML and JSON are superior to YAML and even this weird-looking HUML. Not to mention almost any other language syntax being superior to Python.
I have actually practically tried out a test where I give a huge config file in XML and then JSON and ask folks question on its structure.
The ones who read the XML file understood immediately. Why ? Because XML is self-documenting and the repetition via clear de-limitation extensively aids human memory.
The one who read the JSON file just glazed over it and needed to refer back to the document and re-read several times.
I urge all the XML naysayers and XML haters to please carry out this practical test with their colleagues. Please choose a good level of complexity and nesting and please make use of XML attributes for scalar values.
XML is SO FAR ahead in readability and grokking that it is not funny.
Exactly. And with a proper color scheme it is so much easier to "parse" a document as a human.
But JSON popularity is linkend to the web and javascript so not much that can be done.
Coming up with new ambiguous markups just for config files is just a waste.
I really don't get it; the whole point of computing is to make stuff rigorous and precise so that you don't have to run a whole guesstimate translation layer as you need to with humans.
There are plenty of times in Python and YAML I cannot visually figure out where some block ends.
JSON prevents this by explicitly closing lists and dicts. Though you do end up with Ladders to Heaven of `}`'s and `]`'s where you have no goddamn clue what is actually being closed out.
XML prevents this by explictly stating what element was just closed. Deeply nested XML, provided the elements don't have some 300 character set of attributes all jammed into the opening element, is vastly easier to read than YAML.
> There are plenty of times in Python and YAML I cannot visually figure out where some block ends.
I might understand this objection for YAML, but for python, it's very clear: a block ends whenever the content on the next line is indented by four fewer spaces. (And lists and dicts are explicitly closed with brackets)
If you're talking about matching block starts to ends, then that's just as bad in json, if not worse; without an editor that does brace coloring, it's almost impossible to eyeball which brace goes to which block without indenting (which is the whole point of significant whitespace).
> Deeply nested XML, provided the elements don't have some 300 character set of attributes all jammed into the opening element, is vastly easier to read than YAML.
Not really. More often than not, tags are visual noise that make it harder to scan for the actual content.
I have to read a lot of deeply nested XML for part of my job, and I wrote a parser to display it as YAML precisely because it's more readable. If your data is so convoluted that you need xml tags to make sense of it, that's usually a sign you need to either refactor it, or provide a proper display tool.
> There are plenty of times in Python and YAML I cannot visually figure out where some block ends.
To match the start of a Python block (with possibly other blocks nested within it) to its end: start at the (non-whitespace) column where the opening line begins, and go straight down until you find another line that starts in that column (or EOF).
You can also just... not nest so deeply, or write so long. My functions rarely have more than ten lines are are usually not even inside classes; and I don't generally need more than three levels of indentation (that gets you, for example, a test within a loop within a function — which might well be better done with a comprehension anyway).
> XML prevents this by explictly stating what element was just closed.
Only for elements that cannot, even indirectly, contain other elements of the same element name. And for this limited safeguard, you double up every element name even in cases where it would otherwise be completely clear (which contributes to visual noise as the sibling comment points out). Of course, XML is designed for things that inherently need to be deeply nested. Your code usually doesn't.
Way back in like 2012-2013 I was putting together workflows in ESRI ArcGIS.
The options for scripting were either VBScript or Python. Python was the better choice (AFAIR the UI would show what you were doing in it as python, which made it easy to take a manual flow you developed and automate.)
However, the editor window for scripts in the UI, used the default windows dialog font configured for the user. [0] I wound up having to put together a workflow where I'd have to copy-paste back and forth from a text editor, which was fairly unproductive.
[0] - No, changing the dialog font to fixed width was not a great solution, because then other apps suddenly had terrible UX due to their design....
