5 ms·

I've had a good long think about configuration languages, and after a long-term on/off love/hate relationship with schemas I think I've finally concluded that I

by kibwen 3y ago

I've had a good long think about configuration languages, and after a long-term on/off love/hate relationship with schemas I think I've finally concluded that I don't want rich types in my configs, thank you very much. I use statically-typed programming languages, and for my purposes I'd rather have a config language where the only types are strings, arrays, and hashmaps, and then push all type validation into the parsing stage.

giancarlostoro 3y ago
The only thing I want is very basic flow control / environment based code blocks and that’s it. I think nginx has a reasonable config language
acuozzo 3y ago
Reduce it further: strings and maps. Arrays can be represented as a map.
- ricardobeat 3y ago
  Strings can be represented as arrays too. Doesnt make a good argument for removing them.
  - acuozzo 3y ago
    Doing so would necessitate the addition of another type: character/grapheme cluster. Representing arrays as maps would impose no additional requirements outside of validation which is already considered as part of the proposal in question.
ajross 3y ago
That's my feeling too. Tools like this are trying to squeeze into the space between "straightforward configuration easily maintained in static files" and "complicated state management better served by real code in a real programming language". And that's a real hole for some applications, but it's a small hole. Basically forcing everyone to learn new tooling (Pkl here, but lots of json/yaml middleware nonsense fits the bill too) just to deal with what really isn't that big of a problem seems like a bad trade.
leapis 3y ago
I mostly agree with this, but I've been a big fan of having primitive types in config. Most of the time if I have something I want to configure, it's either one of the following (or a map/list-based structure consisting of): - scalar value - feature toggle - URI/enum option/human readable display text Having float/long/boolean is trivial to validate in the config language itself, and if they're useful and simple enough isn't it nice to be able to validate your config as early as possible?
- youerbt 3y ago
  It's nice, but it comes at a cost. For example, every user of toml forever will have to put strings in quotes. Why? Because having other types creates ambiguity, that is resolved by this one simple trick. But if you don't quote them then you have "the Norway problem" like in yaml.
avianlyric 3y ago
Guess the obvious question is why don’t you want types in your config language? Pushing all the validation to parsing state just makes it hard to write valid config, because you only know if the config is valid when you feed it into your program. Having the ability to pull all that validation forward, and into your IDE, means you can be told about invalid config as you’re writing it. To me the idea of only wanting to validate config at the last possible moment, is a bit like advocating for only using simple text editors, and replying purely on build failures for feedback. Sure you can do it, but why would subject yourself to that? Pkl is interesting because it makes it possible to describe not just the types, but also valid configs. Effectively allowing you to ship your applications config parsing and validation into Pkl, so your code can just expect valid config. Then Pkl can expose all that parsing and validation logic into your IDE, so you get pointers as you type. Just like you do in any modern IDE for any modern language.
- youerbt 3y ago
  My take on this is that there is not obvious reason not to, but it just so happens that typed configuration languages are not rich enough and not integrated enough to be that useful. Those languages that arrived with the JSON hype train like yaml or toml might be great for dynamic languages, where you can load them to some native object. But in statically typed languages you are gonna declare your types, in code, anyway. So configuration providing types doesn't really do much.
  - jen20 3y ago
    The whole _point_ of Pkl is that it is both rich enough and integrated enough though?
    - youerbt 3y ago
      Oh, I didn't comment on the Pkl, just on the status quo. My bad for not making that clear. "Enough" is the keyword here, time will tell I guess.
  - avianlyric 3y ago
Spivak 3y ago
Sounds like you and the INI guy agree here and honestly I'm coming around to it because for complex types you end up typing everything twice. https://github.com/madmurphy/libconfini/wiki/An-INI-critique-of-TOML https://github.com/madmurphy/libconfini/wiki/An-INI-critique...
garethrowlands 3y ago
You're saying you don't want red squigglies in your IDE when you do your configuration wrong? Why?
bioballer 3y ago
I think this is a reasonable approach if you only have one stack, and don't have a lot of config. If you have one stack, you can put all the validation, types, and everything else in your runtime application, and then you don't need to learn new languages, and everything works. This becomes a lot more painful if your work is more polyglot. If you need to define config that needs to be shared between different applications, but they're written in different languages, you'll have a much harder time. Also, say, if you need to deploy your applications to Kubernetes, and your Kubernetes specification needs to provide config files to your application, then you'll still end up in a situation where your statically typed programming language won't help. That is where something like Pkl becomes really helpful, because you have just one place to manage all that complexity--right in Pkl itself.

by kibwen 3y ago

giancarlostoro 3y ago

The only thing I want is very basic flow control / environment based code blocks and that’s it. I think nginx has a reasonable config language

acuozzo 3y ago

Reduce it further: strings and maps. Arrays can be represented as a map.

ricardobeat 3y ago
Strings can be represented as arrays too. Doesnt make a good argument for removing them.
- acuozzo 3y ago
  Doing so would necessitate the addition of another type: character/grapheme cluster. Representing arrays as maps would impose no additional requirements outside of validation which is already considered as part of the proposal in question.

ajross 3y ago

That's my feeling too. Tools like this are trying to squeeze into the space between "straightforward configuration easily maintained in static files" and "complicated state management better served by real code in a real programming language". And that's a real hole for some applications, but it's a small hole. Basically forcing everyone to learn new tooling (Pkl here, but lots of json/yaml middleware nonsense fits the bill too) just to deal with what really isn't that big of a problem seems like a bad trade.

leapis 3y ago

I mostly agree with this, but I've been a big fan of having primitive types in config. Most of the time if I have something I want to configure, it's either one of the following (or a map/list-based structure consisting of): - scalar value - feature toggle - URI/enum option/human readable display text Having float/long/boolean is trivial to validate in the config language itself, and if they're useful and simple enough isn't it nice to be able to validate your config as early as possible?

youerbt 3y ago
It's nice, but it comes at a cost. For example, every user of toml forever will have to put strings in quotes. Why? Because having other types creates ambiguity, that is resolved by this one simple trick. But if you don't quote them then you have "the Norway problem" like in yaml.

avianlyric 3y ago

Guess the obvious question is why don’t you want types in your config language? Pushing all the validation to parsing state just makes it hard to write valid config, because you only know if the config is valid when you feed it into your program. Having the ability to pull all that validation forward, and into your IDE, means you can be told about invalid config as you’re writing it. To me the idea of only wanting to validate config at the last possible moment, is a bit like advocating for only using simple text editors, and replying purely on build failures for feedback. Sure you can do it, but why would subject yourself to that? Pkl is interesting because it makes it possible to describe not just the types, but also valid configs. Effectively allowing you to ship your applications config parsing and validation into Pkl, so your code can just expect valid config. Then Pkl can expose all that parsing and validation logic into your IDE, so you get pointers as you type. Just like you do in any modern IDE for any modern language.

youerbt 3y ago
My take on this is that there is not obvious reason not to, but it just so happens that typed configuration languages are not rich enough and not integrated enough to be that useful. Those languages that arrived with the JSON hype train like yaml or toml might be great for dynamic languages, where you can load them to some native object. But in statically typed languages you are gonna declare your types, in code, anyway. So configuration providing types doesn't really do much.
- jen20 3y ago
  The whole _point_ of Pkl is that it is both rich enough and integrated enough though?
  - youerbt 3y ago
    Oh, I didn't comment on the Pkl, just on the status quo. My bad for not making that clear. "Enough" is the keyword here, time will tell I guess.
- avianlyric 3y ago

Spivak 3y ago

Sounds like you and the INI guy agree here and honestly I'm coming around to it because for complex types you end up typing everything twice. https://github.com/madmurphy/libconfini/wiki/An-INI-critique-of-TOML https://github.com/madmurphy/libconfini/wiki/An-INI-critique...

garethrowlands 3y ago

You're saying you don't want red squigglies in your IDE when you do your configuration wrong? Why?

bioballer 3y ago

I think this is a reasonable approach if you only have one stack, and don't have a lot of config. If you have one stack, you can put all the validation, types, and everything else in your runtime application, and then you don't need to learn new languages, and everything works. This becomes a lot more painful if your work is more polyglot. If you need to define config that needs to be shared between different applications, but they're written in different languages, you'll have a much harder time. Also, say, if you need to deploy your applications to Kubernetes, and your Kubernetes specification needs to provide config files to your application, then you'll still end up in a situation where your statically typed programming language won't help. That is where something like Pkl becomes really helpful, because you have just one place to manage all that complexity--right in Pkl itself.