3 ms·

In practice there aren't many languages that support anything more than yaml 1.0 from my last look a few years ago. Ie yaml isn't nearly as supported as it loo

In practice there aren't many languages that support anything more than yaml 1.0 from my last look a few years ago. Ie yaml isn't nearly as supported as it looks once you start actually trying to use it between languages with anything more than 1.0 as most of the purported library support seemed to be roughly 2009 abandonware. Yaml also precludes easy https://www.sqlite.org/json1.html https://www.sqlite.org/json1.html and postgresql jsonb etc. Not to mention trivial js consumption of the file. Superset or not, Yaml automagically introduces bugs to and from json through the magic powers of more lines of code involved. Most projects would have a hard time not having a json library these days? I've not done a survey of music apps though. In practice, as someone that has been vim/emacs for a few decades I'd put a low priority on yaml vs json text editability. They are about the same for changing a few characters and I'd probably use orgmode+ python to do anything non-trivial but not full program(and probably drive the transform via json data from somewhere...). In 2017 yaml doesn't seem tasteful for this format.

StavrosK 10y ago
Really? For me, editing JSON is always a chore, because you have to match the multiple nested brackets, otherwise your whole file is invalid and you get to have fun finding out what you did wrong. YAML, in comparison, can be visually inspected quickly. However, with all the apprehension in the thread, I'm rethinking this decision. Maybe TOML would be better?
- hammerandtongs 10y ago
  Pretty printed json isn't too bad, but I intentionally never bulk edit it. This format shouldn't end up heavily nested anyway? Toml is nice for simple configs/Cargo.toml but I think everything I said basically applies to it as well. Toml has recent work on it in 2017 for some (but not broad) library support but what does it look like in 2024?
  - StavrosK 10y ago
    Yeah, good point (plus it's not fantastic for this project anyway). I'm going to think hard on this, I quite like YAML...
    - hammerandtongs 10y ago
      Fwiw I like yaml as well but it's just got a few too many issues these days. While you are thinking maybe look at this https://stedolan.github.io/jq/ https://stedolan.github.io/jq/ and how people could leverage it when using your format.
      - StavrosK 10y ago
        Ah yes, I know about jq, it's fantastic. I've switched to JSON, with heavy heart, but YAML seems too big indeed.
  - masklinn 10y ago
    > I think everything I said basically applies to it as well. TOML is a much simpler format than YAML, and is a dialect/formalisation of INI files which have yet to go out of style. Direct database storage seems like a red herring (why would you want to store a playlist as a json blob?), so does "trivial JS consumption of the file". [0] the entire spec is 10 pages, and that's with lots of examples, YAML 1.2 is ~80 pages
- bostonvaulter2 10y ago
  I, on the other hand, loathe editing YAML configuration files because the nesting is so obtuse and difficult to figure out based on limited examples in open source projects. JSON is much easier.
StavrosK 10y ago
I finally changed my mind and switched to JSON after I tried to write pls2upl and realized that YAML is much larger than I thought, and with so many features that incompatibilities between clients would be a real problem.

StavrosK 10y ago

Really? For me, editing JSON is always a chore, because you have to match the multiple nested brackets, otherwise your whole file is invalid and you get to have fun finding out what you did wrong. YAML, in comparison, can be visually inspected quickly. However, with all the apprehension in the thread, I'm rethinking this decision. Maybe TOML would be better?

hammerandtongs 10y ago
Pretty printed json isn't too bad, but I intentionally never bulk edit it. This format shouldn't end up heavily nested anyway? Toml is nice for simple configs/Cargo.toml but I think everything I said basically applies to it as well. Toml has recent work on it in 2017 for some (but not broad) library support but what does it look like in 2024?
- StavrosK 10y ago
  Yeah, good point (plus it's not fantastic for this project anyway). I'm going to think hard on this, I quite like YAML...
  - hammerandtongs 10y ago
    Fwiw I like yaml as well but it's just got a few too many issues these days. While you are thinking maybe look at this https://stedolan.github.io/jq/ https://stedolan.github.io/jq/ and how people could leverage it when using your format.
    - StavrosK 10y ago
      Ah yes, I know about jq, it's fantastic. I've switched to JSON, with heavy heart, but YAML seems too big indeed.
- masklinn 10y ago
  > I think everything I said basically applies to it as well. TOML is a much simpler format than YAML, and is a dialect/formalisation of INI files which have yet to go out of style. Direct database storage seems like a red herring (why would you want to store a playlist as a json blob?), so does "trivial JS consumption of the file". [0] the entire spec is 10 pages, and that's with lots of examples, YAML 1.2 is ~80 pages
bostonvaulter2 10y ago
I, on the other hand, loathe editing YAML configuration files because the nesting is so obtuse and difficult to figure out based on limited examples in open source projects. JSON is much easier.

StavrosK 10y ago

I finally changed my mind and switched to JSON after I tried to write pls2upl and realized that YAML is much larger than I thought, and with so many features that incompatibilities between clients would be a real problem.