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.
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/
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.
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.
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.
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).
Am I missing something or is this literally just Ruby? Like - it doesn’t list Ruby as a supported language, but, it also looks like fully executable Ruby code?
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.
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:
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.
57 comments
[ 5.1 ms ] story [ 57.0 ms ] threadReally, 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.
https://xkcd.com/927/ ?
Or is there any reason why to choose this over the others?
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/
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.
[1]: https://hjson.github.io/
When I was a teen I made something called Nabla:
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).(To be fair, I’m in favor of that)
Edit: Oh, no commas.
I’ll just stick to environment vars or something code
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
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
0 - https://github.com/lightbend/config/blob/main/HOCON.md