625
TOML (europe.pub)
submitted 7 months ago by to c/programmer_humor@programming.dev
159 comments fedilink hide all child comments
 

top 50 comments

sorted by: hot top controversial new old
[–] 226 points 7 months ago (43 children)

JSON is like the carcinization of programming

  • permalink
  • fedilink
  • source
  • hideshow 43 child comments
    •
  • [–] 85 points 7 months ago (18 children)

    Chuck in comments and I'm on board.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 18 child comments
    •
  • [–] 97 points 7 months ago (4 children)

    If we’re adding comments to json, can we add canonical support for trailing commas?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 31 points 7 months ago (3 children)

    Found the python guy!

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 23 points 7 months ago (8 children)

    They were chucked out because, according to the guy who defined it, people started using them for parsing directives, which hurt interoperability because now you needed to be sure that the parser would both read the comments and interpret them correctly. Suddenly, those comments might make otherwise identical files parse differently. If the whole point is that it's reliable and machine-readable, keeping it to the minimal set of features and not extending it any way whatsoever is a good way to ensure compatibility.

    What you can do is define some property for comments. It's not standardised, but you could do stuff like

    {
  "//": "This is a common marker for comments",
  "#": "I've never seen that as a property name, so it might be safe?",
  "_comment": "Property names with underscore for technical fields seem common enough as well, and it's semantically explicit about its purpose"
}
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 15 points 7 months ago (2 children)

    And also, JSON was intended as a data serialisation format, and it's not like computers actually get value from the comments, they're just wasted space.

    People went on to use JSON for human readable configuration files, and instantly wanted to add comments, rather than reconsider their choice because the truth is that JSON isn't a good configuration format.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
    load more comments (2 replies)
    • load more comments (5 replies)
    • load more comments (2 replies)
  • [–] 43 points 7 months ago

    Well...

    It's name-value pairs, with groups denoted by balanced brackets. It's close to as good as you can get for one kind of data serialization.

    What is impressive is how many problems people manage to fit in something so small.

  • permalink
  • fedilink
  • source
  • parent
    • load more comments (16 replies)
    [–] 168 points 7 months ago (8 children) 
    orange = {
    you = "glad",
    I = {
        didn\'t = {
            say = "banana"
        }
    }
}
  • permalink
  • fedilink
  • source
  • hideshow 8 child comments
    •
    • [–] 99 points 7 months ago (21 children)

    If yaml didn’t have anchors and 8 different white space formats, it’d be a great replacement for this kind of thing.

    But yaml is a mess, and you’d think you could parse it easily, but you can’t.

  • permalink
  • fedilink
  • source
  • hideshow 21 child comments
    •
  • [–] 62 points 7 months ago (4 children)

    YAML is redeemed by one thing only:

    All JSON is valid YAML.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 12 points 7 months ago (3 children)

    No way. You're telling me I can just write json instead?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
    • load more comments (5 replies)
    [–] 90 points 7 months ago (16 children)

    Time to read this if you haven't already

    https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell

  • permalink
  • fedilink
  • source
  • hideshow 16 child comments
    •
  • [–] 38 points 7 months ago (10 children)

    The json spec is not versioned. There were two changes to it in 2005 (the removal of comments

    See, this is why we can't have nice things.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
    • load more comments (4 replies)
    [–] 48 points 7 months ago (28 children)

    I like this. I also like yaml, I've had very few issues with it and it's nicer to work with than json.

    Json's lack of support for trailing commas and comments makes it very annoying for everyday use.

  • permalink
  • fedilink
  • source
  • hideshow 28 child comments
    •
  • [–] 61 points 7 months ago (23 children)

    Significant white-space is bullshit and i will die on this hill.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 23 child comments
    •
    • load more comments (15 replies)
    • load more comments (4 replies)
    [–] 47 points 7 months ago (1 child)

    TOML's design is based on the idea that INI was a good format. This was always going to cause problems, as INI was never good, and never a format. In reality, it was hundreds of different formats people decided to use the same file extension for, all with their own incompatible quirks and rarely any ability to identify which variant you were using and therefore which quirks would need to be worked around.

    The changes in the third panel were inevitable, as people have data with nested structure that they're going to want to represent, and without significant whitespace, TOML was always going to need some kind of character to delimit nesting.

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
    • [+] 38 points 7 months ago* (last edited 3 months ago) (9 children)
    [deleted]
  • permalink
  • fedilink
  • source
  • hideshow 9 child comments
    •
  • [–] 24 points 7 months ago* (last edited 7 months ago) (2 children)

    It’s basically just JSON that can generate itself !

    You have inspired me.

    I will make JSON with meta-programming

    I will call it DyJSON, i.e. "Dynamic JSON" but pronounced "Die, Jason!"

    It is JSON with meta-programming and the ability to call C functions from libraries

    Example:

    # This is a line comment

# Put your function definitions up here
(concat str_a str_b: "concat" "my-lib.so") # Import a function through a C ABI
(make-person first_name last_name email -> { # Define our own generative func
    "name": (concat (concat $first_name " ") $last_name),
    "email": $email
})

# And then the JSON part which uses them
[
    (make-person "Jenny" "Craig" "jenn.craig.420@hotmail.com"),
    (make-person "Parson" "Brown" null)
]

    As you can see, it is also a LISP to some degree

    Is there a need for this? A purpose? No. But some things simply should exist

    Thank you for helping bring this language into existence

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
    • load more comments (1 reply)
    • load more comments (3 replies)
    [–] 28 points 7 months ago (1 child)

    If this is where the toml train ends I will be happy with it. If they do a yaml, I will be very upset.

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
    load more comments (1 reply)
    [–] 24 points 7 months ago (2 children)

    As someone who likes lua, I don't see the problem.

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
  • [–] 14 points 7 months ago

    The very minor and nitpicky problem is that if you want JSON just use JSON. there's still a place in the world for human readable/ editable configs that don't require linters to be run on them after. (Current TOML is fine, I like it).

  • permalink
  • fedilink
  • source
  • parent
    • load more comments (1 reply)
    [–] 14 points 7 months ago

    No, sir. That's an inline table, sir. That is clearly totally different, sir!

  • permalink
  • fedilink
  • source
    •
    load more comments
    view more: next ›