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

21–30 of 69 posts

Re: Levels of configuration languages

#21

Post by bangonkeyboard »

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…

A top-level /AppleInternal/ directory on macOS, even if empty, will enable certain features in Apple developer tools.

Re: Levels of configuration languages

#23

Post by cduzz »

somat wrote: post #19
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…

A number of traditional unix utilities change their behavior based on what their name is. /bin/test and /bin/[ come to mind. but I just checked and a quick survey of openbsd finds. eject mt [ test chgrp chmod cksum md5 sha1 sha256 sha512 cpio pax tar ksh rksh sh taken to it's logical extreme you end up with somthing like crunchgen https://man.openbsd.org/crunchgen which merges many independent programs into one and s…

ssh and rsh used to cause you to rsh/ssh to the name of the file...

so I had, in my home directory

~me/bin/snoopy

and if I wanted to log into snoopy, I'd just type

$ snoopy

and it'd rsh me into snoopy.

Hilarity was the day when someone ran

  cd /export/home && for user in * ; do chown -R $user:users ; done
(note the lack of the -h flag, which causes the ownership of the symbolic link instead of the reference of the symbolic link to be chowned)

Re: Levels of configuration languages

#24

Post by chubot »

Hm I also made a taxonomy of 5 categories of config languages, which is a bit different

Survey of Config Languages https://github.com/oils-for-unix/oils/wiki/Survey-of-Config-...

    Languages for String Data
    Languages for Typed Data
    Programmable String-ish Languages
    Programmable Typed Data
    Internal DSLs in General Purpose Languages
Their taxonomy is:

    String in a File
    A List
    Nested Data Structures
    Total Programming Languages
    Full Programming Language
So the last category (#5) is the same, the first one is different (they start with plain files), and the middle is a bit different.

FWIW I don’t think “Total” is useful – for example, take Starlark … The more salient things about Starlark are that it is restricted to evaluate very fast in parallel, and it has no I/O to the external world. IMO it has nothing to do with Turing completeness.

Related threads on the “total” issue:

https://lobste.rs/s/dyqczr/find_mkdir_is_turing_complete

https://lobste.rs/s/gcfdnn/why_dhall_advertises_absence_turi...

Re: Levels of configuration languages

#25

Post by AtlasBarfed »

This is just the complexity in individual files!

Configuration can be a lot more complicated. Look at dockerfiles, which are filesystems overlaid over each other, often sourced from the internet.

https://docs.spring.io/spring-boot/reference/features/extern...

Look at that: a massive 15 deep precedence order for pulling just individual values (oh man, doesn't even touch things like maps/lists that get merged/overridden).

That includes sources like the OS, environment-specific, a database (the JNDI registry), XML, JSON, .properties files, hardcodes. Honestly, I remember this being even deeper, I suspect they have simplified this.

This doesn't even get into secrets/secured configuration, which may require a web service invocation. I used to also pull config via ssh, or from private gits or github, from aws web service calls (THAT required another layer of config getting a TOTP cycled cred).

https://crushedby1sand0s.blogspot.com/2021/02/stages-of-desp...

I was right, the Spring config fallthru was deeper.

Re: Levels of configuration languages

#26

Post by hmry »

kristopolous wrote: post #8
qznc wrote: post #3

Earlier quoted context omitted.

CSS is at least level 4. You can even argue for level 5, i.e. Turing-complete: https://stackoverflow.com/questions/2497146/is-css-turing-co...

Level 4 is turing complete. There's two parts that I was talking about. Things that are not quite that and the fact that configuration can have that capability in a fairly useless context. When I'm dealing with personal things or stuff that few people use I will often make the configuration just something I eval/source. So it in theory has the same functionality as the underlying programming language, but in practice…

Level 4 / total programming languages are not turing complete. Because you can't simulate every turing machine in them, only some subset that provably halts. (And because the halting problem is undecidable, there will always be some turing machines that actually do halt but still can't be simulated because the compiler can't prove it)

Re: Levels of configuration languages

#27

Post by alexambarch »

I’d argue Terraform/HCL is quite popular as a Level 4 configuration language. My biggest issue with it is that once things get sufficiently complex, you wish you were using a Level 5 language.

In fact, it’s hard to see where a Level 4 language perfectly fits. After you’ve surpassed the abilities of JSON or YAML (and you don’t opt for slapping on a templating engine like Helm does), it feels like jumping straight to Level 5 is worth the effort for the tooling and larger community.

Re: Levels of configuration languages

#28

Post by rssoconnor »

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.

Dave Cunningham created jsonnet from some conversations I had with him about how Nix's lazy language allows one to make recursive references between parts of one's configuration in a declarative way. No need to order the evaluation beforehand.

Dave also designed a way of doing "object oriented" programming in Nix which eventually turned into what is now known as overlays.

P.S. I'm pretty sure jsonnet is Turing complete. Once you get any level of programming, it's very hard not to be Turing complete.

Re: Levels of configuration languages

#29

Post by zzo38computer »

18172828286177 wrote: post #10

> Don't waste time on discussions within a level. For example, JSON and YAML both have their problems and pitfalls but both are probably good enough. Disagree. YAML is considerably easier to work with than JSON, and it’s worth dying on that hill.

I don't really like either format (I am not sure which is worse; both have significant problems). YAML has some problems (such as Norway problem and many other problems with the syntax), and JSON has different problems; and some problems are shared between both of them. Unicode is one problem that both of them have. Numbers are a problem in some implementations of JSON but it is not required. (Many other formats have some of these problems too, such as using Unicode, and using floating numbers and not integers, etc.)

I think DER is better (for structured data), although it is a binary format, but it is in canonical form. I made up the TER format which is a text format which you can compile to DER, and some additional types which can be used (such as a key/value list type). While Unicode is supported, there are other (sometimes better) character sets which you can also use.

(However, not all configuration files need structured data, and sometimes programs are also useful to include, and these and other considerations are also relevant for other formats, so not everything should use the same file formats anyways.)

Re: Levels of configuration languages

#30

Post by LeifCarrotson »

bangonkeyboard wrote: post #21
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…

A top-level /AppleInternal/ directory on macOS, even if empty, will enable certain features in Apple developer tools.

I've observed similar things to happen in other tools too - third-party tools that will list a certain set of file formats by default, and enable Autodesk formats if C:/Autodesk is present.

It seems to be most common in systems that cross major business domains (or come from completely separate companies). If you could just add an entry to the featureful, versioned, controlled config file then you'd do that, but if you can't developers frequently resort to the "does this path name resolve" heuristic.

Post reply on HN