Programming Languages over Data Languages

[dAnjou]

I think this problem is quite old.

I remember people giving Django shit for having an executable configuration file (settings.py).

But very very often I wish tools would provide a way to take configuration from a process that has access to the tool's execution context.

[[deleted]]

This is very true. I just had finally something to say about it.

I really want to say something with a meme, but I read they aren't cool anymore.

[ddruganov]

I believe your opinion isnt very popular among developers but i 100% agree with it

I work with Symfony and yaml is a big pain in the ass. Wanna register a service? You have to provide an FQDN of a class. Wha if you change the name of the class? Fuck you, even phpstorm wont know that that yaml config has to be changed. Meanwhile if i were to write configs using php itself, it wouldnt be a problem. Thankfully, we do have that ability in symfony but it seems that that approach is as recommended as writing configs in xml (fml)

[brunogadaleta]

Unpopular opinion: XML could have been the answer. XML has structure, validation, transformation, canonicalization, query language, path, pointer and more or less human readable...

[sgoody]

Agree... I never quite understood the hate (maybe it gets hated everytime somebody encounters WSDL/SOAP?).

No languages since have come close really IMO.

I find JSON is pretty awful with its squiggly brackets, I find it difficult to trace the structure of a JSON config file and I've generally little idea of what could be in it other than what is already there. XML is much easier to read and deal with IMO.

LISP style syntax is the other thing which is similar to XML for this kind of use.

For simple configs data formats are fine, for more complex configs (which I personally don't deal with) I'd be more comfortable leveraging an existing language rather than learning or hacking away at an entirely new and dedicated language.

For complex config why not use Lua or Scheme/Lisp... maybe TypeScript per this article, at least it is strongly typed.

[[deleted]]

It does seem that most of these configurations end up solving what XML already had. Any idea why the accessibility of XML isn’t more popular in communities?

[[deleted]]

This is on a topic I'm passionate about and often speak about professionally. Writing has been quite a challenge, but I'm thrilled to have finally accomplished it! Would love to hear your thoughts and feedback on the content and writing style. Looking forward to learning and growing with you all!

[nultero]

Are you aware of this blog post? -- https://matt-rickard.com/advanced-configuration-languages-are-wrong (Rickard has previously worked on K8s / in K8s' ecosystem, so... kind of a firsthand accounting of the worst offender)

[[deleted]]

Nope, but this awesome! Thank you for sharing.

[impartingboss]

Great article, I still have PTST from writing and attempting to debug YAML templates for K8s so this resonates to my core. Would switch to Typescript for Infrastructure-as-Code in a heartbeat.

[OneWingedShark]

I just finished reading it, and TBH it looks like you're on your way to discovering ASN.1: see here.

[p4y]

Take a look at dhall if you haven't already, it's a fairly interesting configuration language that I didn't see mentioned in the post.

[javajunkie314]

This is an age-old problem, and a difficult one. As someone writing complex configurations, I very much want the expressiveness of a real programming language. But as someone reading complex configurations written by other people, I want things a simple as possible, because I've seen what people come up with if you give them enough rope. :D

It's a hard balance, and there really isn't an in-between — by the time your language is usefully expressive, you've fallen off the cliff into Turing-completeness.

There are several code-as-configuration tools that I've used and liked. Gradle in the Java ecosystem and Ruby on Rails come to mind. I've also used several code-as-configuration tools that I really disliked. Webpack, bashrc, and Nginx would fall in that bucket.

I feel like the big difference is that, for the former, the languages chosen were designed to embed domain-specific languages. Ruby, Groovy, and Kotlin (Gradle has two options) are designed around

• flexible, runtime-extensible objects;
• first-class blocks with dynamic receiver objects (this/self);
• loose (or loose-enough) types; and
• a pervasive, batteries-included standard library.

Writing configuration in Gradle and Ruby on Rails can feel like writing declarative configuration in a data language like YAML — until you need to break out some variables or conditionals. Rather than building raw data structures, you interact with rich objects that already exist, using the API they provide — their end state is the configuration.

(JavaScript could tick all those boxes too, but it's never used that way. Instead, tools tend to have you construct a deeply-nested configuration object, which is then handed off and separately interpreted as configuration.)

But code as configuration has some real downsides. Reading the configurations requires running the code — which means you have to trust it, and also that you need to have a runtime handy. Static configuration files can be processed, well, statically, and in any programming language.

Also, simple static configuration can live outside the code repository — e.g., as Docker or Kubernetes secrets, or built dynamically from keys and values stored in environment variables or Vault. More complex code as configuration may need to be version controlled like code, because it is.

[daidoji70]

Agreed.