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

11–20 of 111 posts

Re: A reasonable configuration language

#11

Post by stevekemp »

AtlasBarfed wrote: post #2

The configuration rabbit hole, for practically any system that becomes widely applied or through large amounts of feature iterations. With provisioning systems you rapidly walk the ladder because they are basically starting about five steps down on this already: You start with an INI/yaml/json Then you might have several overlaid INIs Eventually: https://docs.spring.io/spring-boot/docs/2.1.13.RELEASE/refer... Go ahea…

It's scary to think how many times I've had to evolve configuration options as systems developed and the user-base changed.

As you say, I'd start out with INI files, then move on to JSON, after that it would come a hack to allow the JSON to be generated by executing a shell/ruby/perl script. (i.e. "--config=!xx" would execute XX and parse the output, instead of reading a file).

Later still we started embedding lua, or similar, to allow things to be templated and "dynamic" on a per-host basis.

I was always fond of the Apache-style configuration system, and I guess HCL is close to that, but there aren't any great universal solutions unless you go all-in with scripting, and then you end up with emacs!

Re: A reasonable configuration language

#12

Post by qznc »

AtlasBarfed wrote: post #2

The configuration rabbit hole, for practically any system that becomes widely applied or through large amounts of feature iterations. With provisioning systems you rapidly walk the ladder because they are basically starting about five steps down on this already: You start with an INI/yaml/json Then you might have several overlaid INIs Eventually: https://docs.spring.io/spring-boot/docs/2.1.13.RELEASE/refer... Go ahea…

I defined myself 5 levels:

Level 1 is just values in a file. The Linux kernel uses that.

Level 2 is a list of values, e.g. ini files.

Level 3 allows nesting. JSON, XML, and YAML are here.

Level 4 allows computation but limited. Dhall and Starlark are here.

Level 5 is a Turing-complete language. Python, Javascript, etc.

RCL seems to be level 5, so I'm not sure if there is really an advantage compared to Python.

Re: A reasonable configuration language

#13

Post by aleksiy123 »

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.

I think because there are some desirable traits for config languages that don't exist in general purpose languages.

Not exhaustive list but generally:

Usually constrained to reduce complexity and try to eliminate the need for testing config.

Interopable between many different programming languages.

Readable by programmers working in different languages.

I think this usually makes config languages favour declarative over imperative which usually eliminates most general purpose languages.

Another topic is why do we use configuration at all and what is the difference between code and config.

Re: A reasonable configuration language

#14

Post by hnlmorg »

> 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

Re: A reasonable configuration language

#15

Post by gary_0 »

AtlasBarfed wrote: post #2

The configuration rabbit hole, for practically any system that becomes widely applied or through large amounts of feature iterations. With provisioning systems you rapidly walk the ladder because they are basically starting about five steps down on this already: You start with an INI/yaml/json Then you might have several overlaid INIs Eventually: https://docs.spring.io/spring-boot/docs/2.1.13.RELEASE/refer... Go ahea…

I wonder if anyone would take me seriously if I suggested WASM as a configuration language. When run, the WASM would be given imports that provide a small API for manipulating the config DOM, and importing and executing further WASM files. Then you can use whatever high-level config language you want (or, say, a subset of Rust) and compile it to WASM.

Existing JSON/YAML/etc could be compiled to WASM that simply builds the corresponding DOM.

Funny joke?

Re: A reasonable configuration language

#16

Post by mcphage »

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

That’s not really the opposite opinion… the opposite is not allowing trailing commas (like JSON) so if you remove the last item from a list, you need to adjust the line above as well. And when you add something to a list, you need to know if something will come after it, even though you don’t necessarily know.

Commas as separator is pretty much orthogonal, and… well, better overall.

Re: A reasonable configuration language

#17

Post by notfed »

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.

I think NixOS/Nix is a good example of where we need one. Nix is used for a massive amount of configuration which needs to be functional and turing-complete. Nix is pretty nice and compact as a configuration language, but the "programming language" aspect of Nix, IMO is ugly and unreadable, and could have been designed better.

Re: A reasonable configuration language

#18

Post by DrBazza »

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.

Don't repeat yourself / single-point-of-truth. Config files can be full of repetition, from values, to sections/objects. Defining a value or object once, dramatically reduces search+replace errors for example.

Re: A reasonable configuration language

#19

Post by rco8786 »

DrBazza wrote: post #18
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.

Don't repeat yourself / single-point-of-truth. Config files can be full of repetition, from values, to sections/objects. Defining a value or object once, dramatically reduces search+replace errors for example.

Is that mutually exclusive with using your normal programming language as a config language?

Re: A reasonable configuration language

#20

Post by hnlmorg »

mcphage wrote: post #16
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

That’s not really the opposite opinion… the opposite is not allowing trailing commas (like JSON) so if you remove the last item from a list, you need to adjust the line above as well. And when you add something to a list, you need to know if something will come after it, even though you don’t necessarily know. Commas as separator is pretty much orthogonal, and… well, better overall.

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) both commas and semi-colons can be dropped if the statement or expression is terminated by a line feed.

    list = %[
        chair
        table
        “bed-side table”
    ]
YAML, for all of its warts, also behaves similarly too.

It’s a much better way to handle lists and objects because the comma only exists for the same reason the semi-colon does in C-like syntax: as a parser hint. But if you’ve got a new line then that hint is completely redundant.

Post reply on HN