MAML – A new configuration language

> Minimal Abstract Markup Language

Pardon my naming nitpick and lack of commentary on any technical aspect, but I don't think this is a markup language. What is being marked up? HTML is called that because it's marking up text with like bold and italics and font and color and paragraphs and stuff.

To be fair, YAML's creators had the same misunderstanding. Compare:

https://yaml.org/spec/history/2001-12-10.html

https://yaml.org/spec/history/2002-04-07.html

The author of this language seems to have responded with AI-generated arguments in response to all questions linked in the FAQ section. This does not inspire much confidence for the design of the language.

Really, I do not see the point of this. These configuration languages are just different syntaxes for expressing the same fundamental data, bearing the same semantics. It would be much more interesting to see a language which experiments with what is fundamentally representable, for example like how the Nix language supports functional programming and has functions as a first-class data type.

I understand trying to improve popular technologies that have issues, but for a text format with mass ubiquity, JSON has very little wrong with it to the point where I believe that projects like this are a profound waste of everyone's time.

I am all for people experimenting and making things they like, but a domain was purchased so I can only assume a serious intent to make something of this and my only reaction is that I hope this is not taken seriously and disappears.

I love this. It reminds me of PowerShell configuration files: https://ssg.dev/powershell-accidentally-created-a-nice-confi...

This is basically JSON for humans. YAML is harder to use due to significant indentation (easy to mess up in editors, and hard to identify the context), and TOML isn't great for hierarchical data.

It addresses all my complaints about JSON:

> Comments

> Multiline strings

> Optional commas

> Optional key quotes

I wish it was a superset of JSON (so, a valid JSON would also be valid MAML), but it doesn't seem to be the case.

EDIT: As I understand, HCL is very similar in terms of goals, and has been around for a while. It looks great too. https://github.com/hashicorp/hcl/

My IT department blocks me from seeing this page. I suppose they wish to preserve my sanity, by shielding me from yet another config-language spec. =)

But why, - jsonnet https://jsonnet.org/ resolves the annoying syntactic strictness of json + does some other interesting things.

I just can’t anymore with this stuff. TOML, JSON, YAML, JSONC, HJSON, MAML…

I’ll just stick to environment vars or something code

I see the negativity in some comments, but I have to say: just because we have a format that works we don't have to suffer it's slightly annoying problems for eternity.

This is a format that's very well defined, good decisions where to be flexible (quoted keys) and when to be strict (no leading zeroes, no leading plus sign, error when integer parsing can't be precise, defining all corner cases in strings).

For almost all of these, I remember cases when something went wrong (or was just annoying) in another format.

I admire efforts to fix things.

I believe every ambitious programmer makes a configuration language at some point, but most either keep it to themselves.

When I was a teen I made something called Nabla:

  * XML-like syntax

  * Schema language
  * Compact binary representation
  * Trivial parser for binary representation 
  * Optionally, simple dynamic programming language on top

Initially made it for my 3d engine scene serialization format, but then used everywhere some non-trivial data format was needed (e.g. anything with nested data structures).

I wonder if the author has heard of KDL: https://kdl.dev/

So a worse version of HJSON[1]. I'm good.

[1]: https://hjson.github.io/

Hmm, that's just "another link from someone who uses HN as a bookmark service". User started this self-service at the end of last year. With now 60+ submissions in the last two weeks. We can expect more interesting topics.

> Optional commas

> Optional key quotes

For me, it is an anti-feature.

Each time something is optional, by definition, there is more than one way to do it. I much more prefer opinionated way, so it is consistent.

It is precisely why I like linters, so instead of a few ways to go, I pick one and stick to it. More focus on the content and less on things that do not matter.

> Optional key quotes

Why are they optional? Why not just make them mandatory? So I don't need to guess which chars need quotes.

Edit: What most languages also lack: semantics on de-serialization. In the best case, I want to preserve formatting and stuff when the config is changed/re-committed programmatically.

This looks like an anemic HOCON[0] clone.

0 - https://github.com/lightbend/config/blob/main/HOCON.md

I like it a lot: a superset of JSON, fixing the most annoying warts of the format - most annoying, because most gratuitous, in that it would have cost nothing to have those obvious features and yet would have greatly increased usability. It's just a very pragmatic approach to improving JSON compared to creating a brand-new language like YAML and a slew of other contenders seemingly vainly try. I wish the name and presentation would better reflect this. Something like FJSON (Fixed JSON) or JSONF (JSON Fixed) or some other name which makes it clear this is an extended JSON, not yet another language, to avoid the confusion which already has engulfed the comment section here.

