7 ms·

So what's the author's proposed alternative? IMHO JSON5 (JSON with comments basically) is fine for config files, VS Code is using this and they seem to be doin

So what's the author's proposed alternative? IMHO JSON5 (JSON with comments basically) is fine for config files, VS Code is using this and they seem to be doing alright. Addressing the article's points: - Lack of comments: not an issue with JSON5. - Readability: I think it's pretty readable. Are the quotes, semicolons and commas really an issue? Not for me. - Strictness: just edit it with an editor that points at the errors quickly. Escaping quotes might be annoying, but I can't think of a possible alternative format where escaping isn't required at all. - Lack of programmability: I've never had any problem with this, and again pretty complex and customizable applications like VS Code seem to be doing fine without this. This may even be considered a feature, as it forces you to keep the configuration well separated from the actual logic.

nonbirithm 8y ago
Perhaps HCL[0] is worth a look. It has comments and no need to quote keys. I ported it to C++ and Lua for a project and it gets the job done for non-dynamic configs. [0] https://github.com/hashicorp/hcl https://github.com/hashicorp/hcl
nixpulvis 8y ago
So many options out there, just look for config formats on github. TOML is my personal favorite.
- alias_neo 8y ago
  Agreed. I feel like everyone uses YAML, I hate it. YAML feels like 10 steps back; no parser I've ever used has been able to accurately give me a line number for an error, white space issues make it impossible to work with without special editor features, and some of the types are just cryptic. I spend most of my time that's spent editing configs in vim over SSH and it can be challenging at times. TOML resolves a lot of these issues in my experience but I'd still argue that by virtue of its capability, is still quite complex when trying to define configs for new applications.
  - rgacote 8y ago
    And TOML does not have the security code execution vulnerability that is in YAML.
  - StavrosK 8y ago
    I once tried to use YAML as my format of choice. Then I read the spec. YAML: Not even once.
  - h1d 8y ago
    > TOML resolves a lot of these issues The only complaint is that the name TOML isn't as cool as other formats.
    - justinclift 8y ago
      Came across a pain point with TOML yesterday in use. When trying out a CLI I've been writing recently, this time on Windows... the TOML config file (generated on first run) wasn't usable. The problem turned out to be TOML not handling single slashes "\" in strings, instead treating them as escape characters. Annoying as on Windows the paths are (eg): "C:\Program Files\stuff". Which then needs changing to "C:\\Program Files\\stuff" to work ok. I can see both good and bad points of TOML's string handling there. But it's annoying it needs a workaround for one of the signature aspects (slash vs backslash) of windows. Especially when paths are very common in config files, regardless of OS. :/
      - frosted-flakes 8y ago
        Just use 'literal strings' instead of "basic strings". TOML has two types of strings, each of which can be single line or multi line [0]. Basic strings allow escape characters, while literal strings do not (so there's no way to represent an apostrophe in a single line literal string). Multi line strings are like Markdown's code blocks: """ This is a multi- line basic string. C:\\Program Files\\stuff """ ''' This is a multi- line literal string. C:\Program Files\stuff ''' [0] https://github.com/toml-lang/toml/blob/master/README.md#string https://github.com/toml-lang/toml/blob/master/README.md#stri...
- adrianhel 8y ago
  Definitely
grigjd3 8y ago
The lack of comments is a problem. The rest seems whiney to me, but sometimes I need to leave notes for other developers as reminders.
- rjf72 8y ago
  I formalize comments and keep them themselves as data. I don't use JSON for this, but it'd work out as a perfect solution here. There's also good reasons to do it this way. For instance the formalized comments can work as a tool tip for a user configuration UI. Another reason is to do something like automatically produce source code from the config file with the comments in a format such that they work with intellisense. The produced source code now also can trivially reproduce a config file with appropriate defaults. Lots of perks.
k__ 8y ago
https://medium.com/@robmuh/yaml-has-won-ba5dae37e740 https://medium.com/@robmuh/yaml-has-won-ba5dae37e740 Seems like YAML won. But TOML seems to be heavily used in Rust. Also there is SANE.
- h1d 8y ago
  I don't care if it has "won" in a few places, I'll be using TOML and mindshare can change who has "won" later.
echelon 8y ago
> - Lack of comments: not an issue with JSON5. Yeah, but now you have to find a tool that supports that. Easy on small projects, but try being at a company supporting many languages and frameworks. > - Readability: I think it's pretty readable. Are the quotes, semicolons and commas really an issue? Not for me. If you haven't tried TOML, you're missing out. Why on earth would you put up with syntax (hard to author, at that) that isn't necessary? Syntax distracts from the actual problem that this is trying to solve. JSON is fine for machine read/write, but horrible on humans. > - Strictness: just edit it with an editor that points at the errors quickly. Escaping quotes might be annoying, but I can't think of a possible alternative format where escaping isn't required at all. What if you have an issue in prod and need to fix something quick? You might only be able to open it up in a stripped-down vi, or if the machine is locked down you might only be able to materialize a plain text view. What if not everyone uses the same tool? This imposes a further constraint. Yet more concessions pointing to how horrible JSON is for humans. > - Lack of programmability: I've never had any problem with this, and again pretty complex and customizable applications like VS Code seem to be doing fine without this. Can you imagine projects where this might be an issue? These aren't the only codebases in the world. And just because VSCode appears to be doing fine doesn't mean they don't second guess that decision. They might just be locked in at this point.
- ohaideredevs 8y ago
  Generally, you swap out the config file at build time if that's a requirement. Just as a few examples - you can set up a dev/demo/prod(whatever you call these where you work) config file in .NET Core, Docker/K8S, Angular, etc. As far as I know, this is considered best practice.
  - echelon 8y ago
    There are many different needs. - static config - environment specification - runtime feature flagging - semi-static control plane config - rollout weights Etc. All of these have different characteristics. Infrequently changed, a priori config that doesn't need to be changed in emergencies is suitable for baking in at compile time.
- 8y ago
cle 8y ago
There are cases when JSON is really unreadable. Multi line strings, strings with lots of escaping, etc. There are a lot of other formats that solve these problems (eg YAML, which certainly has other unrelated problems). There are trade offs with the various formats. Think about your use cases and pick the one that fits them the best.
brianpgordon 8y ago
In the Scala world, HOCON addresses a lot of these (except programmability, which I think is probably a bad idea).
- patsplat 8y ago
  Not just Scala https://github.com/yellowblood/hocon-js https://github.com/yellowblood/hocon-js
  - azernik 8y ago
    Whole bunch of other ports into different languages too: https://github.com/lightbend/config#other-apis-wrappers-ports-and-utilities https://github.com/lightbend/config#other-apis-wrappers-port... Thanks for pointing me to that - I'm working in Scala on server-side and JS on browser-side for a couple of years now, and sharing config would be nice. Still need object merging and value concatenation, which hocon-js doesn't support, but I'll keep an eye on it!
- femto113 8y ago
  The only config system I've worked on that ever felt even vaguely satisfying was built around the excellent Typesafe (now Lightbend) HOCON implementation. The fact that HOCON is a superset of both JSON and properties formats made adoption in a large org feasible since it could "just work" with the many already existing config files in those formats. While generalized programmability has obvious dangers, HOCON's ability to do variable substitution was super useful for the large amounts of config that was supposed to follow a convention, e.g. hostnames based on a template like ${service}.${env}.example.com
- azernik 8y ago
  It has a few features that feel like programmability but really aren't, and I think these address most of the use cases that people want a Turing complete language for.
strags 8y ago
Take a look at HJSON.
- roryokane 8y ago
  I agree that HJSON is better for config files than JSON5, because of its more relaxed syntax requirements that making adding and editing values quicker. Link for HJSON: https://hjson.org/ https://hjson.org/ Compare to JSON5: https://json5.org/ https://json5.org/
TazeTSchnitzel 8y ago
Personally I'm partial to the classic Windows-style INI file. Because it was designed to be a human-editable configuration file format, it has a simple and intuitive format that is easy for both humans and machines: [Section] ; comment Key1=Value ; comment Key2=Value [Section2] Key1=Value It is also easy for machines to non-destructively edit, maintaining existing comments and formatting by humans, and applications take advantage of that. That is a big plus in my opinion.
- Pxtl 8y ago
  The problem with ini is that it has no good story for arrays or associative arrays. TOML attempts to fix this, but it provides ugly format for arrays and associative arrays.
  - afiori 8y ago
    I personally find the TOML solution quite nice. In part because you can always drop to JSON syntax to avoid excessive nesting of array tables.
- cheerlessbog 8y ago
  TOML is arguably an evolution of ini format.
- tinus_hn 8y ago
  It is pretty limited and the worst part is quoting. What if your value contains \n? What about UTF8?
- BuckRogers 8y ago
  I agree, but my second choice if INI doesn't suit someone is just the standard app.config in Windows (trivial to interface with in the .Net space), or storing the values in a table. I'd prefer any of these before JSON or the other alternatives.
- robocat 8y ago
  Horrible for: UTF8, syntax checks, numbers (albeit JSON has this problem too for floats), deep nesting, arrays, strings as keys, consistency between different parsers, etc etc Good for: comments, readability if keys limited, familiarity.
naranha 8y ago
The alternative is javascript. Javascript gives you json with comments and programmability. And where possible .env.
- cmroanirgo 8y ago
  A lightweight ini reader in js I wrote a few years back: https://github.com/cmroanirgo/jsinf https://github.com/cmroanirgo/jsinf
jonathankoren 8y ago
Of course, JSON5 didn’t come out until 2017, and this was written in 2016.
darkpuma 8y ago
In cases where the file is written and read by the program, without the expectation that the user will typically edit or read the file by hand, sqlite is something that should be considered. A sqlite file isn't an ascii text file that you can edit with vi, so that suggestion is likely to get a lot of jeering, but it's a serious suggestion. It's already being used for configuration on all mobile platforms. There exists a wide range of applications, particularly for windows users, where the common user is not a developer and is not meant to be editing configuration by hand. Furthermore, access to the sqlite3 binary is very nearly as widespread as access to a vi binary. And self-styled developers who don't know SQL aside, it actually is a rather convenient format to edit by hand. Machine transformation of the config is obviously straight forward, and sqlite databases tend to be self-documenting anyway. Sane table and row names go a long way (obfuscated tables and rows would be roughly equivalent to obfuscated keys in an ini file...) and if that's not enough, comments for tables and rows can be stored in the schema. The one downside is strictness; sqlite doesn't enforce types. It does however have data constraints, which help.
willtim 8y ago
In my opinion, a statically typed config file would be preferable.
- FraaJad 8y ago
  See Dhall - https://dhall-lang.org/ https://dhall-lang.org/
  - willtim 8y ago
    Yes I like Dhall, I also had a go at my own one a while ago: https://github.com/willtim/Expresso https://github.com/willtim/Expresso
zaphar 8y ago
I'm not sure what the the author would suggest but I'm increasingly of the opinion that config files formats should be treated as a compile target not a file that you edit. There are formats that are easier to edit than others and formats that are easier to parse than others. But sooner or later all of them end up being created by an ill-suited template engine or embedding a programming language in the syntax (cloudformation, ansible, hcl2). Why not treat the config file as a generated artifact that is readable but not written by a human. Tools like jsonnet (https://jsonnet.org/ https://jsonnet.org/), dhall-lang (https://dhall-lang.org/ https://dhall-lang.org/), or my personal side project ucg (https://ucg.marzhillstudios.com/ https://ucg.marzhillstudios.com/) allow you reuse values and safely generate your configuration formats with comments and logic all while bypassing the pitfalls of most formats. They give you a purpose built language for creating configurations with comments and logic w/o putting that burden on your application later. And it allows you to ignore the parts of a particular format that cause you problems.
- terandle 8y ago
  Create a good config file format and transpile that to a bad config file format for use in an application? I dunno I would rather just have the application use a decent config file format in the first place. It's just a config file, no need to overthink this with translation layers IMO.
  - zaphar 8y ago
    No good config file format will allow you to share common shared values across all of the formats. That database host everything uses? You'll have to copy paste it everywhere or use a template engine to generate all of the formats. If you only have one application then it's overkill. When you have 10's of applications it's a life saver.
    - terandle 8y ago
      Good point. However hopefully whatever brilliant file format the source of truth is in will eventually end up being able to be consumed natively by the other applications and we can forgo the translation layer. Until then yes you have a good use case there.
ehsankia 8y ago
Wow, just looked at JSON5 and it's everything I could've ever hoped for! I remember distinctly looking for a JSON alternative that supports comments, trailing , and single quotes. This does all that and more. Now how long until it becomes standard (supported by python's default json library, browser's JSON.parse, etc).
- h1d 8y ago
  Somehow not widely spread. I can't believe json was standardized with all those shortcomings.
keymone 8y ago
EDIT: moved this comment to the root of the discussion https://news.ycombinator.com/item?id=19655249 https://news.ycombinator.com/item?id=19655249
gubbrora 8y ago
>Escaping quotes might be annoying, but I can't think of a possible alternative format where escaping isn't required at all. One nifty way of doing this is custom quote sequence. In C++ it works like R"delimiter( raw_characters )delimiter" As delimiter can be anything it can be chosen not to conflict with the payload. Bash has had the same trick for here documents for a long while.
afiori 8y ago
> a possible alternative format where escaping isn't required at all. HEREDOC-like format: #qweqwe123" string where everything is unquoted and is terminated by a " followed by qweqwe123. you can chose a short relevant sequence of alphanumeric chars as needed"qweqwe123#
arp242 8y ago
> So what's the author's proposed alternative? I am the author. It depends on your purpose; in general, I would say "the simplest solution that meets all needs", where "all needs" depends on what you're doing. In Python, this could be the configparser module, or parsing a Python file (again, depending on requirements). As a matter of taste, I prefer minimal syntax. I wrote a library with this syntax a while ago[1], although it's clearly not the best solution for every case. I should probably write a separate article about this. [1]: https://github.com/carpetsmoker/sconfig#what-does-it-look-like https://github.com/carpetsmoker/sconfig#what-does-it-look-li... > Lack of comments: not an issue with JSON5. JSON5 isn't JSON though. It's JSON5. None of the standard JSON parsers can deal with JSON5, you need a different JSON5 parser. > I think it's pretty readable A matter of taste. > just edit it with an editor that points at the errors quickly It seems to me that having to rely on such tools for issues such as this is not a great idea, especially not if it's easy to do better. > I can't think of a possible alternative format where escaping isn't required at all. There is a difference between "escaping isn't required at all" vs. "having to constantly and awkwardly escape a commonly used character". > Lack of programmability [..] VS Code seem to be doing fine without this. I've not used VSCode, As I'm a Vim guy. I can't imagine configuring Vim with just declarative configuration as so many useful parts come from being able to program Vim. This could be separated out to just an "extension" or "plugin" system, but I really like being able to just stick one or two lines of code in my vimrc and have it do something really useful, without writing a full plugin.
- equasar 8y ago
  for my tastes, sconfig is the opposite of human readable. IMO, JSON is good enough for the average cases of configuration files.
  - Carpetsmoker 8y ago
    I'm curious why you would consider it to be "the opposite of human readable"? It has a minimal of syntax to parse, so at least in my view that should make it easier, rather than harder?
DonHopkins 8y ago
I have a proposal that I'm sure will make EVERYBODY happy by combining the best of both worlds! How about "J4X" (JSON for XML), that lets you embed XML in JSON the same way the ever-popular "E4X" (ECMAScript for XML) lets you embed XML in ECMAScript? https://developer.mozilla.org/en-US/docs/Archive/Web/E4X https://developer.mozilla.org/en-US/docs/Archive/Web/E4X J4X Example: <!DOCTYPE j4x PUBLIC "-//W3C//DTD J4X 1.0 Transitional//EN" "http://www.w3.org/TR/j4x/DTD/j4x-1.0-transitional.dtd"> { april: <fools late="13 days"/>  }
EdgarVerona 8y ago
Yes - I have seen at some jobs what a horror "configuration files" can be if you let people add programmability into them. Many years ago I worked at a job that made an XML tag-based language that was turing complete with the intent of it making their configuration "smarter". It ended up making the entire project much more difficult to debug, trace through, and even understand at all.
cturhan 8y ago
I thought he would suggest yml but he didn't. yml is good but, personally I don't like it. I find json file easier to read yml. It might be because of years of experience with json.

nonbirithm 8y ago

Perhaps HCL[0] is worth a look. It has comments and no need to quote keys. I ported it to C++ and Lua for a project and it gets the job done for non-dynamic configs. [0] https://github.com/hashicorp/hcl https://github.com/hashicorp/hcl

nixpulvis 8y ago

So many options out there, just look for config formats on github. TOML is my personal favorite.

alias_neo 8y ago
Agreed. I feel like everyone uses YAML, I hate it. YAML feels like 10 steps back; no parser I've ever used has been able to accurately give me a line number for an error, white space issues make it impossible to work with without special editor features, and some of the types are just cryptic. I spend most of my time that's spent editing configs in vim over SSH and it can be challenging at times. TOML resolves a lot of these issues in my experience but I'd still argue that by virtue of its capability, is still quite complex when trying to define configs for new applications.
- rgacote 8y ago
  And TOML does not have the security code execution vulnerability that is in YAML.
- StavrosK 8y ago
  I once tried to use YAML as my format of choice. Then I read the spec. YAML: Not even once.
- h1d 8y ago
  > TOML resolves a lot of these issues The only complaint is that the name TOML isn't as cool as other formats.
  - justinclift 8y ago
    Came across a pain point with TOML yesterday in use. When trying out a CLI I've been writing recently, this time on Windows... the TOML config file (generated on first run) wasn't usable. The problem turned out to be TOML not handling single slashes "\" in strings, instead treating them as escape characters. Annoying as on Windows the paths are (eg): "C:\Program Files\stuff". Which then needs changing to "C:\\Program Files\\stuff" to work ok. I can see both good and bad points of TOML's string handling there. But it's annoying it needs a workaround for one of the signature aspects (slash vs backslash) of windows. Especially when paths are very common in config files, regardless of OS. :/
    - frosted-flakes 8y ago
      Just use 'literal strings' instead of "basic strings". TOML has two types of strings, each of which can be single line or multi line [0]. Basic strings allow escape characters, while literal strings do not (so there's no way to represent an apostrophe in a single line literal string). Multi line strings are like Markdown's code blocks: """ This is a multi- line basic string. C:\\Program Files\\stuff """ ''' This is a multi- line literal string. C:\Program Files\stuff ''' [0] https://github.com/toml-lang/toml/blob/master/README.md#string https://github.com/toml-lang/toml/blob/master/README.md#stri...
adrianhel 8y ago
Definitely

grigjd3 8y ago

The lack of comments is a problem. The rest seems whiney to me, but sometimes I need to leave notes for other developers as reminders.

rjf72 8y ago
I formalize comments and keep them themselves as data. I don't use JSON for this, but it'd work out as a perfect solution here. There's also good reasons to do it this way. For instance the formalized comments can work as a tool tip for a user configuration UI. Another reason is to do something like automatically produce source code from the config file with the comments in a format such that they work with intellisense. The produced source code now also can trivially reproduce a config file with appropriate defaults. Lots of perks.

k__ 8y ago

https://medium.com/@robmuh/yaml-has-won-ba5dae37e740 https://medium.com/@robmuh/yaml-has-won-ba5dae37e740 Seems like YAML won. But TOML seems to be heavily used in Rust. Also there is SANE.

h1d 8y ago
I don't care if it has "won" in a few places, I'll be using TOML and mindshare can change who has "won" later.

echelon 8y ago

> - Lack of comments: not an issue with JSON5. Yeah, but now you have to find a tool that supports that. Easy on small projects, but try being at a company supporting many languages and frameworks. > - Readability: I think it's pretty readable. Are the quotes, semicolons and commas really an issue? Not for me. If you haven't tried TOML, you're missing out. Why on earth would you put up with syntax (hard to author, at that) that isn't necessary? Syntax distracts from the actual problem that this is trying to solve. JSON is fine for machine read/write, but horrible on humans. > - Strictness: just edit it with an editor that points at the errors quickly. Escaping quotes might be annoying, but I can't think of a possible alternative format where escaping isn't required at all. What if you have an issue in prod and need to fix something quick? You might only be able to open it up in a stripped-down vi, or if the machine is locked down you might only be able to materialize a plain text view. What if not everyone uses the same tool? This imposes a further constraint. Yet more concessions pointing to how horrible JSON is for humans. > - Lack of programmability: I've never had any problem with this, and again pretty complex and customizable applications like VS Code seem to be doing fine without this. Can you imagine projects where this might be an issue? These aren't the only codebases in the world. And just because VSCode appears to be doing fine doesn't mean they don't second guess that decision. They might just be locked in at this point.

ohaideredevs 8y ago
Generally, you swap out the config file at build time if that's a requirement. Just as a few examples - you can set up a dev/demo/prod(whatever you call these where you work) config file in .NET Core, Docker/K8S, Angular, etc. As far as I know, this is considered best practice.
- echelon 8y ago
  There are many different needs. - static config - environment specification - runtime feature flagging - semi-static control plane config - rollout weights Etc. All of these have different characteristics. Infrequently changed, a priori config that doesn't need to be changed in emergencies is suitable for baking in at compile time.
8y ago

cle 8y ago

There are cases when JSON is really unreadable. Multi line strings, strings with lots of escaping, etc. There are a lot of other formats that solve these problems (eg YAML, which certainly has other unrelated problems). There are trade offs with the various formats. Think about your use cases and pick the one that fits them the best.

brianpgordon 8y ago

In the Scala world, HOCON addresses a lot of these (except programmability, which I think is probably a bad idea).

patsplat 8y ago
Not just Scala https://github.com/yellowblood/hocon-js https://github.com/yellowblood/hocon-js
- azernik 8y ago
  Whole bunch of other ports into different languages too: https://github.com/lightbend/config#other-apis-wrappers-ports-and-utilities https://github.com/lightbend/config#other-apis-wrappers-port... Thanks for pointing me to that - I'm working in Scala on server-side and JS on browser-side for a couple of years now, and sharing config would be nice. Still need object merging and value concatenation, which hocon-js doesn't support, but I'll keep an eye on it!
femto113 8y ago
The only config system I've worked on that ever felt even vaguely satisfying was built around the excellent Typesafe (now Lightbend) HOCON implementation. The fact that HOCON is a superset of both JSON and properties formats made adoption in a large org feasible since it could "just work" with the many already existing config files in those formats. While generalized programmability has obvious dangers, HOCON's ability to do variable substitution was super useful for the large amounts of config that was supposed to follow a convention, e.g. hostnames based on a template like ${service}.${env}.example.com
azernik 8y ago
It has a few features that feel like programmability but really aren't, and I think these address most of the use cases that people want a Turing complete language for.

strags 8y ago

Take a look at HJSON.

roryokane 8y ago
I agree that HJSON is better for config files than JSON5, because of its more relaxed syntax requirements that making adding and editing values quicker. Link for HJSON: https://hjson.org/ https://hjson.org/ Compare to JSON5: https://json5.org/ https://json5.org/

TazeTSchnitzel 8y ago

Personally I'm partial to the classic Windows-style INI file. Because it was designed to be a human-editable configuration file format, it has a simple and intuitive format that is easy for both humans and machines: [Section] ; comment Key1=Value ; comment Key2=Value [Section2] Key1=Value It is also easy for machines to non-destructively edit, maintaining existing comments and formatting by humans, and applications take advantage of that. That is a big plus in my opinion.

Pxtl 8y ago
The problem with ini is that it has no good story for arrays or associative arrays. TOML attempts to fix this, but it provides ugly format for arrays and associative arrays.
- afiori 8y ago
  I personally find the TOML solution quite nice. In part because you can always drop to JSON syntax to avoid excessive nesting of array tables.
cheerlessbog 8y ago
TOML is arguably an evolution of ini format.
tinus_hn 8y ago
It is pretty limited and the worst part is quoting. What if your value contains \n? What about UTF8?
BuckRogers 8y ago
I agree, but my second choice if INI doesn't suit someone is just the standard app.config in Windows (trivial to interface with in the .Net space), or storing the values in a table. I'd prefer any of these before JSON or the other alternatives.
robocat 8y ago
Horrible for: UTF8, syntax checks, numbers (albeit JSON has this problem too for floats), deep nesting, arrays, strings as keys, consistency between different parsers, etc etc Good for: comments, readability if keys limited, familiarity.

naranha 8y ago

The alternative is javascript. Javascript gives you json with comments and programmability. And where possible .env.

cmroanirgo 8y ago
A lightweight ini reader in js I wrote a few years back: https://github.com/cmroanirgo/jsinf https://github.com/cmroanirgo/jsinf

jonathankoren 8y ago

Of course, JSON5 didn’t come out until 2017, and this was written in 2016.

darkpuma 8y ago

In cases where the file is written and read by the program, without the expectation that the user will typically edit or read the file by hand, sqlite is something that should be considered. A sqlite file isn't an ascii text file that you can edit with vi, so that suggestion is likely to get a lot of jeering, but it's a serious suggestion. It's already being used for configuration on all mobile platforms. There exists a wide range of applications, particularly for windows users, where the common user is not a developer and is not meant to be editing configuration by hand. Furthermore, access to the sqlite3 binary is very nearly as widespread as access to a vi binary. And self-styled developers who don't know SQL aside, it actually is a rather convenient format to edit by hand. Machine transformation of the config is obviously straight forward, and sqlite databases tend to be self-documenting anyway. Sane table and row names go a long way (obfuscated tables and rows would be roughly equivalent to obfuscated keys in an ini file...) and if that's not enough, comments for tables and rows can be stored in the schema. The one downside is strictness; sqlite doesn't enforce types. It does however have data constraints, which help.

willtim 8y ago

In my opinion, a statically typed config file would be preferable.

FraaJad 8y ago
See Dhall - https://dhall-lang.org/ https://dhall-lang.org/
- willtim 8y ago
  Yes I like Dhall, I also had a go at my own one a while ago: https://github.com/willtim/Expresso https://github.com/willtim/Expresso

zaphar 8y ago

I'm not sure what the the author would suggest but I'm increasingly of the opinion that config files formats should be treated as a compile target not a file that you edit. There are formats that are easier to edit than others and formats that are easier to parse than others. But sooner or later all of them end up being created by an ill-suited template engine or embedding a programming language in the syntax (cloudformation, ansible, hcl2). Why not treat the config file as a generated artifact that is readable but not written by a human. Tools like jsonnet (https://jsonnet.org/ https://jsonnet.org/), dhall-lang (https://dhall-lang.org/ https://dhall-lang.org/), or my personal side project ucg (https://ucg.marzhillstudios.com/ https://ucg.marzhillstudios.com/) allow you reuse values and safely generate your configuration formats with comments and logic all while bypassing the pitfalls of most formats. They give you a purpose built language for creating configurations with comments and logic w/o putting that burden on your application later. And it allows you to ignore the parts of a particular format that cause you problems.

terandle 8y ago
Create a good config file format and transpile that to a bad config file format for use in an application? I dunno I would rather just have the application use a decent config file format in the first place. It's just a config file, no need to overthink this with translation layers IMO.
- zaphar 8y ago
  No good config file format will allow you to share common shared values across all of the formats. That database host everything uses? You'll have to copy paste it everywhere or use a template engine to generate all of the formats. If you only have one application then it's overkill. When you have 10's of applications it's a life saver.
  - terandle 8y ago
    Good point. However hopefully whatever brilliant file format the source of truth is in will eventually end up being able to be consumed natively by the other applications and we can forgo the translation layer. Until then yes you have a good use case there.

ehsankia 8y ago

Wow, just looked at JSON5 and it's everything I could've ever hoped for! I remember distinctly looking for a JSON alternative that supports comments, trailing , and single quotes. This does all that and more. Now how long until it becomes standard (supported by python's default json library, browser's JSON.parse, etc).

h1d 8y ago
Somehow not widely spread. I can't believe json was standardized with all those shortcomings.

keymone 8y ago

EDIT: moved this comment to the root of the discussion https://news.ycombinator.com/item?id=19655249 https://news.ycombinator.com/item?id=19655249

gubbrora 8y ago

>Escaping quotes might be annoying, but I can't think of a possible alternative format where escaping isn't required at all. One nifty way of doing this is custom quote sequence. In C++ it works like R"delimiter( raw_characters )delimiter" As delimiter can be anything it can be chosen not to conflict with the payload. Bash has had the same trick for here documents for a long while.

afiori 8y ago

> a possible alternative format where escaping isn't required at all. HEREDOC-like format: #qweqwe123" string where everything is unquoted and is terminated by a " followed by qweqwe123. you can chose a short relevant sequence of alphanumeric chars as needed"qweqwe123#

arp242 8y ago

> So what's the author's proposed alternative? I am the author. It depends on your purpose; in general, I would say "the simplest solution that meets all needs", where "all needs" depends on what you're doing. In Python, this could be the configparser module, or parsing a Python file (again, depending on requirements). As a matter of taste, I prefer minimal syntax. I wrote a library with this syntax a while ago[1], although it's clearly not the best solution for every case. I should probably write a separate article about this. [1]: https://github.com/carpetsmoker/sconfig#what-does-it-look-like https://github.com/carpetsmoker/sconfig#what-does-it-look-li... > Lack of comments: not an issue with JSON5. JSON5 isn't JSON though. It's JSON5. None of the standard JSON parsers can deal with JSON5, you need a different JSON5 parser. > I think it's pretty readable A matter of taste. > just edit it with an editor that points at the errors quickly It seems to me that having to rely on such tools for issues such as this is not a great idea, especially not if it's easy to do better. > I can't think of a possible alternative format where escaping isn't required at all. There is a difference between "escaping isn't required at all" vs. "having to constantly and awkwardly escape a commonly used character". > Lack of programmability [..] VS Code seem to be doing fine without this. I've not used VSCode, As I'm a Vim guy. I can't imagine configuring Vim with just declarative configuration as so many useful parts come from being able to program Vim. This could be separated out to just an "extension" or "plugin" system, but I really like being able to just stick one or two lines of code in my vimrc and have it do something really useful, without writing a full plugin.

equasar 8y ago
for my tastes, sconfig is the opposite of human readable. IMO, JSON is good enough for the average cases of configuration files.
- Carpetsmoker 8y ago
  I'm curious why you would consider it to be "the opposite of human readable"? It has a minimal of syntax to parse, so at least in my view that should make it easier, rather than harder?

DonHopkins 8y ago

I have a proposal that I'm sure will make EVERYBODY happy by combining the best of both worlds! How about "J4X" (JSON for XML), that lets you embed XML in JSON the same way the ever-popular "E4X" (ECMAScript for XML) lets you embed XML in ECMAScript? https://developer.mozilla.org/en-US/docs/Archive/Web/E4X https://developer.mozilla.org/en-US/docs/Archive/Web/E4X J4X Example: <!DOCTYPE j4x PUBLIC "-//W3C//DTD J4X 1.0 Transitional//EN" "http://www.w3.org/TR/j4x/DTD/j4x-1.0-transitional.dtd"> { april: <fools late="13 days"/>  }

EdgarVerona 8y ago

Yes - I have seen at some jobs what a horror "configuration files" can be if you let people add programmability into them. Many years ago I worked at a job that made an XML tag-based language that was turing complete with the intent of it making their configuration "smarter". It ended up making the entire project much more difficult to debug, trace through, and even understand at all.

cturhan 8y ago

I thought he would suggest yml but he didn't. yml is good but, personally I don't like it. I find json file easier to read yml. It might be because of years of experience with json.