MAML – A new configuration language

Original Article ↗ Hacker News Discussion ↗

A new configuration format called MAML, which extends JSON with features like comments, multiline strings, optional commas, and unquoted keys, is drawing mixed reactions. Supporters see it as a pragmatic, human-friendlier refinement of JSON, while critics question the value of yet another config syntax given existing options such as YAML, TOML, JSON5, HCL, CUE, and Jsonnet, and argue that deeper issues lie in data models and semantics rather than surface syntax. Concerns also surface around ecosystem support, inconsistent optional features, and the choice to market it as a “markup language.”

Similarity to Existing Formats

  • Many see MAML as “JSON with extras” or nearly identical to HJSON/HOCON/HCL/KDL/JSON5: comments, multiline strings, optional commas, and often unquoted keys.
  • Several note prior art (HJSON, HOCON, JSON5, KDL, Lua tables, JSONC, etc.) and feel MAML doesn’t acknowledge or improve meaningfully on it.
  • Some argue it’s essentially a superset of JSON, but others point out incompatibilities (e.g., different Unicode escape syntax).

Perceived Advantages

  • Supporters like:
    • Comments and multiline strings.
    • Optional commas and unquoted keys; removing “JSON’s most annoying warts”.
    • A distinct integer type, improving over JSON’s single numeric type.
  • A few praise the spec’s attention to edge cases and see it as a pragmatic, human-friendly JSON improvement, nicer than YAML or TOML for nested data.

Critiques of Design and Data Model

  • Detractors say it only tweaks syntax while leaving fundamental issues:
    • Still Unicode-only, keys must be strings, limited data types, no dates, no NaN/Infinity, no domain-specific types.
  • Optional quotes/commas are called anti-features: more ways to write the same thing reduce consistency and complicate tooling.
  • Some worry about round‑tripping: parsers can read the “enhanced” syntax but may not preserve it on write.

“Yet Another Config Language” and Adoption Concerns

  • Strong sentiment that configuration formats are already overcrowded (JSON, YAML, TOML, JSON5, HCL, Dhall, CUE, jsonnet, Pkl, etc.).
  • Many say JSON’s shortcomings aren’t bad enough to justify another format with minimal semantic gain, and that poor ecosystem support will doom new contenders.
  • Others counter that YAML’s footguns and JSON’s rigidity justify continued experimentation.

Broader Perspectives & Alternatives

  • Several suggest richer or more ambitious approaches like Nix, Dhall, CUE, jsonnet, Pkl, EDN, or functional/typed configuration, rather than another JSON-like syntax.
  • Some argue for typeless or application-defined typing; others prefer strong intrinsic types.

Meta: Naming and Author Communication

  • “Minimal Abstract Markup Language” is criticized as misleading: it’s configuration, not markup, nor clearly “abstract”.
  • There’s a side thread about the FAQ answers appearing AI-generated, reducing confidence, though some attribute it to language/grammar assistance rather than content fabrication.