Human-Oriented Markup Language

Scalar vs vector and the :: debate

• A major thread focuses on HUML’s use of : for scalars and :: for vectors.
• Supporters like the clear distinction and how it enables inline lists/dicts without extra brackets, e.g. props:: mime_type: "text/html", encoding: "gzip".
• Critics argue this is machine-driven, not human-oriented: people don’t want to think about types when writing configs and will be confused by documents failing due to a missing or extra colon.
• Alternatives suggested: mandatory braces for inline structures, trailing commas to indicate lists, Python-style rules (1 vs 1,), or other delimiters instead of doubling :.
• Some note that “double = more” is intuitive only if the single-colon form remains the dominant, simpler case.

Human-oriented vs machine-oriented design

• There’s tension between strictness that aids parsing/autoformatting (e.g. “only one space after :”, significant whitespace) and claims of “human readability above all else.”
• Some see HUML’s scalar/vector distinction as its main improvement over YAML; others see it as adding cognitive load.
• Several comments emphasize that what is “human-friendly” is highly subjective and trade-offs quickly snowball in language design.

Whitespace, indentation, and readability

• Significant whitespace is contested: some find it visually clear; others say it makes block boundaries ambiguous and fragile, especially with inconsistent editors.
• Comparisons are drawn to Python, YAML, JSON, and XML, with people split on whether indentation or explicit delimiters are easier to reason about in large, nested documents.

Comparisons to existing formats

• HUML is framed in the thread as “trying to fix YAML horrors,” but some question why YAML 1.2 or JSON5 aren’t sufficient.
• Skeptics see HUML as “yet another YAML” offering less flexibility than JSON and less explicit structure than XML, while adding new syntax to learn.
• Fans of XML argue it’s actually more readable for complex, nested data because of explicit tags; others prefer JSON’s simplicity and tooling.
• TOML is mentioned as “good enough” for many config cases, with some calling further formats unnecessary wheel reinvention.

Specification, tooling, and ecosystem

• Multiple commenters want a formal grammar/spec in addition to examples to judge complexity and implement parsers.
• Strict rules are seen as useful for linting and autoformatting.
• Some say language-server support and editor tooling (LSP, autocomplete, inline docs) matter more than the surface syntax for real-world usability.