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

Universal configuration language

github.com

Post reply on HN
Print view View original

11–20 of 29 posts

Re: Universal configuration language

#11

Post by valw »

krapp wrote: post #5
moomin wrote: post #2

Doesn't Lisp already exist?

A "configuration language" by definition (in my opinion) should not be Turing complete. A configuration language is for storing state - key/value pairs or simple structures of primitive types, nothing more (or as little more as necessary), nothing less. Once you introduce enough complexity (branching, recursion) you've just created another application with global variables for the main application to access - a capab…

Would you agree to call Grunt a configuration tool?

I have found the fact that Grunt lets you write full-featured JavaScript quite useful. In 95% of cases, of course, you want to write your configuration in a declarative, JSON-like form, but I welcome the possibility of having full JS power in the few situations where non-trivial logic is needed. Another advantage, of course, is familiarity: I already know JavaScript.

However, what I really don't like is a declarative data language or some sort of DSL that starts adding some basic variable and control flow features. That's the best way to end up with a tool that's complicated, hard to reason about, and still unexpressive.

So to me, a good configuration language should be either a simple data language (such JSON), OR a simple, powerful, well-known programming language with good data structure literals to encourage a declarative style.

Re: Universal configuration language

#12

Post by krapp »

valw wrote: post #11
krapp wrote: post #5

Earlier quoted context omitted.

A "configuration language" by definition (in my opinion) should not be Turing complete. A configuration language is for storing state - key/value pairs or simple structures of primitive types, nothing more (or as little more as necessary), nothing less. Once you introduce enough complexity (branching, recursion) you've just created another application with global variables for the main application to access - a capab…

Would you agree to call Grunt a configuration tool? I have found the fact that Grunt lets you write full-featured JavaScript quite useful. In 95% of cases, of course, you want to write your configuration in a declarative, JSON-like form, but I welcome the possibility of having full JS power in the few situations where non-trivial logic is needed. Another advantage, of course, is familiarity: I already know JavaScript…

Certainly, but personally I would still like to keep logic out of configuration as much as possible.

If I had to pick an actual language for configuration I would probably pick Javascript, mostly because I like JSON's syntax.

My instinct would be to say that if you need non-trivial logic, you may have an issue elsewhere with separation of concerns, and should move that code somewhere else.

But I will concede there may be a cases I'm just not aware of where that's unavoidable. Almost everything I do involves json or ini files anyway so I haven't really worked on anything incredibly complex.

Re: Universal configuration language

#13

Post by espadrine »

moe wrote: post #9

This looks terrible. An "almost-JSON" with... macros? Seriously? What problem is this looking to solve? Why not just use TOML or YAML?

JSON offers data structures that everybody understands, so having a configuration language that has exactly those is what I want in a configuration language.

TOML isn't it (some JSON can't be put in TOML by design). YAML is definitely easier to edit than JSON, but just like XML its flaw is in its complexity (both in syntax and in specialized structures, such as references or types).

That's why I made dotset (http://espadrine.github.io/dotset/). It doesn't have macros™. And it's a YAML subset.

Re: Universal configuration language

#14

Post by bshimmin »

The "Automatic arrays creation" bit rather worries me - it strikes me that very often if you have non-unique keys, it's because you've made a mistake, so automatically converting that object into an array would probably result in misconfiguration.

Re: Universal configuration language

#16

Post by calibraxis »

krapp wrote: post #5
moomin wrote: post #2

Doesn't Lisp already exist?

A "configuration language" by definition (in my opinion) should not be Turing complete. A configuration language is for storing state - key/value pairs or simple structures of primitive types, nothing more (or as little more as necessary), nothing less. Once you introduce enough complexity (branching, recursion) you've just created another application with global variables for the main application to access - a capab…

Presumably they mean something like EDN/Fressian.

Re: Universal configuration language

#17

Post by cies »

moe wrote: post #9

This looks terrible. An "almost-JSON" with... macros? Seriously? What problem is this looking to solve? Why not just use TOML or YAML?

Also came here to mention TOML. It's still in development, but already it makes (IMHO) a better configuration language.

Re: Universal configuration language

#19

Post by usrusr »

Yet another tool to parse one large string into a map of smaller strings. Trouble with configuration files is rarely caused by insufficient syntax features, but insufficient schema validation seems to be a consistent source of wtf-moments: a mistyped key here, a duplicate key there, that's what is stealing our time (duplicate key: first definition wins? last definition wins? both get concatenated? doesn't matter, if i was aware of having two of them i would have fixed it in a second).

What i want from a configuration helper library is nothing less than an internal DSL for specifying the typed structure of allowed/expected keys, together with their default values and a short "what is this" description available at runtime. This would be enough to generate nice empty configuration templates and create warnings for unexpected keys (be it from typos or from unexpected duplicates).

Fancy syntax features for the configuration files themselves would be only secondary niceties. And candidates for "stupid" preprocessors ("stupid" in that they would not have to know about the appllicaton's configuration schema).

Re: Universal configuration language

#20

Post by chriswarbo »

krapp wrote: post #5
moomin wrote: post #2

Doesn't Lisp already exist?

A "configuration language" by definition (in my opinion) should not be Turing complete. A configuration language is for storing state - key/value pairs or simple structures of primitive types, nothing more (or as little more as necessary), nothing less. Once you introduce enough complexity (branching, recursion) you've just created another application with global variables for the main application to access - a capab…

> A "configuration language" by definition (in my opinion) should not be Turing complete.

One of the key insights of LISP is that s-expressions are a simple, universal format. Yes, they can be used for code, but they can also be used for static configuration data. In fact, LISP originally used s-expressions solely for data; code was meant to be written with m-expressions ( http://en.wikipedia.org/wiki/M-expression ). Once `eval` was implemented, s-expressions could be used for code and data, so the idea of m-expressions was abandoned.

> A configuration language is for storing state - key/value pairs or simple structures of primitive types, nothing more (or as little more as necessary), nothing less.

The trouble with "universal" formats like this is that there's no universal agreement on what's a "primitive type" (what happens when I write `0.1`? Are booleans primitive, or should we use `0` and `1`?) and what's a "simple structure" (can I make a circular list?). That in itself wouldn't be too bad, but these languages tend to hard-code special syntax to particular types and structures, so any types or structures we may want to add must either be second-class citizens, or would require hacking the parser.

Post reply on HN