Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Well, the idea is not to generate json files, the idea is to not use json files at all.

And even if you don't want to implement logic in config file, there are still advantages in having access to a full language.

For example: with a simple config file

  maxAttachmentSize: 33554432,
  maxTotalSize: 33816576
with a full language

  maxAttachmentSize = 32 * 1024 * 1024; // 32 MB covers 99% of use cases
  maxTotalSize = (256 * 1024) + maxAttachmentSize; // 256 kB of text + one big attachment
No logic here, just a more readable file. But that uses several things json doesn't support: comments, arithmetic and variables.


If you give a fully loaded programming language to a programmer to write configuration, It's almost a certainty that you will end up with a program in your configuration file. With great power come great responsibilities but unfortunately not all of us are super heroes.


You don’t need a full blown programming language for that, just a configuration language with some basic expressions.

Your example is fine, it’s certainly more pleasant than not doing it that way, but that’s not where the trouble starts: the trouble begins when you have conditions and loops and any non-trivial logic.

If you need non-trivial logic then it probably isn’t “configuration” and should be part of the normal codebase (and go through the same review and testing procedures).

I would also argue that if your system is so complex that you need a programming language to configure it, there’s something very very wrong.


If that's the best example, I'd almost count that as an argument against.

    maxAttachmentSize: 33554432 # 32MB
    maxTotalSize: 33816576      # 256kB + maxAttachmentSize
All the "full language" version is done is avoided me having to use the incredibly powerful calculator I'm sitting in front of to calculate some numbers for all of 5 seconds.

Programatically solving something which changes very infrequently isn't really a good case for all the other complexity and potential issues something like this would drag along with it.


> maxAttachmentSize: 33554432 # 32MB

That works until person 1 updates the value, but does not notice the comment duplicates it, then person 2 spends hours figuring out why he can't upload 30MB file, while he can clearly see in the config, that it allows up to 32MB, and his debugger tells him limit value actually matches that long number.


I really don't like JSON for configuration. I prefer TOML or YAML for config file definition. But I would also make sure my config item names are descriptive enough to where I know units from the name, e.g. maxAttachmentSizeBytes. Any other comments I usually prefer to put in my code that loads the config files into my program.


I’m a big fan of TOML. It’s not perfect, but as a configuration format, it does the job much better (imho) than the alternatives.


The other option is to pull in the one of many libs it there that can understand suffixes (or even write your own... Really not that hard).

As a bonus, your config is more readable.


With a configuration language one could use

maxTotalSize: 1MB

Or similar.


And then have to parse and translate that to a workable value in their program...precisely (part of) the problem the article is pointing out




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: