5 ms·

There are a lot of problems in YAML, but I think the main real problem is trying to put logic inside configuration. YAML is still one of the nicest human-readab

There are a lot of problems in YAML, but I think the main real problem is trying to put logic inside configuration. YAML is still one of the nicest human-readable and -writeable data formats if it is only used for data and not logic. CI/CD always has some logic, and it's almost never in pure YAML but also has some weird templating going on. Like, please, couldn't you just have a real API for some real programming language.

nikeee 3y ago
In my experience, the more a language is able to do, the more it will be used in ways that overcomplicate stuff. People will just pull in abstractions because they think it is needed. This is why I always avoid using Turing complete programming languages as a configuration format. I've spent hours using a JavaScript debugger to step through AWS CDK. A simple, dumb yaml/Json/whatever file wouldn't have that problem (and it was a small project, the complexity wasn't needed). Sure, there might be use-cases where you need to be able to do more. But until now, I've never seen that. This is why I also prefer JSON over JS in JS tool configuration. This is why webpack configs get so messy. As soon as people can use a real language, their "DRY sensor" (or other bad applied paradigm sensor) triggers and they make things more complicated. Being declarative also makes it easier to follow standard practice and supports tooling. Imagine the package.json would actually be like a build.gradle. That would make things much worse.
- galangalalgol 3y ago
  I like toml even more than json, but the real issue to me is that we, or most of us, have this subtle drive to generalize, and the more things we can make comfigurable the better. But as it is said, when something is fully configurable that is like saying it isn't done and assembly is required. Also, we end up designing declarative domain specific languages. But I don't want to program in json, yaml, or toml. They aren't made for that, and it hurts me. For rust the clap crate helps put the brakes on if you agree on a simple rule, anything that is a config file parameter is a command line argument and environment variable. It is one struct that gets populated by the combination of those things. If you wouldn't make it one of them, don't make it any of them.
- tasuki 3y ago
  I've seen thousands and thousands of lines of copy-pasted YAML. "Oh you changed it in these 34 places but forgot to change this one and that one"
hitchstory 3y ago
That's not really a problem with YAML it's an abuse of YAML. Accidental turing completeness is a problem all over, too. I remember using Ant 15 years ago - built in XML. It was the same problem and that wasn't XML's I think a lack of type safety is the main problem with YAML - a wrong indentation, a typo in a key, a string that gets parsed as a boolean, etc. Other than that I think it's a great format - terse and far less syntactic noise than other formats. This is why I wrote https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml so people could write type safe yaml and get instantaneous, clear error messages on those things.
- bradrn 3y ago
  This reminds me of the Dhall configuration language: https://dhall-lang.org/ https://dhall-lang.org/
  - verdverm 3y ago
    I think more of JSON5, but the opposite direction
- PH95VuimJjqBqy 3y ago
  > That's not really a problem with YAML it's an abuse of YAML. absolutely true, but the same happened to XML. XML is actually awesome with tooling that hasn't been matched to this day (XSD, XSLT, just to name a few). But people abused it, it got a bad rap, browsers made JSON preferable, etc. But the point is that companies are using YAML for these things and we're starting to see attitudes shift just like they did when the industry went nuts and abused XML.
- Aerbil313 3y ago
  Nickel (https://nickel-lang.org/ https://nickel-lang.org/) is a new configuration language which builds upon lessons learnt from YAML, TOML, JSON, JSONNet, Nix and many others. It has optional types and logic (functions, variables) for when you need it.
  - 3y ago
globular-toast 3y ago
Executable config can bring huge wins. Python is an obvious choice. Just say, I'm going to run your script in a Python interpreter (in heavily limited cgroup) and your script must result in a dictionary called CONFIG. Some wrapper logic could then serialise that in whatever way is convenient for the program under configuration.
- kuchenbecker 3y ago
  Declarative vs imperative. Languages have state and behavior. I've had to convert 50k class-based schemas to a declarative DSL; the requirement is to be declarative, not rely on external state. and portable as-is with as little interpretation as possible. The flexibility of a language means some bug deep in a library will cause your infra to delete or misconfigureitself on accident. An API requires transactions or at the very least a read-modify-write cycle. The API need to always be up so engineers can merge their modifications to infrastructure. Recovery and undo is also a problem that needs to be solved so you need a system with point in time recovery. My Preference is to have an actual language generate what the system will do in a human-readable format, and you check that in, but Git and JSON or YAML with a Proto DSL act as the API, and then anything that can write a flat file can be used to configure your system.
  - globular-toast 3y ago
    Yeah, but we're adults and just because we can do something doesn't mean we have to. You can write shit code and you can write shit configs. Python can be written in a declarative style with perhaps a little magic sprinkled when pragmatic to do so. Completely banning imperative programming is like throwing out the baby with bath water.
- verdverm 3y ago
  So add python as a dependency to every project?
  - globular-toast 3y ago
    If the project could benefit from such a configuration, why not? It's not a super heavy dependency and most distros include it by default. Obviously doesn't make sense for every project, but something like a CI system or desktop window manager, sure.
moondev 3y ago
Why is "bad" schema design yaml's fault and not the schema designer? It's like complaining about complexity or rigidness of "helm". The helm charts do not write themselves. It seems like the issue is it's easier to complain than dismiss than understand and implement.
quickthrower2 3y ago
Get that YAML to call a bash or powershell script outside of the YAML as soon as humanly possible!
- verdverm 3y ago
  This is the bad trend emerging in Yaml based DSLs If you want to do things like that, use a real language and emit a final config value
  - quickthrower2 3y ago
    What if I didn't get to choose the CI system :-)
    - verdverm 3y ago
      Well I think you are asking in jest, there are some things you can do which amount to using it as minimally as possible. Basically make it as few steps as possible, using the minimal amount of options, and just call your own scripts. The secondary benefit of this is that you move towards a world where you can "run CI" locally. This is something I try to do with all my CI now. If you've ever pushed a stream of commits trying to fix a CI only bug, you'll really appreciate the green of the grass once you get to the other side :]
paulddraper 3y ago
> couldn't you just have a real API for some real programming language. What are you thinking? Like Jenkins Groovy plugin? I'd probably just hear how people hate Groovy.
- verdverm 3y ago
  CUE or Dhall are examples for config Dagger and Pulumi SDKs are examples of typical languages used to replace config languages for certain tasks
nrclark 3y ago
I agree with this 100%. When people talk about hating YAML, I think a lot of the time they really mean "I hate describing pipelines in YAML". And I get that because I feel it too. As a file-format, YAML has pros and cons. But the real problem is in trying to use a JSON-equivalent file format to describe things that have conditionals, loops, functions, and classes/subclasses (by way of templates). YAML is fine for small configurations. But it grows into a vendor-specific spaghetti mess very quickly, especially once you start to need any kind of control flow.

nikeee 3y ago

In my experience, the more a language is able to do, the more it will be used in ways that overcomplicate stuff. People will just pull in abstractions because they think it is needed. This is why I always avoid using Turing complete programming languages as a configuration format. I've spent hours using a JavaScript debugger to step through AWS CDK. A simple, dumb yaml/Json/whatever file wouldn't have that problem (and it was a small project, the complexity wasn't needed). Sure, there might be use-cases where you need to be able to do more. But until now, I've never seen that. This is why I also prefer JSON over JS in JS tool configuration. This is why webpack configs get so messy. As soon as people can use a real language, their "DRY sensor" (or other bad applied paradigm sensor) triggers and they make things more complicated. Being declarative also makes it easier to follow standard practice and supports tooling. Imagine the package.json would actually be like a build.gradle. That would make things much worse.

galangalalgol 3y ago
I like toml even more than json, but the real issue to me is that we, or most of us, have this subtle drive to generalize, and the more things we can make comfigurable the better. But as it is said, when something is fully configurable that is like saying it isn't done and assembly is required. Also, we end up designing declarative domain specific languages. But I don't want to program in json, yaml, or toml. They aren't made for that, and it hurts me. For rust the clap crate helps put the brakes on if you agree on a simple rule, anything that is a config file parameter is a command line argument and environment variable. It is one struct that gets populated by the combination of those things. If you wouldn't make it one of them, don't make it any of them.
tasuki 3y ago
I've seen thousands and thousands of lines of copy-pasted YAML. "Oh you changed it in these 34 places but forgot to change this one and that one"

hitchstory 3y ago

That's not really a problem with YAML it's an abuse of YAML. Accidental turing completeness is a problem all over, too. I remember using Ant 15 years ago - built in XML. It was the same problem and that wasn't XML's I think a lack of type safety is the main problem with YAML - a wrong indentation, a typo in a key, a string that gets parsed as a boolean, etc. Other than that I think it's a great format - terse and far less syntactic noise than other formats. This is why I wrote https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml so people could write type safe yaml and get instantaneous, clear error messages on those things.

bradrn 3y ago
This reminds me of the Dhall configuration language: https://dhall-lang.org/ https://dhall-lang.org/
- verdverm 3y ago
  I think more of JSON5, but the opposite direction
PH95VuimJjqBqy 3y ago
> That's not really a problem with YAML it's an abuse of YAML. absolutely true, but the same happened to XML. XML is actually awesome with tooling that hasn't been matched to this day (XSD, XSLT, just to name a few). But people abused it, it got a bad rap, browsers made JSON preferable, etc. But the point is that companies are using YAML for these things and we're starting to see attitudes shift just like they did when the industry went nuts and abused XML.
Aerbil313 3y ago
Nickel (https://nickel-lang.org/ https://nickel-lang.org/) is a new configuration language which builds upon lessons learnt from YAML, TOML, JSON, JSONNet, Nix and many others. It has optional types and logic (functions, variables) for when you need it.
- 3y ago

globular-toast 3y ago

Executable config can bring huge wins. Python is an obvious choice. Just say, I'm going to run your script in a Python interpreter (in heavily limited cgroup) and your script must result in a dictionary called CONFIG. Some wrapper logic could then serialise that in whatever way is convenient for the program under configuration.

kuchenbecker 3y ago
Declarative vs imperative. Languages have state and behavior. I've had to convert 50k class-based schemas to a declarative DSL; the requirement is to be declarative, not rely on external state. and portable as-is with as little interpretation as possible. The flexibility of a language means some bug deep in a library will cause your infra to delete or misconfigureitself on accident. An API requires transactions or at the very least a read-modify-write cycle. The API need to always be up so engineers can merge their modifications to infrastructure. Recovery and undo is also a problem that needs to be solved so you need a system with point in time recovery. My Preference is to have an actual language generate what the system will do in a human-readable format, and you check that in, but Git and JSON or YAML with a Proto DSL act as the API, and then anything that can write a flat file can be used to configure your system.
- globular-toast 3y ago
  Yeah, but we're adults and just because we can do something doesn't mean we have to. You can write shit code and you can write shit configs. Python can be written in a declarative style with perhaps a little magic sprinkled when pragmatic to do so. Completely banning imperative programming is like throwing out the baby with bath water.
verdverm 3y ago
So add python as a dependency to every project?
- globular-toast 3y ago
  If the project could benefit from such a configuration, why not? It's not a super heavy dependency and most distros include it by default. Obviously doesn't make sense for every project, but something like a CI system or desktop window manager, sure.

moondev 3y ago

Why is "bad" schema design yaml's fault and not the schema designer? It's like complaining about complexity or rigidness of "helm". The helm charts do not write themselves. It seems like the issue is it's easier to complain than dismiss than understand and implement.

quickthrower2 3y ago

Get that YAML to call a bash or powershell script outside of the YAML as soon as humanly possible!

verdverm 3y ago
This is the bad trend emerging in Yaml based DSLs If you want to do things like that, use a real language and emit a final config value
- quickthrower2 3y ago
  What if I didn't get to choose the CI system :-)
  - verdverm 3y ago
    Well I think you are asking in jest, there are some things you can do which amount to using it as minimally as possible. Basically make it as few steps as possible, using the minimal amount of options, and just call your own scripts. The secondary benefit of this is that you move towards a world where you can "run CI" locally. This is something I try to do with all my CI now. If you've ever pushed a stream of commits trying to fix a CI only bug, you'll really appreciate the green of the grass once you get to the other side :]

paulddraper 3y ago

> couldn't you just have a real API for some real programming language. What are you thinking? Like Jenkins Groovy plugin? I'd probably just hear how people hate Groovy.

verdverm 3y ago
CUE or Dhall are examples for config Dagger and Pulumi SDKs are examples of typical languages used to replace config languages for certain tasks

nrclark 3y ago

I agree with this 100%. When people talk about hating YAML, I think a lot of the time they really mean "I hate describing pipelines in YAML". And I get that because I feel it too. As a file-format, YAML has pros and cons. But the real problem is in trying to use a JSON-equivalent file format to describe things that have conditionals, loops, functions, and classes/subclasses (by way of templates). YAML is fine for small configurations. But it grows into a vendor-specific spaghetti mess very quickly, especially once you start to need any kind of control flow.