this post was submitted on 06 Sep 2024
62 points (73.8% liked)

Programming

17670 readers
215 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 !webdev@programming.dev

founded 2 years ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
MaungaHikoi@lemmy.nz
62
Why YAML sucks? (programming.dev)
submitted 3 months ago* (last edited 3 months ago) by heikkiket@programming.dev to c/programming@programming.dev
146 comments fedilink hide all child comments
 

I feel that Yaml sucks. I understand the need for such markup language but I think it sucks. Somehow it's clunky to use. Can you explain why?

you are viewing a single comment's thread
view the rest of the comments
[–] mox@lemmy.sdf.org 26 points 3 months ago* (last edited 3 months ago)

One pattern I've noticed is people seeking a language that's better than {JSON,XML,INI,etc} at wrangling their slightly complex configuration files, noticing the additional features and type support offered by YAML, and assuming it will be a good solution.

Then, as their configs grow ever larger and more complex, they discover that expressing them in YAML requires large sections of deep nesting, long item sequences, and line wrapping. The syntax style that they saw working well in other places (e.g. certain programming languages) breaks down quickly at that level of complexity, making it difficult for humans to correctly write and follow, and leading to frequent errors.

YAML doesn't suck for small stuff, IMHO. (But it is more complex than necessary for small stuff.)

For things likely to grow to medium-large size or complexity, I would recommend either breaking up the data into separate files, or looking for a different config/serialization language.