4 ms·

That's a lot of words to describe a very simple syntax: name=value pairs, with line continuation using whitespace. Basically RFC822 email headers, or Debian Co

by theamk 2y ago

That's a lot of words to describe a very simple syntax: name=value pairs, with line continuation using whitespace. Basically RFC822 email headers, or Debian Control File Format [0] but with "=" instead of ":", and without dedicated comment character. The biggest problem with this format is that a lot of things are left for the app, so each app will have its own way to implement lists, bools, line wrap support.. Even something like "value override" is left to program implementation. Don't expect YAML/JSON/XML-style automated validators/linters, each program will need its own bespoke parser/generator. [0] https://www.debian.org/doc/debian-policy/ch-controlfields.html#syntax-of-control-files https://www.debian.org/doc/debian-policy/ch-controlfields.ht...

atoav 2y ago
Not to discredit the author, there are some smart thoughts in there... but I can't help but feel like: yeah of course this is very elegant — but the complexity is not gone, it is elsewhere. And they are not showing that elsewhere. Namely the parsing code.
- sn9 2y ago
  You can literally just look at it: https://github.com/chshersh/ccl/tree/main/lib https://github.com/chshersh/ccl/tree/main/lib
  - atoav 2y ago
    Sure, but it is a configuration format if it is intended to be used in all kind of languages you have to show bow to deal with it in all kind of languages. Checks that might be trivial in OCaml might be utter footguns in say C. Don't get me wrong here, I get that this is someones spare time project that they might use for themselves only. I am fine with that. But I am unconvinced if the (I admit: well demonstrated) simplicity of the format translates to simplicity of use in the scope it aimed for (replacement for other wide spread configuration formats). I don't say it is impossible (or even unlikely) that this is an improvement, I just caution against seeing an elegant minimalist approach and automatically assuming it makes things simpler — remember, computers with their binary file systems already have the most simple format that could exist: zero or one. Yet somehow people shot themselves in the foot parsing those for decades. Much of the complexity of computer systems stems from managing the simplicity of the underlying components (if we ignore the thick layer historically grown cruft). What would it take to change my mind? Elegant examples how to parse all the examples in that post using major programming languages (C, C++, Javascript, Java, Python, Go, Rust, ...). That is ofc a lot of work, but if the format should be adopted that work would be needed anyways.
    - sn9 2y ago
      Part of the power of the idea is how amenable this is to property-based testing. And it really only takes one solid implementation that can be wrapped/called from other languages to do well. (Or perhaps one per an ecosystem like JVM, .NET, WASM, anything that can be relatively easily called from C, anywhere Python is used for scripting, etc.) And because of the formalisms involved, you could have a pretty precise and complete spec defined.
- earnestinger 2y ago
  Yup. If simplicity syntax is the only goal, we can take one step further. I present you with, EP - easy properties: Any UTF8 encoded file is valid configuration file. You’re the boss, not the language. You can concatenate two files, you can add comments in format you want, you can choose any syntax you want! (Somebody will need to parse it eventually though)
diggan 2y ago
> The biggest problem with this format is that a lot of things are left for the app, so each app will have its own way to implement lists, bools, line wrap support That seems to be one of the explicit goals: > Configuration is specific to a particular application. What you want is to follow the rule of the least surprise and utility functions to parse strings. Since configuration is specific to a particular program, so should the configuration, seems to be what the author is getting at. Personally, what puts me off this particular configuration language is this part, hidden behind collapsed text: > In fact, CCL is indentation-sensitive. Programming/configuring stuff with invisible characters isn't my idea of fun, and it sounds especially cumbersome if everyone is using it differently, since the configuration language leaves a lot up to the users of the configuration.
- cies 2y ago
  I think indentation sensitivity is very well suited for configs: you want little line noise and the complexity is low. I do understand the trade-off TOML made in this case. Some languages prohibit the TAB character, and only allow spaces at the start of the line in groups of 2 or 4: so it is always clear how indentation is to be understood.

by theamk 2y ago

atoav 2y ago

Not to discredit the author, there are some smart thoughts in there... but I can't help but feel like: yeah of course this is very elegant — but the complexity is not gone, it is elsewhere. And they are not showing that elsewhere. Namely the parsing code.

sn9 2y ago
You can literally just look at it: https://github.com/chshersh/ccl/tree/main/lib https://github.com/chshersh/ccl/tree/main/lib
- atoav 2y ago
  Sure, but it is a configuration format if it is intended to be used in all kind of languages you have to show bow to deal with it in all kind of languages. Checks that might be trivial in OCaml might be utter footguns in say C. Don't get me wrong here, I get that this is someones spare time project that they might use for themselves only. I am fine with that. But I am unconvinced if the (I admit: well demonstrated) simplicity of the format translates to simplicity of use in the scope it aimed for (replacement for other wide spread configuration formats). I don't say it is impossible (or even unlikely) that this is an improvement, I just caution against seeing an elegant minimalist approach and automatically assuming it makes things simpler — remember, computers with their binary file systems already have the most simple format that could exist: zero or one. Yet somehow people shot themselves in the foot parsing those for decades. Much of the complexity of computer systems stems from managing the simplicity of the underlying components (if we ignore the thick layer historically grown cruft). What would it take to change my mind? Elegant examples how to parse all the examples in that post using major programming languages (C, C++, Javascript, Java, Python, Go, Rust, ...). That is ofc a lot of work, but if the format should be adopted that work would be needed anyways.
  - sn9 2y ago
    Part of the power of the idea is how amenable this is to property-based testing. And it really only takes one solid implementation that can be wrapped/called from other languages to do well. (Or perhaps one per an ecosystem like JVM, .NET, WASM, anything that can be relatively easily called from C, anywhere Python is used for scripting, etc.) And because of the formalisms involved, you could have a pretty precise and complete spec defined.
earnestinger 2y ago
Yup. If simplicity syntax is the only goal, we can take one step further. I present you with, EP - easy properties: Any UTF8 encoded file is valid configuration file. You’re the boss, not the language. You can concatenate two files, you can add comments in format you want, you can choose any syntax you want! (Somebody will need to parse it eventually though)

diggan 2y ago

> The biggest problem with this format is that a lot of things are left for the app, so each app will have its own way to implement lists, bools, line wrap support That seems to be one of the explicit goals: > Configuration is specific to a particular application. What you want is to follow the rule of the least surprise and utility functions to parse strings. Since configuration is specific to a particular program, so should the configuration, seems to be what the author is getting at. Personally, what puts me off this particular configuration language is this part, hidden behind collapsed text: > In fact, CCL is indentation-sensitive. Programming/configuring stuff with invisible characters isn't my idea of fun, and it sounds especially cumbersome if everyone is using it differently, since the configuration language leaves a lot up to the users of the configuration.

cies 2y ago
I think indentation sensitivity is very well suited for configs: you want little line noise and the complexity is low. I do understand the trade-off TOML made in this case. Some languages prohibit the TAB character, and only allow spaces at the start of the line in groups of 2 or 4: so it is always clear how indentation is to be understood.