6 ms·

As others in this thread have said: I ask this question all the time, except s/templating/using/. YAML is insanely over complicated; it's as bad or worse than

As others in this thread have said: I ask this question all the time, except s/templating/using/. YAML is insanely over complicated; it's as bad or worse than XML for config files, and it doesn't even have the nice streaming mode. Not to mention that it's a bit of a security nightmare (seriously, who put pointers into the YAML spec?). And, on a more subjective note, YAML is just confusing: between all the significant whitespace and the random single character symbols that no one ever remembers what they do, I never get a YAML document right on the first try. Templating it really does add a whole new level of headache too.

macspoofing 8y ago
>it's as bad or worse than XML for config files XML works very well for config files. It's schema-optional (but is there), well-specified, human-readable, has plethora of supporting technologies (making things like templating easy), and is well supported by every language. At the very least it is way better than JSON.
- Macha 8y ago
  It's missing one important part for config files. It's tedious to write by hand.
  - titanix2 8y ago
    XML is not tedious at all with the right tooling. For example a tool like Visual Studio IntelliSense proposes only elements and attributes valid in the context, automatically close tag, format the file and complete opening tags too so it makes editing XML file a breath.
    - MrStonedOne 8y ago
      The tooling bar for config files is set firmly at notepad.exe If your config file requires more tooling than that you fucked up.
      - heavenlyblue 8y ago
        I mean, with Visual Studio I can even the change the code of the application I am running on the fly, depending on what exactly I am configuring :) That doesn’t make XML an easier format to maintain.
      - macspoofing 8y ago
        notepad is a terrible editor for anything other than simple property files. For example, editing JSON that has any sort of complexity would be just as painful.
  - int_19h 8y ago
    Not really. For quick authoring, configs should have pre-authored snippets for common things, that are commented out, and have adjacent descriptive comments ("Uncomment the following to ...") - this is regardless of their syntax. And for complicated stuff, you're going to spend a lot more time reading the manual than you will actually typing those closing tags. In fact, in most cases you'd be copy/pasting bits from the manual as well.
- guitarbill 8y ago
  > human-readable technically yes, practically maybe not so much, especially with e.g. CDATA sections
  - smittywerben 8y ago
    He means Cantor's XML you barbarian.
  - macspoofing 8y ago
    If we're talking about a human-editable configuration file, then yes, it will be quite human-readable. Machine generated XML can be noisy but the target for those are other machines, and the extra context is there for a reason. You can certainly make XML as obtuse and complex as you want.
    - Gibbon1 8y ago
      Two examples from two IDE's. Codelite's xml based project files can be easily read and modified by hand. Diffing them yields useful information about files added and moved, config values changed, etc. Eclipses project files also written in xml are an Eldritch Horror. I think the failing of xml is also it's strength. It doesn't do typing and schemas, doesn't even try. Which means that can be sane. Or not.
