[HN Gopher] MAML - a new configuration language (similar to JSON...
___________________________________________________________________
MAML - a new configuration language (similar to JSON, YAML, and
TOML)
Author : birdculture
Score : 21 points
Date : 2025-10-12 21:24 UTC (1 hours ago)
(HTM) web link (maml.dev)
(TXT) w3m dump (maml.dev)
| ghthor wrote:
| Practically HCL, switch colons for equals in the key/value map
| sedatk wrote:
| I didn't know about HCL. It looks great too.
| antonymoose wrote:
| Working with Terraform, and needing to handle the complexity of
| our per-client deployments at work, I ended up creating a bash
| layer that takes N number of JSON files, performs a deep merge,
| and spits out a .tfvars file.
|
| As you've said, all I did was fork a JSON.stringify function
| and swap colon for equals.
|
| Anyone have a better solution they've worked with?
| sjdrc wrote:
| Why?
| sorrythanks wrote:
| question: why not make all strings multi-line, and drop a
| syntax/concept?
| poly2it wrote:
| 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.
| zzo38computer wrote:
| > These configuration languages are just different syntaxes for
| expressing the same fundamental data, bearing the same
| semantics.
|
| This is my complaint too. However, they do add a proper integer
| type, which is the only thing that they do change with the
| data, as far as I can tell.
|
| > It would be much more interesting to see a language which
| experiments with what is fundamentally representable
|
| DER (and TER, which is a text format I made up to be compiled
| into DER (although TER is not really intended to be used
| directly in application programs); so TER does have comments,
| hexadecimal numeric literals, and other syntax features) does
| support many more data types, such as arbitrarily long
| integers, ASCII, ISO 2022, etc. My own extension to the format
| adds some additional types, such as a key/value list type and a
| TRON string type; the key/value list type is the only
| nonstandard ASN.1 type needed (together with a few of the
| standard ASN.1 types: sequence, real, UTF-8 string, null,
| boolean) to represent the same data as JSON does.
|
| > for example like how the Nix language supports functional
| programming and has functions as a first-class data type.
|
| For some applications this is useful and good but in others it
| is undesirable, I think.
| sedatk wrote:
| > AI-generated arguments in response to all questions
|
| There are currently two items in the FAQ. While the first one
| seems to be formatted with AI (I don't know if the arguments
| are AI generated though, how do you tell?), the other certainly
| doesn't look AI-generated: https://github.com/maml-
| dev/maml/issues/3#issuecomment-33559...
| ajsnigrutin wrote:
| Why?
|
| https://xkcd.com/927/ ?
|
| Or is there any reason why to choose this over the others?
| sedatk wrote:
| 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/
| CBLT wrote:
| > TOML isn't great for hierarchical data.
|
| My experience is different: TOML isn't obvious if there's an
| array that's far from the leaf data. Maybe that's what you
| experienced with the hierarchical data?
|
| In my usage of it (where we use base and override config
| layers), arrays are the enemy. Overrides can only delete the
| array, not merge data in. TOML merely makes this code smell
| more smelly, so it's perfect for us.
| zzo38computer wrote:
| 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.
| rglover wrote:
| 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).
| nikeee wrote:
| > Optional key quotes
|
| Why are they optional? Why not just make them mandatory? So I
| don't need to guess which chars need quotes.
| kennethallen wrote:
| Oh, joy
| throwaway81523 wrote:
| 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.
___________________________________________________________________
(page generated 2025-10-12 23:00 UTC)