+1000 fake internet points to this article for keeping it short with clear examples.
In Defense of YAML
41–50 of 173 posts
Re: In Defense of YAML
#42While there are no other format with clear advantage over YAML, I wonder why nobody use javascript with modules as programmable configuration.
Can be broken to file parts, support comment, variable, functions or scripts. And with additional extension can import packages. Though the downside may be JSON format that's noticably bigger than yaml.
Re: In Defense of YAML
#43While we're writing the wrongs of badly specified interfaces, can we please kill this stupid obsession with "writing code" to get work done? Code is buggy. It's difficult to write well, you have to write 10,000 tests for it, you have to have a testing framework, complex procedures to move it through pipelines and roll it back and version control it and debug it and maintain it and deploy it. It's annoying.
I don't want to hand-craft a file like a 14th century woodworker carving out letters on blocks. I want a program to just make the config or do the appropriate action for me, based on questions it asks me. I shouldn't have to write code to do that, or treat a file as code, or use a "language" to get work done, whenever it is possible (i.e. most of the time).
The only times I ever want a "language" is when I need to do something complex and iterative, like crafting a search query, or constructing a simple one-line pipeline of pre-defined functions. Aside from that, crafting configuration and performing operations should have a real user interface.
Re: In Defense of YAML
#44The YAML spec requiring turning "yes" "1" to true, and "no" "0" to false is one of the most aggravating things about YAML.
Also "on" and "off", and variations.
"y|Y|yes|Yes|YES|n|N|no|No|NO |true|True|TRUE|false|False|FALSE |on|On|ON|off|Off|OFF"
Re: In Defense of YAML
#45You can actually use Python as a configuration file pretty well, if you need more complicated logic and macros. Otherwise, sticking to a toml or ini file is my preference.
Are you gonna embed a Python interpreter into your C# programs though? Better to use something like dhall that's at least open to being loaded from multiple languages.
I like your point, it goes against the lambda-ultimate post linked separately in the thread. If you accept your point (cross-lang-loading) and accept the LTU argument about the benefits of internal DSLs (you're not slowly reinventing a useful turing-complete language) then you would maybe want to use a very simple, easily interpreted language for your DSL and embed an interpreter for that. (I (can't (think (of any though))))
Re: In Defense of YAML
#46> 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…
> being usable from any language is a really big boon.
Personally, I'm not particularly happy with the idea that I would use something inferior (like YAML) because various mainstream languages are bad and don't make more sophisticated languages possible.
Re: In Defense of YAML
#47The YAML spec requiring turning "yes" "1" to true, and "no" "0" to false is one of the most aggravating things about YAML.
I created a library that just ignores that part of the spec and parses everything that isn't defined in a schema as a string:
http://github.com/crdoconnor/strictyaml
It also does away with a few other anti-features (e.g. the object parsing that led to the epic RoR security hole) and there's a long justification for each.
I would like somehow to create a new spec out of this and see it implemented in programming languages other than python.
Re: In Defense of YAML
#48Earlier quoted context omitted.
I don't understand why people use a markup language when they need a programming language. I mean, sure, you can convert one into the other syntax-wise, both form trees, but what do you gain?
YAML = YAML aint't markup language Please don't give markup a bad name because of YAML, or the clusterfuck linked by GP.
You got me wrong here. I don't think markup languages are bad.
I just don't understand why someone would create such a "clusterfuck linked by my GP"
If you re-invent a programming language in markup, you basically get a new custom programming language that "probably" can do the same as another non-custom programming language, but without the benefit of many people already know them.
Why not integrate something like Lua or Dyon instead of YAML or XML?
Re: In Defense of YAML
#49Earlier quoted context omitted.
Are you gonna embed a Python interpreter into your C# programs though? Better to use something like dhall that's at least open to being loaded from multiple languages.
I like your point, it goes against the lambda-ultimate post linked separately in the thread. If you accept your point (cross-lang-loading) and accept the LTU argument about the benefits of internal DSLs (you're not slowly reinventing a useful turing-complete language) then you would maybe want to use a very simple, easily interpreted language for your DSL and embed an interpreter for that. (I (can't (think (of any th…
> then you would maybe want to use a very simple, easily interpreted language for your DSL
Right, which is essentially what Dhall is. There aren't any established "real" programming languages that are restricted enough (non-Turing complete, etc.) to use for this kind of case.
> (I (can't (think (of any though))))
S-expressions are never going to succeed; there are too many subtly incompatible variations going around already, and their fans are unwilling to compromise and agree on a common standard.
Re: In Defense of YAML
#50Earlier quoted context omitted.
I don't understand why people use a markup language when they need a programming language. I mean, sure, you can convert one into the other syntax-wise, both form trees, but what do you gain?
Because the tools only support markup languages, so we have to use stuff like Jinja or go templates to create those.
Sure thing, but Jinja looks like a garbage fire.
Why couldn't they use a regular programming language to create the markup? I mean this is done with HTML and JS all the time.