- eadmund 8y ago
  There's absolutely no way that this (copied from https://github.com/akeeba/fof/wiki/The-XML-configuration-file https://github.com/akeeba/fof/wiki/The-XML-configuration-fil...): <?xml version="1.0" encoding="UTF-8"?> <fof>  <common>  <container> <option name="componentNamespace"><![CDATA[MyCompany\MyApplication]]></option> </container>  <dispatcher> <option name="defaultView">items</option> </dispatcher>  <authentication> <option name="totpKey">ABCD123456</option> <option name="authenticationMethods">HTTPBasicAuth_TOTP,QueryString_TOTP</option> </authentication>  <model name="orders">  <config> <option name="tbl"><![CDATA[#__fakeapp_orders]]></option> </config>  <field name="enabled">published</field>  <relation type="hasMany" name="items" /> <relation type="belongsToMany" name="transactions" localKey="foobar_order_id" foreignKey="foobar_transaction_id" pivotLocalKey="foobar_order_id" pivotForeignKey="foobar_transaction_id" pivotTable="#__foobar_orders_transactions" /> <relation type="belongsTo" name="client" foreignModelClass="Users@com_fakeapp" />  <behaviors merge="1">foo,bar,baz</behaviors> </model>  <view name="item">  <taskmap> <task name="list">browse</task> </taskmap>  <acl> <task name="dosomething" /> <task name="somethingelse">core.manage</task> </acl>  <config> <option name="autoRouting">3</option> </config>  <toolbar title="COM_FOOBAR_TOOLBAR_ITEM" task="edit"> <button type="save" /> <button type="saveclose" /> <button type="savenew" /> <button type="cancel" /> </toolbar> </view> </common>  <backend>  </backend>  <frontend>  </frontend> </fof> is at all preferable to this: (fof (common (container (component-namespace "MyCompany\\MyApplication")) (dispatcher (default-view items)) (authentication (totp-key ABCD123456) (authentication-methods (http-basic-auth-totp query-string-totp))) (model orders (config (tbl "#__fakeapp_orders")) ;; Field aliasing. One tag per aliased field (field enabled published) ;; Relation setup. One tag per relation (relation items (type has-many)) (relation transaction (type belongs-to-many) (local-key "foobar_order_id") (foreign-key "foobar_transaction_id") (pivot-local-key "foobar_order_id") (pivot-foreign-key "foobar_transaction_id") pivot-table "#__foobar_orders_transactions") (relation client (type belongs-to) (foreign-model-class "Users@com_fakeapp")) ;; Behaviour setup. Use merge="1" to merge with already defined behaviours. (behaviors (merge 1) (foo bar baz))) ;; Controller, View and Toolbar setup. One tag per view. (view item (taskmap (list browse)) ;; Controller ACL mapping (acl (task dosomething) (task somethingelse core.manage)) ;; Controller and View options (config (auto-routing 3)) ;; Toolbar configuration (toolbar "COM_FOOBAR_TOOLBAR_ITEM" (task edit) (button save) (button saveclose) (button savenew) (button cancel)))) (backend) (frontend)) There's just no way.
basil-rash 8y ago
If you think the whitespace is bad, just wait till you see the implicit casting: https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/
- dmix 8y ago
  God, I hate programming some times.
  - krapp 8y ago
    Stick with a config format that isn't overengineered and too clever for its own good, like... anything but YAML?
    - dmix 8y ago
      That might solve one problem but fighting your tools and occasionally hating the complex giant messes we've engineered is a fact of life for any programmer. I absolutely love programming, just not always the process. We get better and better tools each year but it still seems unavoidable. We're ultimately building incredibly complex systems with each layer using multiple development approaches, style choices, language choices, degrees of quality/time investment by the creator, etc. TLDR: you can't help bang your head against the wall in any real-world day-to-day programming
    - rbanffy 8y ago
      You can always use a subset of YAML (much like we do with JavaScript these days).
      - SamWhited 8y ago
        That's a nice thought, but it comes with its own problems. For example, XMPP uses a sane subset of XML, which is nice, except that people throw full XML parsers at it (because why wouldn't you? Your XML library parses XML and limiting that is more work for the developer to do) and then end up with vulnerabilities they don't know about like entity expansion DOS's or system directive stuff (and YAML has lots of tricky behavior that can be abused too like pointers). Using a subset creates more work for the developer, so many just won't bother (if they even know that it's using a subset and they have to do more work at all), which leads to issues.
rbanffy 8y ago
> it's as bad or worse than XML for config files Let's agree to disagree here. No human should ever write XML. No human should ever be forced to read it. YAML is very readable and writable if you stay away from the corners. Templating allows you to stay clear of the corners (the 1 char operators that concatenate stuff, b64 stuff and so on).
- Spivak 8y ago
  > the 1 char operators that concatenate stuff But they're super useful. Some examples from Ansible. - name: Do something annoying. command: > ./my-really-annoying-command -a yep -c it --really-does=take-a-lot --of-options subcommand --target=blah --timeout=60 --callback=/usr/local/bin/callback-x245.sh https://example.com/this-is-the-worst.aspx varable_that_I_need_to_preserve_whitespace: | #BEGIN_LICENSE_KEY ...
  - rbanffy 8y ago
    But they are less than readable.
