That's a Lot of YAML

For the same reason any DSL exists: because the programming representation is a lot more verbose than the DSL, due to the computers not currently honoring the "you know what I meant" flag

  #!/usr/bin/env python3
  """A made up example of the line noise"""
  from ansible import *
  def main():
    hosts = ["localhost"]
    for h in hosts:
      run_one_host(h)
  def run_one_host(inventory_hostname: str):
    connection = ansible.builtin.ssh(inventory_hostname)
    print("sniff out the machine's os")
    host_vars = ansible.builtin.setup(gather_subset="os", connection)
    if host_vars["distribution"] == "ubuntu":
      dest = "/etc/apt"
    else ...
      dest = "/etc/something else"
         
    print("do something awesome")
    copy_ok = ansible.builtin.copy(src="./some_file", dest=dest, connection)
    ...

That said, I can't readily imagine why you couldn't do exactly what you said because the AnsibleModule[1] contract is JSON over stdin/stdout (and one can write Ansible modules in any programming language[2] - they just default to Python)

1: https://github.com/ansible/ansible/blob/v2.18.4/lib/ansible/...

2: https://docs.ansible.com/ansible-core/2.18/dev_guide/develop... and https://github.com/ansible/ansible/blob/v2.18.4/test/integra...

Have you considered XML?

For a configuration language, comments are absolutely crucial. You want to be able to say "# This option is set because <so-and-so>" to explain why you are configuring it this way to the next person that reads the code (or you, in the future).

If the price to pay is that there is some risk some dummy might start parsing the comments as code, so be it. This is not a really a problem in "regular" programming languages, I don't see why it would be in a configuration language.

Comments by themselves provide enough value to justify their supports.

Plus non standard stuff is not a valid argument. As there are many tools which support non standard behaviour, because useful features like comment are considered non standard

Does it support float NaNs? Only asking because of Python's quirky non-standard implementation

Is editing deeply nested JSON and XML a better experience than YAML? I don't think so.

Its. It's is a contraction of it+is

And from their own testimonials section:

> The good news (I realised) was that you can select all the text of the site, and then delete it. Problem solved.

This is the same debate folks have between Maven and Gradle: do you want CI code to be able to do *anything* that Python or Node can do, or do you want well defined knobs people can turn. If nothing else, it makes code reviews for CI way less drama than trying to use some bespoke dsl-in-python that re-implements {job: {steps: [{run: ...}]}} in a less legible way

you only think until you have to extract some information from it. "Here is a dir full of CI job definitions, find all the ones which require extra permissions" - trivial in yaml or json or toml, could be hard to impossible for Python/nodejs.

or "I am doing ci job frontend, for each job I need to get a list of inputs it takes and their description, but without doing full code checkout" - good luck doing this if your jobs are in python/nodejs.

(to be fair, there are programming languages that are also severely limited and can be evaluated mostly safely, like Starlark, but I don't think they'd match your definition)

Yaml is a sad Icarus parable. The syntax is great but the type inference is too much. I don't see why we have to throw the baby out with the bathwater and settle for toml, though.

Here's how yaml's type inference should work:

- All object keys are strings (with or without quotes)

- Value atoms are parsed the exact same way as in JSON5

I'm kinda shocked this isn't a thing. StrictYAML is cool but a bit too cumbersome IMO.

Heh, not sure if you realise, but that website was inspired by my SO answer. (I'm credited at the bottom).