this post was submitted on 02 Sep 2024
218 points (97.8% liked)

Programming

20064 readers
99 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 2 years ago
MODERATORS
 

There are a couple I have in mind. Like many techies, I am a huge fan of RSS for content distribution and XMPP for federated communication.

The really niche one I like is S-expressions as a data format and configuration in place of json, yaml, toml, etc.

I am a big fan of Plaintext formats, although I wish markdown had a few more features like tables.

(page 2) 50 comments
sorted by: hot top controversial new old
[–] [email protected] 3 points 8 months ago* (last edited 8 months ago)

djot for text markup. It addresses a lot of the issues in Common mark (and of course far more of the issues of Markdown).

[–] [email protected] 2 points 8 months ago* (last edited 8 months ago) (1 children)

I'd like something akin to XML DOM for config files, but not XML.

The one benefit of binary config (like the Windows Registry) is that you can make a change programmatically without too many hoops. With text files, you have a couple of choices for programmatic changes:

  • Don't
  • Parse it, make the change, and rewrite it (clobbering comments and whitespace that the user setup; IIRC, npm does this)
  • Have some kind of block that says "things below this line were automatically set and shouldn't be touched" (Klipper does this)
  • Have a parser that understands the whole structure, including whitespace and comments, and provides an interface for modifying things in place without changing anything around it (XML DOM)

That last one probably exists for very specific formats for very specific languages, but it's not common. It's a little more cumbersome to use as a programmer--anyone who has worked with XML DOM will attest to that--but it's a lot nicer for end users.

load more comments (1 replies)
[–] [email protected] 18 points 8 months ago* (last edited 8 months ago) (1 children)

I wish standards were always open access. Not behind a 600 dollar paywall.

When it is paywalled I'm irritated it's even called a standard.

load more comments (1 replies)
[–] [email protected] 14 points 8 months ago (3 children)

TOML instead of YAML or JSON for configuration.

YAML is complex and has security concerns most people are not aware of.

JSON works, but the block quoting and indenting is a lot of noise for a simple category key value format.

[–] [email protected] 2 points 8 months ago

People bitch about YAML but for me it's still the preferred one just because the others suck more.

TOML like said is fine for simple things but as soon as you get a bit more complex it's messy and unwieldy. And JSON is fine to operate on but for a config? It's a mess. It's harder to type and read for something like a config file.

Heck, I'm not even sold on the S-expressions compared to yaml yet. But then, I deal with so much with all of these formats that I simply still prefer YAML for readability and ease of use (compared to the others.)

[–] [email protected] 14 points 8 months ago (3 children)

YAML is complex and has security concerns most people are not aware of.

YAML is racist to Norwegians.

If you have something like country: NO (NO = Norway), YAML will turn that into country: False. Why? Implicit casting. There are a bunch of truthy strings that'll be cast automagically.

load more comments (3 replies)
[–] [email protected] 15 points 8 months ago (2 children)

TOML is not a very good format IMO. It's fine for very simple config structures, but as soon as you have any level of nesting at all it becomes an unobvious mess. Worse than YAML even.

What is this even?

[[fruits]]
name = "apple"

[fruits.physical]
color = "red"
shape = "round"

[[fruits.varieties]]
name = "red delicious"

[[fruits.varieties]]
name = "granny smith"

[[fruits]]
name = "banana"

[[fruits.varieties]]
name = "plantain"

That's an example from the docs, and I have literally no idea what structure it makes. Compare to the JSON which is far more obvious:

{
  "fruits": [
    {
      "name": "apple",
      "physical": {
        "color": "red",
        "shape": "round"
      },
      "varieties": [
        { "name": "red delicious" },
        { "name": "granny smith" }
      ]
    },
    {
      "name": "banana",
      "varieties": [
        { "name": "plantain" }
      ]
    }
  ]
}

The fact that they have to explain the structure by showing you the corresponding JSON says a lot.

JSON5 is much better IMO. Unfortunately it isn't as popular and doesn't have as much ecosystem support.

load more comments (2 replies)
load more comments
view more: ‹ prev next ›