bostonvaulter2 8y ago
This is my favorite collections of reasons that yaml is a bad config file format: https://github.com/cblp/yaml-sucks https://github.com/cblp/yaml-sucks

macspoofing 8y ago

>it's as bad or worse than XML for config files XML works very well for config files. It's schema-optional (but is there), well-specified, human-readable, has plethora of supporting technologies (making things like templating easy), and is well supported by every language. At the very least it is way better than JSON.

Macha 8y ago
It's missing one important part for config files. It's tedious to write by hand.
- titanix2 8y ago
  XML is not tedious at all with the right tooling. For example a tool like Visual Studio IntelliSense proposes only elements and attributes valid in the context, automatically close tag, format the file and complete opening tags too so it makes editing XML file a breath.
  - MrStonedOne 8y ago
    The tooling bar for config files is set firmly at notepad.exe If your config file requires more tooling than that you fucked up.
    - heavenlyblue 8y ago
      I mean, with Visual Studio I can even the change the code of the application I am running on the fly, depending on what exactly I am configuring :) That doesn’t make XML an easier format to maintain.
    - macspoofing 8y ago
      notepad is a terrible editor for anything other than simple property files. For example, editing JSON that has any sort of complexity would be just as painful.
- int_19h 8y ago
  Not really. For quick authoring, configs should have pre-authored snippets for common things, that are commented out, and have adjacent descriptive comments ("Uncomment the following to ...") - this is regardless of their syntax. And for complicated stuff, you're going to spend a lot more time reading the manual than you will actually typing those closing tags. In fact, in most cases you'd be copy/pasting bits from the manual as well.
guitarbill 8y ago
> human-readable technically yes, practically maybe not so much, especially with e.g. CDATA sections
- smittywerben 8y ago
  He means Cantor's XML you barbarian.
- macspoofing 8y ago
  If we're talking about a human-editable configuration file, then yes, it will be quite human-readable. Machine generated XML can be noisy but the target for those are other machines, and the extra context is there for a reason. You can certainly make XML as obtuse and complex as you want.
  - Gibbon1 8y ago
    Two examples from two IDE's. Codelite's xml based project files can be easily read and modified by hand. Diffing them yields useful information about files added and moved, config values changed, etc. Eclipses project files also written in xml are an Eldritch Horror. I think the failing of xml is also it's strength. It doesn't do typing and schemas, doesn't even try. Which means that can be sane. Or not.
