TRUTH!
Or, expressed in YAML 1.1 [1]
y
Y
yes
Yes
YES
true
True
TRUE
on
On
ON
trueI 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.
For example `x: 3` would be equivalent to `"x": 3` in JSON, but `x:: 3` is equivalent to `"x": [3]`
(One could question how human friendly it is to call lists and dicts "vectors" though...)
props:: mime_type: "text/html", encoding: "gzip" # Inline dict. props: mime_type: "text/html", encoding: "gzip" # Inline dict.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.
I think it’s a neat improvement.
> 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!
But why double the character instead of picking another one... plenty of other non-alphanumeric characters to chose from.
Or restrictions like "only one space allowed after : before a value"
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....
Can someone explain to me what is so horrible about curly braces that we need to implement a whole host of "human-oriented" configuration languages with nontrivial parsing just to get around them?
s/JSON/YAML/g
s/curly braces/whitespace/g
bmn__•2h ago
Term not found.
xpe•2h ago