3 ms·
There are probably two use cases. Configuration files for programs. These tend to be short. DSLs which are large manifests for things like cloud infrastructur
by dissent 1y ago
There are probably two use cases.
Configuration files for programs. These tend to be short.
DSLs which are large manifests for things like cloud infrastructure. These tend to be long, they grow over time.
My pet hypothesis is these DSLs exist mostly for neutrality - the vendor can't assume you have Python or something present. But as a user, you can assume just that and gain a lot by authoring in a proper language and generating YAML.
See https://github.com/cloudtools/troposphere https://github.com/cloudtools/troposphere for a great example for AWS CloudFormation.
- bigstrat2003 1y ago> Configuration files for programs. These tend to be short. This is where I use YAML and it shines there. IMO easier to read and write by hand than JSON, and short sweet config files don't have the various problems people run into with YAML. It's great.
- makeitdouble 1y agoI can't run the examples right now, but looking at the last "print(template.to_json())" line, looks like the main use case is JSON ? On cloud infra, yes, having one or two layers of languages is a natural situation. GCP and AWS both accepting (encouraging?) JSON as a subset of YAML makes it a simpler choice when choosing an auto generating target. You mention people wanting to author the generated files, I think in other situations tweaking the auto-generated files will be seen as riskier with potential overwriting issues, so lower readability will be seen as a positive.
- dissent 1y agoThat's the point really, you can generate JSON or YAML and it doesn't really matter. If you want to include 100 similar objects in that output, you can use a for loop. You can't do that in plain JSON/YAML.