Can someone explain to me what is so horrible about curly braces that we need a whole host of "human-friendly" configuration languages with nontrivial parsing just to get around them?
JSON 5 is pretty good. It just needs to make the top-level brace and all commas optional, and add proper support for multi-line strings (writing '/n/' at the end of every line doesn't count).
Allowing only valid JavaScript identifiers to be unescaped keys is also a bit quirky (You have to quote reserved keywords).
But they will never change any of that because it would break JavaScript compatibility.
Well in that case, it's all the ways that IDEs like to jank up whitespace, as well as the additional difficulty knowing 'context'.
With JSON it's fairly easy for me to know if I want to end my structure as well as the structure containing it, I can just type }}, and add the next element.
With whitespace you have to keep track of HOW MUCH whitespace, and trust me once you've got people who are entirely inconsistent with how much whitespace they use it becomes a huge PITA.
We are stuck in the old paradigm of characters taking space on the screen and the idea that a markup language must support classic dumb TUI. If, just imagine it, we used some Unicode range for control characters for the semantic markup and standardized UX for it, we wouldn’t need using normal characters as delimiters and escaping them in strings.
The following would have parseable structure, but would be free of visual noise.
Title: Markup languages: decades of going in the wrong direction
Keywords: hypertext,
delimiters,
ˋ, ", \
People have suggested using the control characters for CSV structured files. The problem is that they are impossible to edit.
Control characters are invisible, using them means changing text editors to display them. They are also, outside the usual ones, hard to type. ASCII ones have Ctrl combos, but editors used those for other things.
Also, what is the difference between using some new character to start block and "{" or "\n"? Why have new thing to indicate new level when have space and tab?
> Control characters are invisible, using them means changing text editors to display them. They are also, outside the usual ones, hard to type. ASCII ones have Ctrl combos, but editors used those for other things.
Yes. Change of paradigm does require change of tooling. If some legacy tool doesn’t support new format, it’s not a good reason not to use new technology - either tool evolves or a replacement emerges and typing won’t be a problem. Classic formatting commands from rich text (Ctrl-B etc) can be repurposed, for example.
>Also, what is the difference between using some new character to start block and "{" or "\n"?
Any such delimiter has other use in text. Dual use means extra ceremony with escaping and extra complexity. Whitespace as a delimiter has especially bad UX, because most editors don’t understand the semantics and it is very to make mistakes.
This case is much rarer than escaping quotes or whitespace. It will happen only if the content of the block will contain unsanitized inputs. In such case a control character for escaping will help, or, if you can have 2x range for control characters, you can use one bit for escaping. E.g. 0x1-0x7 - delimiters, 0x8-0xF - escaped delimiters.
Markup languages should support TUI / plain terminal, because many people still use that as their IDE. If I can’t pipe a file around to standard *nix tooling, it’s not a good format.
You can pipe a file with unicode control characters. If your terminal supports Unicode (it must), it can even display those control characters (e.g. as small curly braces) or choose another form of presenting the text. Markup languages do not have to support every legacy terminal - all new tech requires users to upgrade at some point.
Not fashionable enough.
In all seriousness XML is so much more powerful and no need for a parser with infinite edge case.
Editing is just fine with the proper editor/IDE.
But there is a religion around plaint text and minimal editors so whatever...
I can see someone wanting the Markdown of markup languages: more convenient for people to read and write. Sure, without markdown you could write HTML, say. But editing Markdown is a nicer experience.
Honestly, nothing. Except the endless debate on where the braces go, and how long they're allowed to stay on a single line.
It seems trivial, but replacing scope delimiters with a per-line signifier (i.e. indent) makes the scope of each line self-contained and sidesteps that discussion.
Is that worth YAYAML (Yet another YAML)? I don't know. But I certainly get the desire to skip the discussion :)
I couldn't help but notice almost immediately one feature that is not human oriented, but most likely exists because it's easier for a machine to parse: single (":") vs double colon ("::"). This is not human-friendly. A human wants to write "key" "is" "value", and YAML has for a very long time supported a single ":" for "is" regardless of the actual type of the value.
I shouldn't have to care about what the type of the value is when writing out effectively YAML. This double-colon feature will do nothing but lead to bug reports from people confused as to why their document is invalid.
The comment above gives explanations defending subjective preferences about what "human oriented" means. That's fine as long as you remember that is what is happening: justification of subjective preferences. Other people can reasonably (or unreasonably) have different subjective preferences.
Also notice what the commenter above haven't done (yet, maybe they will?): done a full "forest level" comparison of all the trade-offs between the current HUML specification and ... what is your alternative proposal, exactly?
Based on my experience, I would guess that most people who design a language (and written a parser for it) for the first time will: (1) be surprised at how quickly design decisions snowball and lead to unexpected places; (ii) discover just how entangled design choices really are; (iii) will give up on trying to please everyone.
In my view, a language designer does really well to describe one's motivations, goals, tradeoffs, decisions, and then live with what you make, because... (a) making something real and useful is rad and (b) any language you make will probably have some weird stank you can't seem to get rid of.
The original designers of YAML explicitly declared in its name "Yet Another Markup Language" that it was designed to be a markup language, which it most certainly was not. Eventually somebody finally pointed out the mistake, and they sheepishly retronymed it "YAML Ain't Markup Language".
On the other hand, and to your points, Relax/NG (both its XML and simplified syntaxes) is a beautiful successful example of wisely and collaboratively designing a new clean powerful system with the deep understanding of what a markup language really is (James Clark was deeply involved with many SGML and XML standards and implementations), and full cognizance of the strengths and weaknesses of other systems you're trying to replace (SGML DTDs, XML Schemas, TREX, RELAX, XDuce, and other experimental XML schema languages).
>In computing, RELAX NG (REgular LAnguage for XML Next Generation) is a schema language for XML—a RELAX NG schema specifies a pattern for the structure and content of an XML document. A RELAX NG schema is itself an XML document but RELAX NG also offers a popular compact, non-XML syntax.[1] Compared to other XML schema languages RELAX NG is considered relatively simple.
Abstract:
RELAX NG is a new schema language for XML. This paper discusses various aspects of the design of RELAX NG including the treatment of attributes, datatyping, mixed content, unordered content namespaces, cross-references and modularity. [...]
>Composability
>RELAX NG is designed to be highly composable. A schema language (or indeed a programming language) provides a number of atomic objects and a number of methods of composition. The methods of composition can be used to combine atomic objects into compound objects which can in turn be composed into further compound objects. The composability of the language is the degree to which the various methods of composition can be applied uniformly to all the various objects of the language, both atomic and compound. For example, RELAX NG provides a choice element that can be applied uniformly to elements, attributes, datatypes and enumerated values. This is not mere syntactic overloading. The choice element has a single uniform semantic in all these cases and can have a single implementation. Another example is the grammar element, which is the container for definitions. The grammar element is just another pattern and can be composed in just the same way as other patterns. Composability improves ease of learning and ease of use. Composability also tends to improve the ratio between complexity and power: for a given amount of complexity, a more composable language will be more powerful than a less composable one. [...]
>XML syntax
RELAX NG uses XML instance syntax to express schemas. Although this makes for a rather verbose schema language, it has some major advantages. Since a user of an XML schema language must necessarily already learn XML instance syntax, using XML instance syntax for the schema language reduces the learning burden on a schema user. It also allows XML tools and technologies to be applied to the schema. For example, a schema can be used to specify the syntax of the schema language. Another important benefit of XML syntax is extensibility. RELAX NG has an open syntax that allows the RELAX NG defined elements and attributes to be annotated with elements and attributes from other namespaces. RELAX NG DTD Compatibility [12] uses this annotation mechanism to extend RELAX NG with a mechanism for declaring default values for attributes. RelaxNGCC [23] uses this annotation mechanism to allow users to embed Java code in RELAX NG schemas, which gets executed as an XML document is parsed against the schema. An unofficial non-XML syntax for RELAX NG has also been developed [8]. The non-XML syntax can be used for authoring RELAX NG schemas by hand and can then be transformed into the standard RELAX NG XML syntax for interchange. [...]
For me, it’s clearer with a double colon. Not intuitive, but extremely easy to get used to. When I see the first colon introduce a list, I have to go out of my way to not see the other colons as introducing lists.
I think we should have a name for the often undue examination and analysis of colon/semicolon usage in machine languages. I volunteer the name "colonoscopy."
Your point is funny but if you're not anal-retentive about the syntax you get monstrosity such as the CSV-escape rule instead of the passwd-escape rule..
In my theory of "human-readability", odd double tokens like :: can exist successfully so long as there is sufficient utility and logic in the single token :
Tokens are inseparable from human instincts of single = less, double = more and the corresponding emotions: single=less=easier=quicker, double=more=complicated=longer=difficult
If you are not emphasizing the single token as them most common, it's going to cause confusion.
> Especially since representing a dict already has 2 ways,
And lists.
> Pythonic
Pythonic in the way that Python's 'There should be one...' is expressed through the existence of tuples, named tuples, dataclasses, regular classes and attrs (not part of the standard library but it seems to be as much of a goto as requests is)? ;)
Slightly off-topic, but I find the text of that anchor fragment amusing ("why? just why?") and a little disappointing. Automatic CMSs have robbed us of attention to detail - that anchor (for "Why `::`?") should probably be changed to `why-double-colon`.
LSP is the only thing that matters to me, regardless of the language I’m evaluating.
Weeks of my life have been reclaimed thanks to TypeScripts LSP.
All configuration languages suck in Monaco, so much so that I would rather use C# or TS to generate a config with docs in the tooltips, red squiggles under my typos, and location-aware autocomplete.
If the goal is to look similar to YAML and fix its problems and assert itself as something that's needed in a world with YAML, the introduction should probably explicitly call out some clear differences.
Oh lord. We already have TOML, which is an improvement on limited JSON when a human-readable, easily-diffable, more flexible format is needed.
We don't even need HCL (offers little value), YAML (has too many features making it inherently less secure), XML (is a mess with too many features and too much verbosity), or INI (insufficient features) except for existing and historical reasons.
In cases where a single file is attempted to be managed by multiple, competing interests, it's probably better to split the file into multiple, modular/include files like *.d/* so there would be less chances for merge conflicts.
And then there's /{proc,sys}-like configuration with one "value" per file where the path forms the heirarchy.
Please. Just. Stop reinventing wheels that were already round enough.
`::` is quite strange. 1) It only allows to resolve nesting conflicts for a single level. 2) Could be hard to read and could lead to reasoning mistakes. 3) Looks like an attempt to differentiate HUML from YAML somehow.
I do appreciate that they lead with the examples. They convey 90% of the important information. TBH, having worked with yaml just enough to get by with k8s deployments, I could immediately spot how this would be an improvement.
Yeah, I don't disagree. I'd go further and say the examples are on-point for a "human oriented" language. But the formal spec reveals how simple or complicated this language is. (And I'm also writing this from the perspective of someone who uses a programming language that does not have a HOML implementation).
Data only for JSON, it lacks just like everything else as a configuration language. Arguments against I have seen are too verbose, too strict, and no comments. I am sure there are more.
Reminder: you can use indentation to encode s-expressions. The result is very easy to parse and easy to read provided the underlying data structures are not insane.
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....
Some context, this was launched at IndiaFOSS[0] yesterday
25 minute talk at https://www.youtube.com/live/AUrPdOZNsX8?feature=shared&t=13... (starts 3h:52)
The talk proposal is at https://fossunited.org/c/indiafoss/2025/cfp/arsnhack6n
And it primarily tries to avoid YAML horrors : https://noyaml.com/ and https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr....
[0]: https://fossunited.org/indiafoss/2025
JSON5 allows comments.
Can someone explain to me what is so horrible about curly braces that we need a whole host of "human-friendly" configuration languages with nontrivial parsing just to get around them?
JSON 5 is pretty good. It just needs to make the top-level brace and all commas optional, and add proper support for multi-line strings (writing '/n/' at the end of every line doesn't count).
Allowing only valid JavaScript identifiers to be unescaped keys is also a bit quirky (You have to quote reserved keywords).
But they will never change any of that because it would break JavaScript compatibility.
Well in that case, it's all the ways that IDEs like to jank up whitespace, as well as the additional difficulty knowing 'context'.
With JSON it's fairly easy for me to know if I want to end my structure as well as the structure containing it, I can just type }}, and add the next element.
With whitespace you have to keep track of HOW MUCH whitespace, and trust me once you've got people who are entirely inconsistent with how much whitespace they use it becomes a huge PITA.
We are stuck in the old paradigm of characters taking space on the screen and the idea that a markup language must support classic dumb TUI. If, just imagine it, we used some Unicode range for control characters for the semantic markup and standardized UX for it, we wouldn’t need using normal characters as delimiters and escaping them in strings.
The following would have parseable structure, but would be free of visual noise.
People have suggested using the control characters for CSV structured files. The problem is that they are impossible to edit.
Control characters are invisible, using them means changing text editors to display them. They are also, outside the usual ones, hard to type. ASCII ones have Ctrl combos, but editors used those for other things.
Also, what is the difference between using some new character to start block and "{" or "\n"? Why have new thing to indicate new level when have space and tab?
> Control characters are invisible, using them means changing text editors to display them. They are also, outside the usual ones, hard to type. ASCII ones have Ctrl combos, but editors used those for other things.
Yes. Change of paradigm does require change of tooling. If some legacy tool doesn’t support new format, it’s not a good reason not to use new technology - either tool evolves or a replacement emerges and typing won’t be a problem. Classic formatting commands from rich text (Ctrl-B etc) can be repurposed, for example.
>Also, what is the difference between using some new character to start block and "{" or "\n"?
Any such delimiter has other use in text. Dual use means extra ceremony with escaping and extra complexity. Whitespace as a delimiter has especially bad UX, because most editors don’t understand the semantics and it is very to make mistakes.
> Dual use means extra ceremony with escaping
It depends, if you allow nesting you also need escaping.
Escaping of what?
Of 'yourself', if a text field contain embedded/nested text you need to escape the delimiter.
This case is much rarer than escaping quotes or whitespace. It will happen only if the content of the block will contain unsanitized inputs. In such case a control character for escaping will help, or, if you can have 2x range for control characters, you can use one bit for escaping. E.g. 0x1-0x7 - delimiters, 0x8-0xF - escaped delimiters.
ASCII has 4 delimiter characters: file, group, record, and unit.
They are not used in editors that I have ever seen.
They are theoretically accessible as ctrl-/, ctrl-], ctrl-^, ctrl_
Editors absolutely should be able to show them using syntax highlighting.
There are 3 more: 001, 002 and 003
Probably most of the first 32 can be repurposed.
Markup languages should support TUI / plain terminal, because many people still use that as their IDE. If I can’t pipe a file around to standard *nix tooling, it’s not a good format.
You can pipe a file with unicode control characters. If your terminal supports Unicode (it must), it can even display those control characters (e.g. as small curly braces) or choose another form of presenting the text. Markup languages do not have to support every legacy terminal - all new tech requires users to upgrade at some point.
Don't ask me, I don't even know what was so bad about XML tags.
Not fashionable enough. In all seriousness XML is so much more powerful and no need for a parser with infinite edge case. Editing is just fine with the proper editor/IDE. But there is a religion around plaint text and minimal editors so whatever...
Probably the verbosity, necessity of a schema for typing, and mixing of text with tags as siblings.
And having to add both opening and closing tags.
This should be perfectly valid:
< date="today" id="978"/>
I could have used this many times.
Yes, that's a large part of the verbosity I was mentioning.
I can see someone wanting the Markdown of markup languages: more convenient for people to read and write. Sure, without markdown you could write HTML, say. But editing Markdown is a nicer experience.
I prefer curly braces. My editor has all sorts of comments to jump between opening and closing curly braces. This is not possible with whitespace.
Honestly, nothing. Except the endless debate on where the braces go, and how long they're allowed to stay on a single line.
It seems trivial, but replacing scope delimiters with a per-line signifier (i.e. indent) makes the scope of each line self-contained and sidesteps that discussion.
Is that worth YAYAML (Yet another YAML)? I don't know. But I certainly get the desire to skip the discussion :)
But it can't be minified without keeping the line endings and whitespace, unlike JSON.
You don't need to convince me. The question was "why would people want this", not "why are they wrong to want it" :)
I couldn't help but notice almost immediately one feature that is not human oriented, but most likely exists because it's easier for a machine to parse: single (":") vs double colon ("::"). This is not human-friendly. A human wants to write "key" "is" "value", and YAML has for a very long time supported a single ":" for "is" regardless of the actual type of the value.
I shouldn't have to care about what the type of the value is when writing out effectively YAML. This double-colon feature will do nothing but lead to bug reports from people confused as to why their document is invalid.
The comment above gives explanations defending subjective preferences about what "human oriented" means. That's fine as long as you remember that is what is happening: justification of subjective preferences. Other people can reasonably (or unreasonably) have different subjective preferences.
Also notice what the commenter above haven't done (yet, maybe they will?): done a full "forest level" comparison of all the trade-offs between the current HUML specification and ... what is your alternative proposal, exactly?
Based on my experience, I would guess that most people who design a language (and written a parser for it) for the first time will: (1) be surprised at how quickly design decisions snowball and lead to unexpected places; (ii) discover just how entangled design choices really are; (iii) will give up on trying to please everyone.
In my view, a language designer does really well to describe one's motivations, goals, tradeoffs, decisions, and then live with what you make, because... (a) making something real and useful is rad and (b) any language you make will probably have some weird stank you can't seem to get rid of.
The original designers of YAML explicitly declared in its name "Yet Another Markup Language" that it was designed to be a markup language, which it most certainly was not. Eventually somebody finally pointed out the mistake, and they sheepishly retronymed it "YAML Ain't Markup Language".
https://stackoverflow.com/questions/6968366/if-yaml-aint-mar...
On the other hand, and to your points, Relax/NG (both its XML and simplified syntaxes) is a beautiful successful example of wisely and collaboratively designing a new clean powerful system with the deep understanding of what a markup language really is (James Clark was deeply involved with many SGML and XML standards and implementations), and full cognizance of the strengths and weaknesses of other systems you're trying to replace (SGML DTDs, XML Schemas, TREX, RELAX, XDuce, and other experimental XML schema languages).
https://en.wikipedia.org/wiki/RELAX_NG
>In computing, RELAX NG (REgular LAnguage for XML Next Generation) is a schema language for XML—a RELAX NG schema specifies a pattern for the structure and content of an XML document. A RELAX NG schema is itself an XML document but RELAX NG also offers a popular compact, non-XML syntax.[1] Compared to other XML schema languages RELAX NG is considered relatively simple.
RELAX NG Compact Syntax
https://www.oasis-open.org/committees/relax-ng/compact-20021...
https://relaxng.org/jclark/design.html
The Design of RELAX NG
James Clark (jjc@thaiopensource.com)
Abstract: RELAX NG is a new schema language for XML. This paper discusses various aspects of the design of RELAX NG including the treatment of attributes, datatyping, mixed content, unordered content namespaces, cross-references and modularity. [...]
>Composability
>RELAX NG is designed to be highly composable. A schema language (or indeed a programming language) provides a number of atomic objects and a number of methods of composition. The methods of composition can be used to combine atomic objects into compound objects which can in turn be composed into further compound objects. The composability of the language is the degree to which the various methods of composition can be applied uniformly to all the various objects of the language, both atomic and compound. For example, RELAX NG provides a choice element that can be applied uniformly to elements, attributes, datatypes and enumerated values. This is not mere syntactic overloading. The choice element has a single uniform semantic in all these cases and can have a single implementation. Another example is the grammar element, which is the container for definitions. The grammar element is just another pattern and can be composed in just the same way as other patterns. Composability improves ease of learning and ease of use. Composability also tends to improve the ratio between complexity and power: for a given amount of complexity, a more composable language will be more powerful than a less composable one. [...]
>XML syntax
RELAX NG uses XML instance syntax to express schemas. Although this makes for a rather verbose schema language, it has some major advantages. Since a user of an XML schema language must necessarily already learn XML instance syntax, using XML instance syntax for the schema language reduces the learning burden on a schema user. It also allows XML tools and technologies to be applied to the schema. For example, a schema can be used to specify the syntax of the schema language. Another important benefit of XML syntax is extensibility. RELAX NG has an open syntax that allows the RELAX NG defined elements and attributes to be annotated with elements and attributes from other namespaces. RELAX NG DTD Compatibility [12] uses this annotation mechanism to extend RELAX NG with a mechanism for declaring default values for attributes. RelaxNGCC [23] uses this annotation mechanism to allow users to embed Java code in RELAX NG schemas, which gets executed as an XML document is parsed against the schema. An unofficial non-XML syntax for RELAX NG has also been developed [8]. The non-XML syntax can be used for authoring RELAX NG schemas by hand and can then be transformed into the standard RELAX NG XML syntax for interchange. [...]
I find this very human-friendly: "[double colon] permits vectors to be defined inline without additional syntax such as [ ... ] or { ... }."
(One could question how human friendly it is to call lists and dicts "vectors" though...)
https://huml.io/specifications/v0-1-0/#why
It's especially clear in the "inline dict" example. I really like it!
But that's not done for human readability, that's done for machine parsing? A human would understand just as well:
My mind has a feeling that this might be possible interpretation:
(Even if not legal, to be sure, I must backtrack and concentrate on this particular piece)There are many different humans. I definitely like the idea to separate “:: vs :”.
For me, it’s clearer with a double colon. Not intuitive, but extremely easy to get used to. When I see the first colon introduce a list, I have to go out of my way to not see the other colons as introducing lists.
I think we should have a name for the often undue examination and analysis of colon/semicolon usage in machine languages. I volunteer the name "colonoscopy."
And the obsession with inserting colons into things (and vice-verse) should be called "colonialism".
Your point is funny but if you're not anal-retentive about the syntax you get monstrosity such as the CSV-escape rule instead of the passwd-escape rule..
The double-colon is probably a necessity to disambiguate a scalar from an inline list that only has one scalar.
For example `x: 3` would be equivalent to `"x": 3` in JSON, but `x:: 3` is equivalent to `"x": [3]`
A trailing comma would also solve this, but is equally awkward. A clear list delimiter would work for both machines and humans.
Maybe author of huml will read: I would prefer mandatory braces for inline stuff. “X:: 3” feels like a trick question.
In my theory of "human-readability", odd double tokens like :: can exist successfully so long as there is sufficient utility and logic in the single token :
Tokens are inseparable from human instincts of single = less, double = more and the corresponding emotions: single=less=easier=quicker, double=more=complicated=longer=difficult
If you are not emphasizing the single token as them most common, it's going to cause confusion.
I found that example to be humerous, but specifically compared to the goals:
> Provide as few ways as possible—preferably one—of representing something.
Very Pythonic. Especially since representing a dict already has 2 ways, on the first page!
> Especially since representing a dict already has 2 ways,
And lists.
> Pythonic
Pythonic in the way that Python's 'There should be one...' is expressed through the existence of tuples, named tuples, dataclasses, regular classes and attrs (not part of the standard library but it seems to be as much of a goto as requests is)? ;)
You forgot to split out collections.namedtuple and typing.NamedTuple.
I love Python to death, but will readily admit that in no way is there “one obvious way” to do things.
Also see string concatenation.
Maybe the plural of "is" is "are" :)
But why double the character instead of picking another one... plenty of other non-alphanumeric characters to chose from.
Language design often involves subjective tradeoffs. The author gives their rationale here: https://huml.io/specifications/v0-1-0/#why
Slightly off-topic, but I find the text of that anchor fragment amusing ("why? just why?") and a little disappointing. Automatic CMSs have robbed us of attention to detail - that anchor (for "Why `::`?") should probably be changed to `why-double-colon`.
There would at least be some ambiguity with single-value lists otherwise:
If
was a list, what would be?You could have it like in Python tuples where 1 is a scalar and 1, is a tuple.
True, but I think that wouldn't be any more intuitive or error safe than the :: syntax.
Error safe, the : or :: I kind of doubt it, I think that finding a typing mistake (two : instead of 1) won't be easy..
The clear distinction between scalars and vectors appears to be the main advancement HUML offers.
I think it’s a neat improvement.
The buttstock of a rifle, trigger and other operating details are "human oriented" and the muzzle end is also frequently "human oriented".
Not sure which one we have here.
Thanks for the chuckle.
"Human readability and editability above all else" would not chose significant whitespace for a markup language. IMO.
Or restrictions like "only one space allowed after : before a value"
On the contrary, such strictness makes it easy to lint / auto-format HUML.
That's for computers, though, not humans.
LSP is the only thing that matters to me, regardless of the language I’m evaluating.
Weeks of my life have been reclaimed thanks to TypeScripts LSP.
All configuration languages suck in Monaco, so much so that I would rather use C# or TS to generate a config with docs in the tooltips, red squiggles under my typos, and location-aware autocomplete.
If the goal is to look similar to YAML and fix its problems and assert itself as something that's needed in a world with YAML, the introduction should probably explicitly call out some clear differences.
> Provide as few ways as possible—preferably one—of representing something.
TRUTH!
Or, expressed in YAML 1.1 [1]
As expressed in YAML 1.2 [2]:Oh lord. We already have TOML, which is an improvement on limited JSON when a human-readable, easily-diffable, more flexible format is needed.
We don't even need HCL (offers little value), YAML (has too many features making it inherently less secure), XML (is a mess with too many features and too much verbosity), or INI (insufficient features) except for existing and historical reasons.
In cases where a single file is attempted to be managed by multiple, competing interests, it's probably better to split the file into multiple, modular/include files like *.d/* so there would be less chances for merge conflicts.
And then there's /{proc,sys}-like configuration with one "value" per file where the path forms the heirarchy.
Please. Just. Stop reinventing wheels that were already round enough.
Off topic: Hard part of the wheel was not the round shape, but the axle. (That part actually was improved great many times)
Modern bearings are fascinating and have definitely improved a lot !
I was googling for the repo, and it looks like this project has a name collision with an 11-year-old, 3-star repo: https://github.com/shelling/huml
`::` is quite strange. 1) It only allows to resolve nesting conflicts for a single level. 2) Could be hard to read and could lead to reasoning mistakes. 3) Looks like an attempt to differentiate HUML from YAML somehow.
I like the idea of using `::` to denote a vector value.
My only pet peeve: can we define decimals as dec128 rather then float64 in configuration files?
For something like this I would love to see a formal spec to go along with the examples.
I do appreciate that they lead with the examples. They convey 90% of the important information. TBH, having worked with yaml just enough to get by with k8s deployments, I could immediately spot how this would be an improvement.
Yeah, I don't disagree. I'd go further and say the examples are on-point for a "human oriented" language. But the formal spec reveals how simple or complicated this language is. (And I'm also writing this from the perspective of someone who uses a programming language that does not have a HOML implementation).
ctrl+f grammar
Term not found.
Me like teh grammarz 2. Plays 4 author someday could put at https://github.com/huml-lang then it slay
Strictly 2 spaces for indentation? What's human about that.
Oh good, another even more confusing YAML alternative that still offers less functionality, flexibility and readability than JSON.
You could say the same thing about JSON compared to XML.
Data only for JSON, it lacks just like everything else as a configuration language. Arguments against I have seen are too verbose, too strict, and no comments. I am sure there are more.
It's not more verbose than this markup; strictness is only necessary for disambiguation; and comments are part of JSON5.
yeah, the 15th standard.. https://xkcd.com/927/ :)
XKCD predicting the future so well! :)
It's like YAML and MD had a baby
Wasn't this solved by yaml 1.2?
Reminder: you can use indentation to encode s-expressions. The result is very easy to parse and easy to read provided the underlying data structures are not insane.
https://srfi.schemers.org/srfi-49/srfi-49.html
I don’t hate this nearly as much as I hate YAML. Now get everyone else to adopt it - good luck.
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.
I think it's a preference? I find both Python and YAML to give clear beginnings and ends using whitespace, and you can also see it visually.
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).
Or you use an editor (or plugin) that just knows how to do this, just as you would with the balanced brackets. cf. https://vi.stackexchange.com/questions/7262 .
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.
https://en.wikipedia.org/wiki/Turing_(programming_language) tried the same idea. It didn't catch on.
That has never been a problem with Python, ever.
Story time!
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....
Posting a link to the XKCD comic would be a cliche at this point, yes?
Why not just use YAML?
Because of the reasons presented in the actual article that was posted by op...