Great name and a reasonable solution to the problems of JSON (can't speak for the implementation but the DX value of this is huge).

There's also - https://huml.io

Problem: Trailing commas, key-quoting-rules, etc are a problem when generating JSON from scripts/templates - which is a key practical necessity for a Configuration language. Of course, you may already disagree here and say you don't have this problem, but it's a sufficient problem for everyone that there are many attempts to solve it. If you don't have this problem, feel free to ignore.

MAML: Takes JSON, makes trailing commas & key-quoting optional. One may not like it, but it does indeed solve the scripting problem, and it's a nice and novel idea. Thereby it's a "Superset" of JSON. All JSON is valid MAML, but all MAML is not valid JSON.

JSONNet: Also a good attempt, directly solving the scripting problem with built-in functions and so on. But can be overwhelming.

Other approach: A strict "Subset" of JSON. Every value MUST end with a comma, whether it's first or last. Every key MUST be quoted. Comments MUST be a valid JSON key-value called ".comment" that will be ignored at parsing but otherwise part of the JSON. JSON5 seems to be more suitable for this.

They fix some of the problems with syntax of JSON but do not fix most of the problems with the data model; the only thing they do fix is that now there is a integer type. It still has the other problems, e.g. it still uses Unicode and still requires keys to be strings. For a configuration language, it can also be useful to have a application-specific data.

I like it. It solves a few issues I have with JSON. The quotes on the keys, the commas, etc. nice work. Keep them coming

Practically HCL, switch colons for equals in the key/value map

MAML sounds like mammelle in French, but besides that I think that making things optional adds complexity. JSON is simple because it's strict and the syntax parts are not optional.

As much as I like writing javascript objects without quotes, it's javascript, not JSON. I don't mind putting quotes in JSON. Plus, it helps distinguishing it from javascript.

People don't always agree wether there should be a trailing comma or not. At least with JSON there's no choice. Making a trailing comma mandatory would be weird. Because mandatory is different than "automatically added by Prettier".

What I like about JSON is that people can't use it to make weird things like HTMLX on top of it. Even plain HTML is no longer XML. At least JSON is JSON.

I don't mind VS Code using JSONC for it's config though.

This thing is what triggered me to write https://ruudvanasseldonk.com/2025/abstraction-not-syntax

If I actually require comments, dangling commas etc. I'm always using JSON5 instead [1].

[1] https://json5.org/

When this was first posted a couple of weeks ago by the spec's author, I took it as an opportunity to see how quickly I could spin up an IntelliJ language plugin since the last time I worked on a language plugin was pre-GPT (Klotho Annotations - basically TOML inside of @annotations inside comments or string literals in a variety of host languages). Back then, it took a week for me to figure out the ins and outs of basic syntax highlighting with GrammarKit.

This time around, I worked with Claude Code and we basically filled in each other's knowledge gaps to finish implementing every feature I was looking for in about 3 days of work:

Day 1:

- Plugin initialization

- Syntax highlighting

- JSON Schema integration

- Error inspections

Day 2:

- Code formatter (the code style settings page probably took longer to get right than the formatter)

- Test suite for existing features

Day 3:

- Intentions, QuickFix actions, etc. to help quickly reformat or fix issues detected in the file

- More graceful parsing error recovery and reporting

- Contextual completions (e.g., relevant keys/values from a JSON schema, existing keys from elsewhere in the file, etc.)

- Color picker gutter icon from string values that represent colors (in various formats)

I'm sure there are a few other features that I'm forgetting, but at the end of the day, roughly 80-85% of the code was generated from the command line by conversing with Claude Code (Sonnet 4.5) to plan, implement, test, and revise individual features.

For IntelliJ plugins, the SDK docs tend to cover the bare minimum to get common functionality working, and beyond that, the way to learn is by reading the source of existing OSS plugins. Claude was shockingly good at finding extension points for features I'd never implemented before and figuring out how to wire them up (though not always 100% successfully). It turns out that Claude can be quite an accelerator for building plugins for the JetBrains ecosystem.

Bottom line, if you're sitting on an idea for a plugin because you thought it might to take too long to bootstrap and figure out all the IDE integration parts, there's never been a better time to just go for it.

EDIT: Repo link for anyone interested: https://github.com/DavidSeptimus/maml-intellij-plugin

The Raku language (https://raku.org) nails multiline strings and avoids the triple quotes issues mentioned in the OP.

  say q:to/END/;
    Here is
    some multi line
        string
    END

https://docs.raku.org/syntax/heredocs%20%3Ato

Looks infinitely much nicer than YAML, with explicit blocks and such.

That's not a high bar of course, even the apache httpd pseudo xml is nicer than yaml.

While JSON kind of sucks as a configuration language, it's already there and I don't think it sucks enough for me to care to use anything else. Not having trailing commas or comments is annoying, but unless you're the config file for a web server or something, I'm cool with JSON.

This is super controversial for HN but I really really like YAML. The best “human readable” config language.

There is also https://kdl.dev/

This looks pretty good but also JSON5 is perfectly fine, it just needs more support from libraries and IDEs. Adding another format is just going to make that problem worse. And nobody is going to use this format either because it also has poor support from libraries and IDEs.

Thanks for reminding me that I always wanted to create an alternative to JSON/YAML, so after your post, I got down to work, and this is what came out: https://vzparse.xyz/

If I could change the world I'd remove all those formats and keep cuelang only.

Oh yay, just what we need, ANOTHER one of these. Did the YA in YAML not already give a clue? Now there are 15 competing standards. Please make it stop. S-expressions were all that we wanted in the first place.

An important detail not covered here, is dates.

Json doesn't support dates, so we use strings in whatever format.

A good new configuration language should have dates. IMO.

So far it seems like Json with comments =)

I've been using EDN for years without ever wishing for something different. It's unfortunate that it hasn’t caught on outside the Clojure world.

I like it, but it's too late.

It could also do with a datetime datatype, the one thing (apart from comments) that I constantly feel the need for in JSON.

json without comments is one of the worst cancers in programming land. however replacing json5 // with # is NOT it!

Why does this look pretty much like JSON with the only exception being no commas between elements in a list / array?