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

Levels of configuration languages

beza1e1.tuxen.de

Post reply on HN
Print view View original

51–60 of 69 posts

Re: Levels of configuration languages

#51

Post by kristopolous »

nxnxdndndn wrote: post #48
kristopolous wrote: post #39

Earlier quoted context omitted.

It's been edited since I wrote this and it's now 5 instead of 4 It didn't originally use the obscure formal idea of a "total" language

How is a total language obscure? It's a language describing total functions

oh I knew I was going to get this. Now I have to define obscure. Let's go!

Github has two (yes, just 2) repositories referring to them: (that's nearly 0.000 000 5% of Github I hear you say)

https://github.com/search?q=%22total%20language%22&type=repo...

But maybe that's unfair. Let's try a software engineering encyclopedia!

Ok, "Encyclopedia of Software Engineering (2011)" doesn't have it: https://archive.org/details/encyclopediaofso0001unse_m2w7/pa...

Alright what about programming language text book?

Well, "Programming language design concepts" (2004) also doesn't mention it https://archive.org/details/programminglangu0000watt/mode/2u...

What about Donald Knuth? Surely! Nope, not on the versions of his text on archive.org at least.

https://archive.org/details/artofcomputerpro0002knut_u2o0/mo... also https://archive.org/details/artofcomputerpro0000unse_e7w6/mo...

Oh let's go to arxiv. I'm sure of the ~400 CS papers that go up daily there'd be hundreds of ... oh wait, we got 5 spreading over 17 years: https://arxiv.org/search/?query=%22total+language%22&searcht... about 1 every 3 years. Alright.

And thus with 5 different sampling methods all supporting the same conclusion I will support the claim that it is obscure.

I know how on the internet, vibes tends to win over cited defensible evidence but I did it anyway. Maybe we can be all be adults some day.

Re: Levels of configuration languages

#52

Post by xelxebar »

sgeisenh wrote: post #5

> Don't waste time on discussions within a level. I disagree with this. YAML has too many footguns (boolean conversions being the first among them) not to mention it is a superset of JSON. Plain old JSON or TOML are much simpler.

> YAML has too many footguns (boolean conversions being the first among them)

Copying my own comment from elsewhere: https://news.ycombinator.com/item?id=43670716.

This has been fixed since 2009 with YAML 1.2. The problem is that everyone uses libyaml (_e.g._ PyYAML _etc._) which is stuck on 1.1 for reasons.

The 1.2 spec just treats all scalar types as opaque strings, along with a configurable mechanism[0] for auto-converting non-quoted scalars if you so please.

As such, I really don't quite grok why upstream libraries haven't moved to YAML 1.2. Would love to hear details from anyone with more info.

[0]:https://yaml.org/spec/1.2.2/#chapter-10-recommended-schemas

Re: Levels of configuration languages

#53

Post by lmm »

ks2048 wrote: post #34

I'm not sure "total" vs "turing-complete" should be a huge difference - just terminate with an error after X seconds. For example, can "total programming languages" include: "for i in range(10000000000000): do_something()"? If so, your config file can still hang - even though it provably terminates.

It's a lot easier to accidentally make a file that takes forever than to accidentally make a file that takes a long but finite amount of time.

Re: Levels of configuration languages

#54

Post by ajb »

qznc wrote: post #20
ajb wrote: post #4

I'm not convinced by reducing this to a single dimension. There are differences in both 'what can be expressed' and 'what validation can be done' which are somewhat independent of each other

Hm, you got me thinking about reversible computing and how it could be applied to configuration. Debugging a configuration becomes tedious once computation is involved. You think some value should be "foo" but it is "bar". Why is it "bar"? If someone wrote it there, the fix is simply to change. If "bar" is the result of some computation, you have to understand the algorithm and its inputs, which is significantly hard…

Interesting idea! Although, maybe you just want to be able to run the configuration language in a reversible debugger?

This issue becomes even harder when you have some kind of solver involved, like a constraint solver or unification. As a user the solver is supposed to make your life easier but if it rejects something without a good enough error message you are stuck; having to examine the solver code to work out why is a much worse experience than not having a solver. (This is the same issue with clever type systems that need a solver)

Re: Levels of configuration languages

#55

Post by James_K »

"Use the lowest level possible" has always seemed rather stupid advice to me. What I suggest: use XML. Every programming language under the sun can spit out XML files, so you can generate them programmatically if needed, and it's not as if you'll ever sit there wishing you'd gone for a simpler format. Sachems make the files practically self-documenting and the tooling for them is brilliant.

Re: Levels of configuration languages

#56

Post by rzzzt »

ks2048 wrote: post #32
susam wrote: post #7

About 20 or so years ago, I have come across a configuration pattern that could be arguably called "Level 0". It was configuration by file existence. The file itself would be typically empty. So no parsing, syntax, or schema involved. For example, if the file /opt/foo/foo.txt exists, the software does one thing but if it is missing the software does another thing. So effectively, the existence of the file serves as a…

This gives me an idea - store small integer parameters (<= 511) as file permissions (r/w/exe for user/group/other) on an empty file.

Larger integers can go into UID:GID values.

Re: Levels of configuration languages

#57

Post by bob1029 »

danpalmer wrote: post #43
bob1029 wrote: post #14

I think SQL is one of the best level 4/5 configuration languages out there. Whether or not it's a "full programming language" depends on your specific dialect and how it's used.

Only if what you specifically want is to represent queries. If what you want to represent is roughly static data then SQL is an incredibly awkward language to use.

This is valid SQL:

  SELECT 'Constant'

Re: Levels of configuration languages

#58

Post by longor1996 »

chewbacha wrote: post #37

Reminds me a lot of the configuration complexity clock: https://mikehadlow.blogspot.com/2012/05/configuration-comple... It’s made the page before and proposes that these forms are cyclic.

The article actually (accidentally or on purpose?) refers to just that:

> How to avoid this madness? Introduce another low-level configuration file. Back to level one...

Re: Levels of configuration languages

#59

Post by liveify »

waynecochran wrote: post #18

https://jsonnet.org/ I never heard of this before. This seems like the JSON I wish I really had. Of course at some point you could just use JavaScript. I guess that fits w option 5.

I made a decision early on in a project to replace YAML with jsonnet for configuration and it was the best decision I made on that project - I’ve written tens of thousands of lines of jsonnet since.

Re: Levels of configuration languages

#60

Post by sevensor »

sgeisenh wrote: post #5

> Don't waste time on discussions within a level. I disagree with this. YAML has too many footguns (boolean conversions being the first among them) not to mention it is a superset of JSON. Plain old JSON or TOML are much simpler.

Lack of nulls in toml is a headache. No two yaml libraries agree on what a given yaml text means. Although json is bad at numbers, that’s more easily worked around.
Post reply on HN