4 ms·

YAML is the new XML. Monstrous configurations used by some magic runtime to glue pieces together. Dependency injection frameworks were there already and decid

YAML is the new XML. Monstrous configurations used by some magic runtime to glue pieces together. Dependency injection frameworks were there already and decided against it at the end. I wish CI, data pipelines, config management, IaC tools and all other modern users of YAML-fits-everything approach learned from the past. What we need is an ease of creating mini languages, but apparently it is not something industry/academia is aiming at, so this skill in not existent among common engineers, which often come up with ideas of new products.

kfk 6y ago
HashiCorp is doing fine with config files in hcl or json. What’s your specific complain here? To me it seems your mini languages would anyway compile into something very similar to those yaml files. It’s all graph nodes in the end. But I do agree a language would be nicer when it comes to testing
m3h 6y ago
>Dependency injection frameworks were there already and decided against it at the end. How did dependency injection frameworks solve this problem then?
- modarts 6y ago
  By declaring dependencies in code (usually with annotations or decorators)
  - m3h 6y ago
    What do you do when you want to choose the implementation for dependencies and optionally configure them at runtime? I think that's why most of the popular dependency injection frameworks I see support configuration through XML or JSON.
    - atraac 6y ago
      Then you also do that in code? I don't see how that would differ. If your container doesn't support that, you can always just make a Factory for it.
    - HereBeBeasties 6y ago
      Firstly, you barely ever do. Secondly, unless you're selling compiled software for others to configure, there really is no difference between config in config files and config in code, except that the former does not let you build such meaningful and useful abstractions. You're presumably delivering it all into production via CI/CD anyway, so what difference editing a config file vs. some actual source code, besides the lack of real type safety and IDE assistance? Pulumi have figured this out. (And I suspect that if your end users need to configure your software's use of Spring's Dependency Injection in XML config then you are probably doing it wrong.)
      - verdverm 6y ago
        What exactly has Pulumi figured out? FWIU, their path is not the right one for DevOps. Dhall and Cue have the correct starting philosophy, i.e Turing incomplete
verdverm 6y ago
https://curlang.org https://curlang.org is amazing, I see devops going from YamHell to Cuetopia
- mdaniel 6y ago
  I believe the muscle memory from typing the name of an amazing http client overtook the URL you meant to type: https://cuelang.org/ https://cuelang.org/
jnwatson 6y ago
Language implementation has never been easier with Earley parsing. Your users still have to learn your new language. That’s the part designers are trying to avoid.

kfk 6y ago

HashiCorp is doing fine with config files in hcl or json. What’s your specific complain here? To me it seems your mini languages would anyway compile into something very similar to those yaml files. It’s all graph nodes in the end. But I do agree a language would be nicer when it comes to testing

m3h 6y ago

>Dependency injection frameworks were there already and decided against it at the end. How did dependency injection frameworks solve this problem then?

modarts 6y ago
By declaring dependencies in code (usually with annotations or decorators)
- m3h 6y ago
  What do you do when you want to choose the implementation for dependencies and optionally configure them at runtime? I think that's why most of the popular dependency injection frameworks I see support configuration through XML or JSON.
  - atraac 6y ago
    Then you also do that in code? I don't see how that would differ. If your container doesn't support that, you can always just make a Factory for it.
  - HereBeBeasties 6y ago
    Firstly, you barely ever do. Secondly, unless you're selling compiled software for others to configure, there really is no difference between config in config files and config in code, except that the former does not let you build such meaningful and useful abstractions. You're presumably delivering it all into production via CI/CD anyway, so what difference editing a config file vs. some actual source code, besides the lack of real type safety and IDE assistance? Pulumi have figured this out. (And I suspect that if your end users need to configure your software's use of Spring's Dependency Injection in XML config then you are probably doing it wrong.)
    - verdverm 6y ago
      What exactly has Pulumi figured out? FWIU, their path is not the right one for DevOps. Dhall and Cue have the correct starting philosophy, i.e Turing incomplete

verdverm 6y ago

https://curlang.org https://curlang.org is amazing, I see devops going from YamHell to Cuetopia

mdaniel 6y ago
I believe the muscle memory from typing the name of an amazing http client overtook the URL you meant to type: https://cuelang.org/ https://cuelang.org/

jnwatson 6y ago

Language implementation has never been easier with Earley parsing. Your users still have to learn your new language. That’s the part designers are trying to avoid.