eadmund 8y ago
There's absolutely no way that this (copied from https://github.com/akeeba/fof/wiki/The-XML-configuration-file https://github.com/akeeba/fof/wiki/The-XML-configuration-fil...): <?xml version="1.0" encoding="UTF-8"?> <fof>  <common>  <container> <option name="componentNamespace"><![CDATA[MyCompany\MyApplication]]></option> </container>  <dispatcher> <option name="defaultView">items</option> </dispatcher>  <authentication> <option name="totpKey">ABCD123456</option> <option name="authenticationMethods">HTTPBasicAuth_TOTP,QueryString_TOTP</option> </authentication>  <model name="orders">  <config> <option name="tbl"><![CDATA[#__fakeapp_orders]]></option> </config>  <field name="enabled">published</field>  <relation type="hasMany" name="items" /> <relation type="belongsToMany" name="transactions" localKey="foobar_order_id" foreignKey="foobar_transaction_id" pivotLocalKey="foobar_order_id" pivotForeignKey="foobar_transaction_id" pivotTable="#__foobar_orders_transactions" /> <relation type="belongsTo" name="client" foreignModelClass="Users@com_fakeapp" />  <behaviors merge="1">foo,bar,baz</behaviors> </model>  <view name="item">  <taskmap> <task name="list">browse</task> </taskmap>  <acl> <task name="dosomething" /> <task name="somethingelse">core.manage</task> </acl>  <config> <option name="autoRouting">3</option> </config>  <toolbar title="COM_FOOBAR_TOOLBAR_ITEM" task="edit"> <button type="save" /> <button type="saveclose" /> <button type="savenew" /> <button type="cancel" /> </toolbar> </view> </common>  <backend>  </backend>  <frontend>  </frontend> </fof> is at all preferable to this: (fof (common (container (component-namespace "MyCompany\\MyApplication")) (dispatcher (default-view items)) (authentication (totp-key ABCD123456) (authentication-methods (http-basic-auth-totp query-string-totp))) (model orders (config (tbl "#__fakeapp_orders")) ;; Field aliasing. One tag per aliased field (field enabled published) ;; Relation setup. One tag per relation (relation items (type has-many)) (relation transaction (type belongs-to-many) (local-key "foobar_order_id") (foreign-key "foobar_transaction_id") (pivot-local-key "foobar_order_id") (pivot-foreign-key "foobar_transaction_id") pivot-table "#__foobar_orders_transactions") (relation client (type belongs-to) (foreign-model-class "Users@com_fakeapp")) ;; Behaviour setup. Use merge="1" to merge with already defined behaviours. (behaviors (merge 1) (foo bar baz))) ;; Controller, View and Toolbar setup. One tag per view. (view item (taskmap (list browse)) ;; Controller ACL mapping (acl (task dosomething) (task somethingelse core.manage)) ;; Controller and View options (config (auto-routing 3)) ;; Toolbar configuration (toolbar "COM_FOOBAR_TOOLBAR_ITEM" (task edit) (button save) (button saveclose) (button savenew) (button cancel)))) (backend) (frontend)) There's just no way.

basil-rash 8y ago

If you think the whitespace is bad, just wait till you see the implicit casting: https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/

dmix 8y ago
God, I hate programming some times.
- krapp 8y ago
  Stick with a config format that isn't overengineered and too clever for its own good, like... anything but YAML?
  - dmix 8y ago
    That might solve one problem but fighting your tools and occasionally hating the complex giant messes we've engineered is a fact of life for any programmer. I absolutely love programming, just not always the process. We get better and better tools each year but it still seems unavoidable. We're ultimately building incredibly complex systems with each layer using multiple development approaches, style choices, language choices, degrees of quality/time investment by the creator, etc. TLDR: you can't help bang your head against the wall in any real-world day-to-day programming
  - rbanffy 8y ago
    You can always use a subset of YAML (much like we do with JavaScript these days).
    - SamWhited 8y ago
      That's a nice thought, but it comes with its own problems. For example, XMPP uses a sane subset of XML, which is nice, except that people throw full XML parsers at it (because why wouldn't you? Your XML library parses XML and limiting that is more work for the developer to do) and then end up with vulnerabilities they don't know about like entity expansion DOS's or system directive stuff (and YAML has lots of tricky behavior that can be abused too like pointers). Using a subset creates more work for the developer, so many just won't bother (if they even know that it's using a subset and they have to do more work at all), which leads to issues.

rbanffy 8y ago

> it's as bad or worse than XML for config files Let's agree to disagree here. No human should ever write XML. No human should ever be forced to read it. YAML is very readable and writable if you stay away from the corners. Templating allows you to stay clear of the corners (the 1 char operators that concatenate stuff, b64 stuff and so on).

Spivak 8y ago
> the 1 char operators that concatenate stuff But they're super useful. Some examples from Ansible. - name: Do something annoying. command: > ./my-really-annoying-command -a yep -c it --really-does=take-a-lot --of-options subcommand --target=blah --timeout=60 --callback=/usr/local/bin/callback-x245.sh https://example.com/this-is-the-worst.aspx varable_that_I_need_to_preserve_whitespace: | #BEGIN_LICENSE_KEY ...
- rbanffy 8y ago
  But they are less than readable.

bostonvaulter2 8y ago

This is my favorite collections of reasons that yaml is a bad config file format: https://github.com/cblp/yaml-sucks https://github.com/cblp/yaml-sucks