Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Because JSON is native to the lingua franca of the internet: Java-/Ecmascript.

    It fits into the poor choices we made, <-- Parse error

  • Somewhat off topic, but Oracle database connection strings seem to be a form of Lisp. It makes me wonder why they would choose that.
  • Let me guess... if they're a form of Lisp, did someone add jndi support, then made it possible to print to the console while the string gets read and finally made it executable because who wouldn't want a LISP for-loop in an Oracle connection string? On to the next RCE...
  • I looked them up, and they’re not lisp (or s-expressions)

        SERVER=(DESCRIPTION (ADDRESS=(PROTOCOL=TCP)(HOST=MyHost)(PORT=MyPort))(CONNECT_DATA=(SERVICE_NAME=MyOracleSID)));uid=myUsername;pwd=myPassword;
    by eska
  • > Why do so many tools have JSON config files‽

    Because XML hasn't been cool for about two decades. And suggesting .ini would you laughed out of the room into retirement.

  • I wish everyone would embrace Amazon's Ion format. Of the data serialization formats it seems the most reasonable with the exception that it can encode S-expressions (so like having data serialization within your data serialization), so it is a bit excessive.

    https://en.wikipedia.org/wiki/Ion_(serialization_format)

  • At a previous employer we tried using Ion, but when they stopped supporting our QLDB it was obvious that nothing else really used it and it was a dead end.

    Shame.

  • because JSON is in the following sense "universal":

    every format/structure that has numbers, strings, booleans, null/none, finite lists of items, and string-indexed records of items already contains JSON

    and that's pretty much the barebones you need for a configuration language

    (of course you can argue about the syntax)

  • It's so simple and straightforward, and that's why Douglas Crockford claims he "discovered" it, rather than invented it.
  • That is not quite true, because you have to define "numbers" and "strings" more specifically; JSON uses Unicode strings, and how numbers work depends on the implementation (but are generally finite 64-bit IEEE floating point; JSON does not have Infinity and NaN).

    ASN.1 is almost a superset, but lacks a key/value list type; I had made some nonstadard extensions called ASN.1X and one of my new types is a key/value list type, so that makes the data types of ASN.1X a superset of JSON (although the format is different, it makes that all JSON data can be represented using DER if the nonstandard key/value list type of ASN.1X is used).

    I don't like JSON that much because of its many problems (some are problems with syntax, others are problems with the data), so I use ASN.1X instead (with the DER format), for my own stuff (but I also deal with JSON because it is common enough).

  • Lack of comments is pretty big though for a human editable config.
  • For our internal tooling we use something similar to a bash profile config file with name/value pairs separated by linebreaks. So, our configs look something like:

    env=staging

    db=0.0.0.0

    #descriptive comment

    etc=true

  • ini file format is pretty much this

    [section_name]

    key=value

    key=value

  • In my opinion, JSON is not the best format and has some problems. Lack of comments is one of the reasons, as they mention in there. Another is the lack of trailing commas (optional trailing commas would be useful for manually written files). However, these are problems with the syntax, and there are also problems with the data, such as a lack of a proper integer type, lack of Infinity and NaN, lack of support for character sets other than Unicode (and ASCII), lack of proper octet string type, etc.
  • I really like the EDN[1][2] (extensible data notation) format that is used mostly by Clojure for config and data transfer/exchange. It is so much more expressive than JSON and supports a well thought-out set of elements for the most common data structures.

    [1]: https://github.com/edn-format/edn

    [2]: https://en.wikipedia.org/wiki/Clojure#Extensible_Data_Notati...

  • For Caddy we chose JSON because it's fairly universal, maps nearly 1:1 with Go structs (useful for initializing an extensible server), and nearly everything else compiles to JSON one way or another, so you can choose your own config format, really: https://caddyserver.com/docs/config-adapters
  • Hey, thanks for Caddy! It's awesome :).
  • > Why do so many tools have JSON config files‽

    1: Because JSON is a very easy serialization format to work with. I suspect these tools all have configuration classes / objects that are deserialized straight from the config file.

    2: I suspect a lot of these tools are written in Javascript, and in Javascript JSON is very easy to work with.

  • JSON is probably the easiest format to work with regardless of language.
  • > A lot of tech folks resist documentation because they think it provides them with job security.

    No, we're just lazy.

  • It's readable, it's easy, it gets the job done.

    I don't think that's necessarily lazy, it's just efficient

  • Occam's Razor at it's finest. I'm not trying to screw others over. I just want to not write sometimes.
  • Which is better than the all too common middle ground: writing something once and then not maintaining it. I've been burned many times reading some documentation and thinking I understood until I discovered the code has changed since and the documentation is now wrong.

    I'm in favor of documentation. I write it. I get people pointing at what I've written as examples of what everybody should do. However it is a lot of work. I'm constantly looking things over to be sure it still makes sense. I often wonder if it is really worth it. I hope you follow my example and write documentation, but it better feel like a lot of work.

  • > Why do so many tools have JSON config files‽ Commenting why options have been set the way they have is just such a basic thing to want to do… Why do tech people have such an aversion to writing things down⁇

    That's the whole post. First I don't know why this is posted on HN. Second I don't see how "JSON config" and "writing things down" are the two opposite options.

  • > That's the whole post. First I don't know why this is posted on HN. Second I don't see how "JSON config" and "writing things down" are the two opposite options.

    The "writing things down bit" is in the context of commenting. I mean, it's literally in the same paragraph.