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

61–70 of 111 posts

Re: A reasonable configuration language

#61

Post by viktree »

gary_0 wrote: post #15
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 build…

I think this is what the zellij terminal multiplexer uses for extensions.

It's worth mentioning that in the opposite direction, if you wanted to have an interpreted config option with fewer compile steps, there's also the option to use lua — a language for which the compiler itself is quite small and portable

See,

[1] : https://zellij.dev

Re: A reasonable configuration language

#62

Post by hnlmorg »

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.

> It's only redundant in languages that make it redundant

Yeah, I did say "several" not "all".

There is very little benefit in new languages making terminator tokens necessary when followed by LF. We are long past the point of needing to optimise language syntax for parser efficiency.

Re: A reasonable configuration language

#63

Post by hnlmorg »

teo_zero wrote: post #43
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…

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.

Re: A reasonable configuration language

#64

Post by sanderjd »

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…

Diff'rent strokes for diff'rent folks (and diff'rent use cases)...

For me, the panacea is to be able to easily do both. I want to be able to use an application as a library from a repl or script by "configuring" it via dataclasses. And I want to be able to run the same application from a cli in different configurations in different production environments by checking in sets of config files that I know are more constrained in what they can do than a generic python runtime.

There's no fundamental reason it is hard to expose both of these interfaces without repeating yourself a bunch!

Re: A reasonable configuration language

#65

Post by skybrian »

habitue wrote: post #22

I know the standard response is "why another one?" but honestly, his diagnosis of the existing options is pretty good. He even uses the best examples of thoughtfully designed config languages: cue, dhall and nix, and ... yeah I pretty much agree with his qualms about those languages. What is a config language really? It's a language that doesn't allow side effects and evaluates to json.

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.

Re: A reasonable configuration language

#66

Post by ianburrell »

skybrian wrote: post #65
habitue wrote: post #22

I know the standard response is "why another one?" but honestly, his diagnosis of the existing options is pretty good. He even uses the best examples of thoughtfully designed config languages: cue, dhall and nix, and ... yeah I pretty much agree with his qualms about those languages. What is a config language really? It's a language that doesn't allow side effects and evaluates to json.

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.

Re: A reasonable configuration language

#67

Post by danenania »

Jtsummers wrote: post #48
danenania wrote: post #33

Earlier quoted context omitted.

You can compile your general purpose language DSL to json and then I think this isn’t too much of a problem. A bigger issue imo is packaging. General purpose languages aren’t typed well-designed for producing single, understandable standalone files like config languages are. Like I think a simple config DSL in TypeScript could potentially be a perfect way to solve this problem, except that no one wants to lug around…

So turn the general purpose language into a non-general purpose language by creating a compiler for a subset of it. That might be what we'd call a configuration language then since it's no longer actually the original language (in full). Like JSON and others.

It’s not really a subset that I’m talking about—just a DSL that outputs JSON for easy portability. You could still use all the language’s features.

Re: A reasonable configuration language

#68

Post by stakhanov »

lolinder wrote: post #7

Reading through this I'm reminded of another article from about a month ago, An app can be a home-cooked meal [0]. Whenever someone starts on a new language or framework, people are quick to ask "why" and bemoan the proliferation of languages and frameworks. I think this article is a good illustration of the "why". What the author understands that so many don't is that a language can be a home-cooked meal. A programm…

> a language can be a home-cooked meal [...] a tool for use by a programmer [...] a pipeline that transforms a data structure from a format that the human would prefer to interact with into a format that a specific machine can work with.

You're neglecting the second function that a language serves, which is as a communication device to communicate a program from one human being to another, and in that second function, a language is utterly useless if it lacks critical mass in terms of how many people "speak" it. This runs completely counter to the "home-cooked meal" model.

You run into problems, even if you only have one human being trying to communicate the program to their future self, because there's a tendency to forget a language you don't use regularly, so you might cook up a very brilliant language to solve a problem that you have right now, but that you don't have sufficiently frequently. So you don't practice the language regularly, and then you come back 10 years later and want to change something about the program and you might find yourself in trouble.

Re: A reasonable configuration language

#70

Post by deepsun »

> The kind of thing you’d do with a two-line nested loop ... > that is was far simpler to just copy-paste the config six times.

And that's the right way for infrastructure and build configs. You do want over-verbose, no-logic code in the configs. Unlike app code, you rarely need to change it, and readability is even more important. 6 duplicates is not too many yet for infra code.

In terms of copy-paste tolerance, I'd rank from least to most: app code, tests code, infra configs, and build pipeline configs.

Post reply on HN