In Defense of YAML

Post by taeric » Thu, Mar 21, 2019, 6:21 PM UTC

jimbokun wrote: post #55

krapp wrote: post #19

Earlier quoted context omitted.

One of these days, I want to come up with a non Turing complete s-expression based config format (basically something like a Lispy JSON) and post it here just to watch Lispers rage at not being able to write DSLs in it.

But...they will be able to write DSLs in it. Just create functions with the same name as the head atom of the top level lists, then run the config file as a program. Or write macros matching the syntax of your format to generate code. I mean, maybe there is something about your format that makes these specific approachs inconvenient. But once you give a Lisper a bunch of S-expressions, you just opened the door for th…

Post by js2 » Thu, Mar 21, 2019, 6:23 PM UTC

gomoboo wrote: post #95

The configuration method for the Gunicorn server ( http://docs.gunicorn.org/en/stable/configure.html#configurat... ) would be a great example to follow. Configuration files are just Python modules. You can specify the number of workers and set log file locations with the following: from multiprocessing import cpu_count def max_workers(): return cpu_count() * 2 + 1 workers = max_workers() errorlog = "/var/www/lcfs/log…

Post by lawn » Thu, Mar 21, 2019, 6:40 PM UTC

bpicolo wrote: post #3

> This is not structured data. This is programming masquerading as configuration I find myself expressing this same opinion to people on a frequent basis. See ansible for another big example. Ansible has a try/catch equivalent in yaml [0]! Unfortunately, YAML is more or less a lowest common denominator for these sorts of interactions - being usable from any language is a really big boon. Would love to see the world a…

Post by lamontcg » Thu, Mar 21, 2019, 6:46 PM UTC

scirocco wrote: post #64

q3k wrote: post #21

Earlier quoted context omitted.

From what I've experienced, it's mostly tools that target either sysadmins or sysadmins-turned-pseudo-devops, and those tools pretend that anything can be done with 'just configuration' as a marketing point. Programming is for programmers, you see. It's easy for someone who never {wanted to, learned to} program to accept yet another configuration format (with all options specified up front) and then accidentally lear…

Would you expect all sysadmins to become programmers?

Post by yellowapple » Thu, Mar 21, 2019, 6:51 PM UTC

kevin_thibedeau wrote: post #77

joshlemer wrote: post #6

Earlier quoted context omitted.

What about https://dhall-lang.org/ ?

You can make Tcl as non-Turing complete as you wish. Stripped of most or all builtin commands, it becomes a flexible configuration language. You can add back power in small controlled doses as it becomes necessary. You can also make it more palatable to the cool kids by adding infix assignment and expression evaluation with a few simple helper procs.

    {application,otpcl,
                 [{description,"Open Telecom Platform Command Language"},
                  {vsn,"0.1.0"},
                  {modules,[otpcl,otpcl_env,otpcl_eval,otpcl_init,otpcl_parse,
                            otpcl_shell,otpcl_stdlib,otpcl_stdmeta]},
                  {registered,[]},
                  {applications,[kernel,stdlib]},
                  {licenses,["ISC"]},
                  {links,[{"Bitbucket","https://bitbucket.org/YellowApple/otpcl"},
                          {"GitHub","https://github.com/YellowApple/otpcl"}]}]}.

    application otpcl {
        description "Open Telecom Platform Command Language"
        vsn 0.1.0
        modules otpcl otpcl_env otpcl_eval otpcl_init otpcl_parse \
                otpcl_shell otpcl_stdlib otpcl_stdmeta
        registered
        applications kernel stdlib
        licenses ISC
        links {
            Bitbucket "https://bitbucket.org/YellowApple/otpcl"
            GitHub "https://github.com/YellowApple/otpcl"
        }
    }