It was concise and expressive. There was a direct way to describe variants (types with multiple constructors), which is always awkward in JSON, but the format was still surprisingly low-noise for reading and editing by hand. I remember you could even use it as a lightweight markup format:

    (here is some text with (em formatting) information)

And, unlike certain other formats I won't name, it has comments!

It also helps that Emacs with Paredit makes editing s-expressions flow. The tool doesn't need to know anything about the sexplib format specifically; just relying on basic s-expression structure gives us fluid but simple structural editing.

I am constantly sad that nobody else uses this sort of format, and I have to deal with a mixture of JSON, YAML, TOML and other ad-hoc formats instead.

[1]: https://github.com/janestreet/sexplib

Of course just adding multiline strings is the start of the rabbit hole, now you need to think about leading line breaks, trailing line breaks, intermediate line breaks, whitespace chomping, and- oh heavens I've reinvented YAML, I think I need to lie down.

[1] https://mikehadlow.blogspot.com/2012/05/configuration-comple...

Hats off, wish my package.json and build.yml were package.maml and build.maml.

> This is why I based my MAML on top of JSON. I fixed things that were a little bit annoying for me inside JSON.

And now it's incompatible with JSON, which is the worst part of the idea.

Instead, maybe propose a patch to your favorite programming language's JSON module to accept the same extensions for humans that the Perl module already supports, and maybe someone uses it for their JSON config files. This moves us together instead of further apart.

That’s not an argument against the merits of XML, it’s just a fashion declaration.

It’s also wrong. Podcasting boils down to XML files. It even heavily uses XML’s extension mechanism. XML is the basis for RSS and Atom. XML is the basis for LibreOffice and modern Microsoft Office files. XML is at the core of the epub digital book standard. And on and on.

XML may not be ideal for config (reasonable people can disagree on the topic) but it’s not dead.

It’s also interesting that he declares JSON “won” then adds a bunch of XML features to it like ordered entries and not having to quote element/attribute names.

JSON “won” for web apis - e.g. browser-server data interchange. It is not, and was never claimed to be, good for serial documents like config, or for when you need an extensible format (the “X” in XML). It’s fine for what it is, and so is XML, which, when it “won”, was similarly overused, like for web apis.

Programming languages have comments and control flow, multiple popular implementations, and can have nice literals. Lack of Turing completeness is actually not a terribly useful feature if you trust the input (and you should probably just use protobufs or similar for untrusted inputs in that case.)

I made up TER, which supports all ASN.1 types (although in some cases there is not a built-in syntax for them and you must write them in terms of other types; however, extensions can be made for your specific application) and is not limited to Unicode, nor does it limit integers to 64-bits (and you can write integers in any base up to thirty-six). You can convert TER to DER (I wrote a program to do this; it is not really intended for an application to use the full specification of TER itself except for using an external program to convert to DER and then use that instead), and you might also make a subset of TER for specific applications.

But, like any other one, it also has advantages and disadvantages (including some that are mentioned in that article; if they look at TER they would probably have criticisms about that too).

There are two kind of criticisms with JSON, having to do with the data types, and having to do with the syntax, and I had mentioned some of these in the past (some of them are commonly mentioned by others too, but some are less commonly mentioned by others).

Another configuration format is the X resource manager format.

But since we're criticizing formats ;-) maml https://maml.dev is fairly good good.

* I like multiline blocks and comment style

* I do not like optional commas, either require them or not. I'd lean toward requiring them.

* Not sure about ordered object keys. How should languages represent that, a map/dict kind of a data structure won't work it would have to be an ordered dict/list of kvs etc. Two objects {"a":"x", "b":"y"} and {"b":"y", "a":"x"} will be different then. I get the idea, but I am leaning toward not liking it by the time I finished typing all that.

* I like booleans and null. Good for not having ons and offs those are just annoying.

- in the spec, key order clearly exists at the syntactic level

- it's just that the spec says nothing about the semantics of JSON (besides "A conforming processor of JSON texts should not accept any inputs that are not conforming JSON texts.")

quote: "The JSON syntax [...] does not assign any significance to the ordering of name/value pairs"

As a result, the operation of "parsing then serializing again" is not even guaranteed to be idempotent across different environments.

