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

81–90 of 111 posts

Re: A reasonable configuration language

#81

Post by anileated »

ianburrell wrote: post #66
skybrian wrote: post #65

Earlier quoted context omitted.

Sure, it doesn't allow side effects, but what can it depend on? If a file defines a language that downloads a dependency from a URL, does that count? How about if it's automatically cached? Once you start getting dependencies from others, it seems like a configuration language could drift into package management.

Downloading anything has side effects and can't be allowed by side effect free language. It is pretty rare that config language allow downloads. Downloading dependencies isn't usually done by config languages. Config languages generate a config, JSON or YAML, from source. The config file can be used by engine that applies the config including downloading dependencies.

Thinking inside the program, downloading dependencies certainly doesn’t need to have side effects. It may add new failure modes, that’s all.

If you step outside then sure, it has side effects, but so does simply running the program (any program), in 100% of the cases.

Re: A reasonable configuration language

#82

Post by aliasxneo »

paulddraper wrote: post #75
aliasxneo wrote: post #54

Earlier quoted context omitted.

> 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.

Because it is a (recent) solution to the problem ("how to easily loop, etc in Terraform"). There are Terraform alternatives...Cloudformation, Pulumi, Crossplane...but that's a separate matter.

Gotcha. I guess I see it more as an alternative rather than a modern evolution. I don't particularly like the direction of these SDKs, but I see an increasing demand for them.

Re: A reasonable configuration language

#83

Post by photonthug »

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…

Awesome description of really fundamental issues. It takes a lot experience to come to these kind of conclusions and people who haven't dug deeply into large enough code bases will never really believe it until they see it, and even then it can take a few rounds. So the config layer complexity keeps coming back while naive but well intentioned folks are striving in earnest for simplicity. It's tricky to argue the point also because either POV can sound like best practice, and decisive action in one direction also doesn't have effects that are immediately visible. It's a pretty long game to see what works best and we never feel the pain that we manage to dodge.

Re: A reasonable configuration language

#84

Post by teo_zero »

hnlmorg wrote: post #63
teo_zero wrote: post #43

Earlier quoted context omitted.

Would your language also accept this? list = %[ chair, table ] And this? list = %[ chair, table, ]

Yes it would: » %[ chair, table ] [ "chair", "table" ] » %[ chair, table, ] [ "chair", "table" ] Here you can see that internally it understands you're writing a JSON object however it relaxes the semantics a little (without going full on YAML) because chasing that erroneous comma is probably the least fun part of programming.

So, accepting the spurious comma at the end of the list and not requiring commas when there's a newline can coexist. I would say they are tho orthogonal properties. You can support the latter without opposing the former.

Re: A reasonable configuration language

#85

Post by eviks »

hnlmorg wrote: post #14

> It’s 2024, so RCL has some features that you might expect from a “modern” language: trailing commas I have the opposite opinion here. Commas should be like semi-colons: only required if you want multiple statements on a line. Eg fruit = [ “apples” “oranges” “bananas” ] No commas yet still extremely explicit

Why do you need a comma on a single line in 2024, you already have 2+1 extra symbols/value to separate: quotes and space

Re: A reasonable configuration language

#86

Post by notnmeyer »

mst wrote: post #47

For templating/generating YAML it's worth a look at https://yglu.io/ and ingy's latest piece of madness, https://yamlscript.org/ I make no claim that anybody who does look will like either of them, but I do claim they're worth a look even if it turns out that you don't.

I feel like just reading about these took years off my life.

Re: A reasonable configuration language

#87

Post by D-Coder »

teo_zero wrote: post #84
hnlmorg wrote: post #63

Earlier quoted context omitted.

Yes it would: » %[ chair, table ] [ "chair", "table" ] » %[ chair, table, ] [ "chair", "table" ] Here you can see that internally it understands you're writing a JSON object however it relaxes the semantics a little (without going full on YAML) because chasing that erroneous comma is probably the least fun part of programming.

So, accepting the spurious comma at the end of the list and not requiring commas when there's a newline can coexist. I would say they are tho orthogonal properties. You can support the latter without opposing the former.

Clearly, whether the language considers commas necessary or optional should be in a config file.

Re: A reasonable configuration language

#88

Post by hnlmorg »

teo_zero wrote: post #84
hnlmorg wrote: post #63

Earlier quoted context omitted.

Yes it would: » %[ chair, table ] [ "chair", "table" ] » %[ chair, table, ] [ "chair", "table" ] Here you can see that internally it understands you're writing a JSON object however it relaxes the semantics a little (without going full on YAML) because chasing that erroneous comma is probably the least fun part of programming.

So, accepting the spurious comma at the end of the list and not requiring commas when there's a newline can coexist. I would say they are tho orthogonal properties. You can support the latter without opposing the former.

Sure, but that’s not what the linked article discusses. It specifically states that commas are mandatory on each line. Not that the rule for commas is relaxed. And what I’m arguing is that requiring commas on each line is pushing the syntax in the wrong direction.

Re: A reasonable configuration language

#89

Post by hnlmorg »

eviks wrote: post #85
hnlmorg wrote: post #14

> It’s 2024, so RCL has some features that you might expect from a “modern” language: trailing commas I have the opposite opinion here. Commas should be like semi-colons: only required if you want multiple statements on a line. Eg fruit = [ “apples” “oranges” “bananas” ] No commas yet still extremely explicit

Why do you need a comma on a single line in 2024, you already have 2+1 extra symbols/value to separate: quotes and space

Well in my own language commas are entirely optional. They actually only exist for JSON compatibility (ie pasting JSON blobs into the language rather than transcribing the data). But I will concede that having a comma separated list on a single line does at least improve readability for some people. In that particular scenario we are drifting into the laws of diminishing returns and thus things become a lot more subjective.

However having a comma terminator when followed by a LF doesn’t. The whitespace is larger and more visible than the comma. In that scenario the comma doesn’t add enough visual distinction to add value to the syntax.

Re: A reasonable configuration language

#90

Post by eviks »

hnlmorg wrote: post #89
eviks wrote: post #85

Earlier quoted context omitted.

Why do you need a comma on a single line in 2024, you already have 2+1 extra symbols/value to separate: quotes and space

Well in my own language commas are entirely optional. They actually only exist for JSON compatibility (ie pasting JSON blobs into the language rather than transcribing the data). But I will concede that having a comma separated list on a single line does at least improve readability for some people. In that particular scenario we are drifting into the laws of diminishing returns and thus things become a lot more subj…

I don't mind some people thinking 1 is more readable than 2

    1fruit = ["apples","oranges","bananas"]

    2fruit = [apples       oranges         bananas]
was only talking about commas being required like semicolons since multiple statements use space within, so need something else unlike lists, so it's not comparable
Post reply on HN