Human-Oriented Markup Language
14 comments
·September 22, 2025jameskilton
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.
jampekka
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...)
sippeangelo
It's especially clear in the "inline dict" example. I really like it!
props:: mime_type: "text/html", encoding: "gzip" # Inline dict.Sohcahtoa82
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]`
xpe
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.
vczf
The clear distinction between scalars and vectors appears to be the main advancement HUML offers.
I think it’s a neat improvement.
xpe
Language design often involves subjective tradeoffs. The author gives their rationale here: https://huml.io/specifications/v0-1-0/#why
didip
Why not just use YAML?
vedmakk
Because of the reasons presented in the actual article that was posted by op...
troupo
"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"
xpe
> Provide as few ways as possible—preferably one—of representing something.
TRUTH!
Or, expressed in YAML 1.1 [1]
y
Y
yes
Yes
YES
true
True
TRUE
on
On
ON
truebmn__
ctrl+f grammar
Term not found.
xpe
Me like teh grammarz 2. Plays 4 author someday could put at https://github.com/huml-lang then it slay
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