7 ms·

I think the only exit to this cycle is something like dhall, which adds features like functions and imports, but is "total" / forbids side-effects. https://dhal

I think the only exit to this cycle is something like dhall, which adds features like functions and imports, but is "total" / forbids side-effects. https://dhall-lang.org/ https://dhall-lang.org/

AlphaSite 6y ago
YTT is pretty nice too and basically glues star lark and yaml together.
- sofixa 6y ago
  via comments! YAML is an abomination in itself ( spaces for logic?!), the last thing it needed was comments for extra logic.
  - xdennis 6y ago
    Proper spacing makes code readable. Forcing it is a good thing.
    - guipsp 6y ago
      It's a good thing, until you ask a non-technical user to edit the config file. Then they become confused because a tab is visually, but not functionally equivalent to a number of spaces.
      - erinnh 6y ago
        I wouldnt ask a non-technical person to write any of these config files. If I want non-technical people to configure something I need to write a GUI for self-serving.
    - sofixa 6y ago
      Indeed, it does, when done via something like go fmt. But in the case of YAML, a pedantic level of "proper spacing" is used for logic. 2 or 3 spaces shouldn't change the meaning and order of things
  - AlphaSite 6y ago
    Not actually via comments, they just use the same syntax, im pretty sure the pretemplated code is not actually valid yaml.
mirekrusin 6y ago
Or cuelang
pydry 6y ago
This is deeply misguided, I think. Dhall is a neat hack, but it's still a hack. Any and all attempts to munge YAML or to turn YAML into something Turing complete are signals that a scripting language would have been a better fit for the problem. The exit to this cycle is: * to use configuration languages for things that are genuinely configuration now and always * scripting language APIs for things that are genuinely not configuration (e.g. build systems). * provide both for domains that are genuinely mixed (a lot of kubernetes probably fits into this category - some things are configuration for some people and dynamic or generated for others). It sounds simple but it is hard - the correct border between config and code is usually hard to perceive and how your tools end up being used is inherently unpredictable.
- protomikron 6y ago
  Dhall is not turing-complete. That's the whole point.
  - pydry 6y ago
    That was incidental to dhall. Dhall doesn't and was never intended to help clean up the mess made by having ansible code be Turing complete (for example). I'm pretty sure the whole point of dhall is to DRY out configuration files and to hack on type guarantees to config files. I played with it for a bit and those are the only two use cases I could find. Those two use cases usually come encumbered with several others which it does not help with at all, but a scripting language would. A good, refactored-to-be-DRY config file that is typesafe completely obliviates any need for dhall and if you've got a Turing complete YAML monstrosity it's not going to help much. It reminds me a bit of XSLT (except that was accidentally Turing complete of course).
    - infogulch 6y ago
      This comment doesn't make any sense to me > A good, refactored-to-be-DRY config file that is typesafe completely obliviates any need for dhall and if you've got a Turing complete YAML monstrosity it's not going to help much. Dhall is a "refactored-to-be-DRY config file that is typesafe", and the host of safety-related features ( https://docs.dhall-lang.org/discussions/Safety-guarantees.html https://docs.dhall-lang.org/discussions/Safety-guarantees.ht... ) make this practical to implement, even while evaluating untrusted & potentially malicious dhall code. These guarantees are much stronger than what nearly any other config or scripting language provides.
erikds 6y ago
I would put my money on lisp. The structure of data and code is the same. The result is that you start with configuration. But you all ways have a nice escape hatch
- infogulch 6y ago
  Too much escape hatch. I would prefer my configuration to be less than turing complete, tyvm.

I think the only exit to this cycle is something like dhall, which adds features like functions and imports, but is "total" / forbids side-effects. https://dhall-lang.org/ https://dhall-lang.org/

AlphaSite 6y ago

YTT is pretty nice too and basically glues star lark and yaml together.

sofixa 6y ago
via comments! YAML is an abomination in itself ( spaces for logic?!), the last thing it needed was comments for extra logic.
- xdennis 6y ago
  Proper spacing makes code readable. Forcing it is a good thing.
  - guipsp 6y ago
    It's a good thing, until you ask a non-technical user to edit the config file. Then they become confused because a tab is visually, but not functionally equivalent to a number of spaces.
    - erinnh 6y ago
      I wouldnt ask a non-technical person to write any of these config files. If I want non-technical people to configure something I need to write a GUI for self-serving.
  - sofixa 6y ago
    Indeed, it does, when done via something like go fmt. But in the case of YAML, a pedantic level of "proper spacing" is used for logic. 2 or 3 spaces shouldn't change the meaning and order of things
- AlphaSite 6y ago
  Not actually via comments, they just use the same syntax, im pretty sure the pretemplated code is not actually valid yaml.

mirekrusin 6y ago

Or cuelang

pydry 6y ago

This is deeply misguided, I think. Dhall is a neat hack, but it's still a hack. Any and all attempts to munge YAML or to turn YAML into something Turing complete are signals that a scripting language would have been a better fit for the problem. The exit to this cycle is: * to use configuration languages for things that are genuinely configuration now and always * scripting language APIs for things that are genuinely not configuration (e.g. build systems). * provide both for domains that are genuinely mixed (a lot of kubernetes probably fits into this category - some things are configuration for some people and dynamic or generated for others). It sounds simple but it is hard - the correct border between config and code is usually hard to perceive and how your tools end up being used is inherently unpredictable.

protomikron 6y ago
Dhall is not turing-complete. That's the whole point.
- pydry 6y ago
  That was incidental to dhall. Dhall doesn't and was never intended to help clean up the mess made by having ansible code be Turing complete (for example). I'm pretty sure the whole point of dhall is to DRY out configuration files and to hack on type guarantees to config files. I played with it for a bit and those are the only two use cases I could find. Those two use cases usually come encumbered with several others which it does not help with at all, but a scripting language would. A good, refactored-to-be-DRY config file that is typesafe completely obliviates any need for dhall and if you've got a Turing complete YAML monstrosity it's not going to help much. It reminds me a bit of XSLT (except that was accidentally Turing complete of course).
  - infogulch 6y ago
    This comment doesn't make any sense to me > A good, refactored-to-be-DRY config file that is typesafe completely obliviates any need for dhall and if you've got a Turing complete YAML monstrosity it's not going to help much. Dhall is a "refactored-to-be-DRY config file that is typesafe", and the host of safety-related features ( https://docs.dhall-lang.org/discussions/Safety-guarantees.html https://docs.dhall-lang.org/discussions/Safety-guarantees.ht... ) make this practical to implement, even while evaluating untrusted & potentially malicious dhall code. These guarantees are much stronger than what nearly any other config or scripting language provides.

erikds 6y ago

I would put my money on lisp. The structure of data and code is the same. The result is that you start with configuration. But you all ways have a nice escape hatch

infogulch 6y ago
Too much escape hatch. I would prefer my configuration to be less than turing complete, tyvm.