If you have a full-blown programming language you can sprinkle a little bit of code in the template and get express everything you need in a clean way. If all you have is a templating language you have to shoehorn your logic into it (likely making a mess) or use the templating language + a "real" programming language.

Well typed, simple syntax. Maps are annoying though.

* https://www.zytrax.com/books/dns/ch6/#master

* https://bind9.readthedocs.io/en/latest/manpages.html#named-c...

ISC-style? (E/A)BNF-ish?

Personally I like (a) the open/close braces for better stanza navigation, (b) all statements/lines ending with semicolon.

(Something similar was used in (now-EOL) ISC DCHPd, and they've moved to "extended JSON" for their new DHCP server, KEA.)

The problem is that folks want a flat human readable file format to solve all these problems. That's a pipe dream.

JSON and CSV are pretty close to "syntactically optimal" in terms of losslessly storing nested and tabular data, respectively, in a human readable format. We ought to just stick with those and think about how to design effective configuration systems on top of them.

I kind of wish it had two and only two features: defined ordering, and comments

As to languages for configuration (specifically), I wish there was a good specification for a program config, where you would have one well-defined configuration file for defaults, and a user-specified configuration file for the values you have set/overriden.

say default.config:

  {"player_name":"player", "mouse_speed":5}

  {"player_name":"me"}

RE: Jsonnet and others: because it has nice guarantees, like lack of arbitrary I/O and pure execution.

See: https://sre.google/workbook/configuration-specifics/#pitfall...

Need to configure 5 services with hundreds of replicas in 7 data centers? Some values depend on the service, some on the data center and some on the combination thereof? Maybe also overrides for a bunch of problemstic machines?

And you also want a manageable config language which doesn't turn into a full blown Turing tar pit?

Then jsonnet is for you.

So it's not entirely fair to compare it in the "pleasant syntax" contest. It's like putting a Unimog into a ranking of city cars.

At the very bottom, author is presenting its own language (maml.dev). It is yet another JSON with comments, multiline strings, and optional commas. It's the most boring part of the page.

That being said TOML would be my choice.

    Here will be a list of ... things I don't like about them.

Of course you did! :-)

All config formats are bad. You either don't need all the features at all, except key:value. Or you quickly run into weird limitations and quirks.

What I rather like instead, are custom build english-like DSL's, like:

- https://man.openbsd.org/pf.conf - https://man.openbsd.org/smtpd.conf - https://man.openbsd.org/httpd.conf - … and many more

That said, TOML is not unsexy.

I hate JSON as configuration format, it is an exchange format, for configuration TOML is clearly more pleasant. VS Code, Sublime, you are doing it wrong.

- You want bits of programmability in your config language. Else you end up with copy-pasting pieces and adding comments like "must be the same value as foo.bar below!". This sucks enough that you may end up with a config generator for some custom meta-config language, which you need to produce and maintain. You very certainly need symbolic constants, it's great to have simple arithmetics and string concatenation, and ideally you need a way to map a config fragment over a list.

- You don't want a Turing-complete language as your config language. You also don't want to allow any I/O or other effects in that language. You don't want to allow your config parser to do anything but to form a tree of keys and values in memory after reading the config. Javascript is right out. XML is also right out, because entities allow for external resource links, that is, uncontrolled I/O; this was a source of many exploits.

- Nevertheless, you want your configs to be modular when needed, allowing to graft into your main config imported values from some common templates, specific overrides, etc. Direct inclusion is a poor but serviceable approach.

- You want the values in your config be typed. They can be strings by default to save some typing. But you want your config parser to be able to complain when you write a string instead of a number, of a float instead of an integer, or an integer out of representable range (the bane of large numbers in JSON), or a date that cannot be parsed, or a null for a value that cannot be null. This saves you from a ton of nasty surprises when configs are updated.

- You want your config language to have explicit delimiters, so that incompletely copy-pasted constructs would be detected. Hence YAML is a bad choice, JSON5 is a much better choice.

- Of course, you absolutely want comments. JSON is a serialization format, not a human-operated config format.

This is why, I think, CUE, Dhall, and Jsonnet are doing more or less the right thing, but they are a tad large. Maybe something simpler and more compact exists, with some limited programmability and easy syntax.

My guess is the RPN nature would be a no-go for many people. Nevertheless: comments, dicts, arrays, good string syntax, numerics, binary data, etc. Maybe that makes it too complicated.

meh.