At the bottom of that blog post:
> Djikstra
Dijkstra. Please!
In Defense of YAML
31–40 of 173 posts
Re: In Defense of YAML
#32I’m glad I read the internal vs external DSL discussion two links away from the article:
Re: In Defense of YAML
#33Slightly related, I just made a Webpack plugin that lets you use Markdown as configuration data: https://www.npmjs.com/package/mdconf-loader
I've been playing with ways of entering test data for years. At Triggerz where I have worked, we use Excel heavily. That works really well but I have to open Excel or LibreCalc to edit the files, which feels really slow and annoying compared to all other files that I can keep in my editor. There is a read-only plugin for VSCode but not yet one that lets me edit.
Markdown tables are quite easy to write when the editor supports them (i.e. auto-formatting), and work pretty well for me.
Re: In Defense of YAML
#34I really want a good "universal" configuration language (like https://dhall-lang.org/ ) that can be used to generate arbitrary text files (e.g. nginx configurations, JSON, YAML, etc.)
https://jsonnet.org/ exists and I've been playing around with a project that has similar goals https://ucg.marzhillstudios.com ucg is very much not ready for prime time yet but I think it's getting close.
Re: In Defense of YAML
#35You want to see a real abuse of YAML? Take a look at SaltStack's Jinja rendered YAML. I just grabbed a random forumla as an example: https://github.com/saltstack-formulas/openssh-formula/blob/m...
Where's the abuse? They're just generating a YAML with Jinja2. Is there something egregious about their YAML structure?
It's really easy to generate invalid YAML with a templating language if you aren't careful. If you like tooling that protects you from yourself and others mistakes then using a template language to generate YAML is going to ring warning bells for you.
Re: In Defense of YAML
#36You 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.
Hahahaha. No. I don't care to ever be forced to write a C# program. I write my applications in python, running in trusted environments. If I need optimized low-level code (which wouldn't be C# either), I access it as a library from within the python glue. Dynamically importing config files works extremely well.
Re: In Defense of YAML
#37You want to see a real abuse of YAML? Take a look at SaltStack's Jinja rendered YAML. I just grabbed a random forumla as an example: https://github.com/saltstack-formulas/openssh-formula/blob/m...
Where's the abuse? They're just generating a YAML with Jinja2. Is there something egregious about their YAML structure?
Because the linked example is code, not just configuration data.
And if I'm writing code, it should look like code you'd actually want to read and edit. Not something with hacked-on delimiters {%- all over the place %}.
Re: In Defense of YAML
#38You want to see a real abuse of YAML? Take a look at SaltStack's Jinja rendered YAML. I just grabbed a random forumla as an example: https://github.com/saltstack-formulas/openssh-formula/blob/m...
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.
Re: In Defense of YAML
#39I really want a good "universal" configuration language (like https://dhall-lang.org/ ) that can be used to generate arbitrary text files (e.g. nginx configurations, JSON, YAML, etc.)
So, my opinion is based only on perhaps 1h playing with it. I have mixed feelings about this. It's definitely neat, but I don't like that it adds quite a bit of cognitive overhead (again, this might be because I'm not fully used to it). I believe configurations shouldn't force you to think "how will this be rendered?". For my personal projects I started using protobuffer text formats as configurations. Having the proto definition is the only docs you need and you get meaningful errors when you misconfigured/forgot something.
Sure, the text format is quirky, but so far it works quite well for me and protobuffers (v3) can be easily rendered as JSON.
Re: In Defense of YAML
#40OK, I totally get the argument that YAML is for data and not programming. But I'm not sure the line between them is always clear. For example: I used to use YAML to define field mappings between external data and internal models in a Rails application. like: - src: fieldA dest: field_a filter: name_of_some_filter_function Is this programming? Data? Really it's configuration for an import library, but I find the line…
Imo that's data, except if the filter is an executable script. For me, the programming part in yaml is string, either single, array or multiline, that will be compiled, executed or eval-ed.
In your case, it can be defended as documentation for data mapping, but executable scripts are rarely so.