Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A reasonable configuration language

ruudvanasseldonk.com

Post reply on HN
Print view View original

51–60 of 111 posts

Re: A reasonable configuration language

#51

Post by catlifeonmars »

civilized wrote: post #8

I have seen many of these posts now and I have a simple question. Why do we need special configuration languages? Why not just use existing languages? I understand why data formats like JSON and YAML are valuable, and I understand why it would be valuable to use a programming language to automate the generation of such formatted data. But the niche of the configuration language remains mysterious to me.

There’s no smooth gradient between data format and Turing complete programming language. Let’s say I want environment conditional logic (such as looking up a map of AMIs to AWS regions), but don’t want to allow arbitrary code execution, or I want to embed the parser inside the service that accepts the config. Those are the niches that HCLs fill.

A programming language that allows you to enable language constructs individually might be interesting (imagine being able to easily turn on list comprehensions but not allow imports or to disable mutation).

Re: A reasonable configuration language

#52

Post by unilynx »

OJFord wrote: post #41
hnlmorg wrote: post #20

Earlier quoted context omitted.

I got what they were saying. My point is that if you have a line feed then a comma is an entirely redundant piece of syntax. Commas should only be needed if you are placing multiple statements on a single line. Just like how several programming languages treat semi-colons (eg Go, bash, JavaScript, etc). So mandating them is the opposite of that modern languages should be insisting upon. In Murex (my own language) bot…

It's only redundant in languages that make it redundant, like you mentioned C at the end - it's the new line that's redundant there (or only for readability), it's the semicolon with the 'end' semantics.

In this specific case it's not redundant in C - without the commas, the strings would be merged together.

Re: A reasonable configuration language

#53

Post by paulddraper »

OJFord wrote: post #39
paulddraper wrote: post #28

> I was struggling with that day was to define six cloud storage buckets in Terraform...The kind of thing you’d do with a two-line nested loop in any general-purpose language I understand this is just an example, but FYI the modern solution is to use CDKTF rather than HCL for Terraform. That allows you to choose your favorite general purpose lang: Python, TypeScript, Go, Java, C#.

I use Terraform because of HCL, the absolute best thing about it is the declarative config; if someone insists on using their favourite general purpose language: 1) they're wrong; 2) there's plenty of other options for that and I'm not interested in fighting in Terraform's corner knowing they won't use it for the most fundamental reason it's good.

So, your reply to Ruud is "you're holding it wrong" or "it actually fine you just think it isn't"?

Re: A reasonable configuration language

#54

Post by aliasxneo »

paulddraper wrote: post #28

> I was struggling with that day was to define six cloud storage buckets in Terraform...The kind of thing you’d do with a two-line nested loop in any general-purpose language I understand this is just an example, but FYI the modern solution is to use CDKTF rather than HCL for Terraform. That allows you to choose your favorite general purpose lang: Python, TypeScript, Go, Java, C#.

> but FYI the modern solution is to use CDKTF rather than HCL for Terraform.

That's an odd take. Are you saying that because it's newer? I would push something like Crossplane as more "modern" in that it solves the critical issue of Terraform not having any sort of reconciliation loop.

Re: A reasonable configuration language

#55

Post by MrDarcy »

zer00eyz wrote: post #37
Kinrany wrote: post #24

Earlier quoted context omitted.

Are you suggesting that all configuration should be dynamic and multi-tenant (for the lack of a better word), not happen at startup?

Scripting a config file. Templates for config. We did this already, xml, XSD, XSLT, DOM... It sucked. Config should be easy and flat and simple. IF it isnt that source it from code, or from a service... Most of the nonsense of config madness is a byproduct of, or hidden in, containers. If we were writing installable software much of that would go away...

What’s this magical config service do? Take data in from a request and return transformed data back in response to configure the caller? What is the essential difference between this config service and existing config languages?

Re: A reasonable configuration language

#56

Post by heads »

Configuration languages are an interface to the API presented by the software you are using. There can be a hard boundary between the two — a C codebase for a web server and the XML-like file that configured it — or there can be an imperceptible transition between the two where the configuration is just another module in the code base.

As one of the authors working in a 2000+ module Python codebase, nothing gives me greater pleasure than to drive one part of the codebase by creating another module. Nothing gives me greater sadness than to be forced to interact with something through a YAML config file, command line flags, or launching GitLab pipelines. All three of those boundaries interrupt the powerful electromagnetic force fields that pervade the system: type checking, linting, and symbol finding (IDE integration). In time, I vow to destroy every last one of these non-code boundaries. Another unwanted-boundary demon on the exorcism list is polyrepos.

There once was a time when the world worked like this but instead of Python it was C. It wasn’t as rich as the dynamic world we have today — I’m certain I don’t want to go back to configuring my softest by recompiling it — but it did have a lot of the advantages of working in one language environment across all the things.

Re: A reasonable configuration language

#57

Post by patrickmay »

catlifeonmars wrote: post #51
civilized wrote: post #8

I have seen many of these posts now and I have a simple question. Why do we need special configuration languages? Why not just use existing languages? I understand why data formats like JSON and YAML are valuable, and I understand why it would be valuable to use a programming language to automate the generation of such formatted data. But the niche of the configuration language remains mysterious to me.

There’s no smooth gradient between data format and Turing complete programming language. Let’s say I want environment conditional logic (such as looking up a map of AMIs to AWS regions), but don’t want to allow arbitrary code execution, or I want to embed the parser inside the service that accepts the config. Those are the niches that HCLs fill. A programming language that allows you to enable language constructs ind…

> There’s no smooth gradient between data format and Turing complete programming language.

S-expressions beg to differ.

Re: A reasonable configuration language

#58

Post by somewhereoutth »

heads wrote: post #56

Configuration languages are an interface to the API presented by the software you are using. There can be a hard boundary between the two — a C codebase for a web server and the XML-like file that configured it — or there can be an imperceptible transition between the two where the configuration is just another module in the code base. As one of the authors working in a 2000+ module Python codebase, nothing gives me…

This, but with Javascript. Perhaps the 'electromagnetic force fields' are less powerful, but the array and object literals are perfect for configuration.

Re: A reasonable configuration language

#59

Post by OJFord »

unilynx wrote: post #52
OJFord wrote: post #41

Earlier quoted context omitted.

It's only redundant in languages that make it redundant, like you mentioned C at the end - it's the new line that's redundant there (or only for readability), it's the semicolon with the 'end' semantics.

In this specific case it's not redundant in C - without the commas, the strings would be merged together.

Exactly, that's what I said? 'In this specific case' though? It would be news to me (not that I've used it since university!) that they're ever non-semantic?

Re: A reasonable configuration language

#60

Post by OJFord »

paulddraper wrote: post #53
OJFord wrote: post #39

Earlier quoted context omitted.

I use Terraform because of HCL, the absolute best thing about it is the declarative config; if someone insists on using their favourite general purpose language: 1) they're wrong; 2) there's plenty of other options for that and I'm not interested in fighting in Terraform's corner knowing they won't use it for the most fundamental reason it's good.

So, your reply to Ruud is "you're holding it wrong" or "it actually fine you just think it isn't"?

No, principally because although he writes:

> Aside from Nix, Python, and HCL, which I’ve already discussed extensively,

He doesn't seem to have much more to say about the latter than that.

'My reply', bluntly, is something like 'maybe it has shortcomings, you haven't addressed them; its most fundamental key advantage is not addressed at all, about it or any other language, and is not a feature of your new one'.

Post reply on HN