9 ms·

Or just use bloody YAML Seriously. Everything the others can do, it does better (or, at least as good - not gonna argue that YAML tags are pretty); and most im

Or just use bloody YAML Seriously. Everything the others can do, it does better (or, at least as good - not gonna argue that YAML tags are pretty); and most importantly, optionally. (Plus, it's got a few features the others don't) You don't have to use block text. You don't have to use quotations. You don't have to use tags, or references. A simple usage of YAML is simpler than any other. A complex use of YAML is still less complex than many uses of XML, but has the same information content.

bsandert 10y ago
Try writing YAML in combination with templating (such as in Salt). Because indentation means hierarchy, it's terrible. I'd much rather use JSON in such a context.
- vithlani 10y ago
  This is a problem with Salt's YAML abuse, not YAML.
- nojvek 10y ago
  What's salt?
  - ptman 10y ago
    Probably https://saltstack.com/ https://saltstack.com/
- RangerScience 10y ago
  I couldn't find an example of Salt on that site; more specifically, I couldn't find an example of the templating you're talking about. I didn't look very hard, but I'm spoiled by things like Sinatra, Coffeescript, and SlimLang. Can you point me at an example of what you're talking about? I can't really evaluate what you're saying with the information I have.
tie_ 10y ago
Agreed. JSON is the new XML. This isn't to say that I would prefer JSON over XML - I most definitely wouldn't - but it is just as abused lately. I hope we will see its demise soon and something coming out of the YAML line (e.g. TOML) getting more widespread.
- nojvek 10y ago
  TOML? First time I'm hearing of it
  - dozzie 10y ago
    Small, INI-like language for specifying configuration.
- RangerScience 10y ago
  TOML looks like slightly more complicated YAML (just because there are more sigils in a few places). I only skimmed the Github readme, what makes TOML better than YAML?
  - espadrine 10y ago
    Simplicity. That's at the expense of a few things, however. For instance, array can't contain objects of different types; even [ 1, 2.0 ] is not allowed. Also, having a map (aka. a dictionary) in an array is really awkward to write, and there probably are cases that simply can't be expressed. It has first-class dates, though. I wrote about the state of settings formats around the time that TOML was born: <http://espadrine.tumblr.com/post/44576550326/a-history-of-settings-file-format-and-dotset> http://espadrine.tumblr.com/post/44576550326/a-history-of-se....
    - tie_ 10y ago
      Thanks for the great article! It echoes most of my thoughts. And thanks for Dotset - didn't know it exists, but it looks very, very neat. In most but the most basic configurations, however, I found myself missing some of variables, inheritance, dates. TOML solves the last two, but as you point out it has limitations. YAML solves the first two, though in a bit of an ugly and obscure way. No wonder Salt and Ansible, two heavy users of YAML configs both pass it through templating engines to reach their goals. For the lack of better alternatives, I usually end up with a Django-style Python module holding the configuration when I want it to be powerful. It still freaks (non-Python) people out though. Lua is not a half-bad choice if you ask me. It takes some time getting used to, but it's fast to interpret, and at least one project that I know of - Lsyncd - is making an absolutely great layered configuration on top of it.
mahyarm 10y ago
YAML & XML serialize / deserialize is slower than its JSON equivalent. On top of that schema assisted JSON serialization can be almost as fast as something like protobuf, but you don't have to deal with binary or a lot of codegen on both sides.
- RangerScience 10y ago
  Why? Is that a consequence of the specification, or an artifact of the implementations? Or, as in the case of XML, a consequence of common usage? PS - I'm not counting the inherent different from simply more characters as important: <obj> <string>foo</string> <obj> obj: string: foo { "obj": { "string":"foo"} } That's not important. If you have enough extra characters for that to be important, you have enough data that you should probably do something other than serialize to text.
  - mahyarm 10y ago
    XML is significantly more complicated and creates a tree structure that doesn't map 1:1 to common programming strings, arrays, dictionaries and numbers. It creates nodes with attributes in a tree structure with namespaces and whole bunch more. The consumer parsing code is significantly more complicated too. YAML is missing things such as quote marks so you have to do things such as type inference to determine what an item is, which decreases speed. I don't know the specifics more than that, but just do serialization benchmarks and you'll see it pretty quickly.
jerf 10y ago
The extensive optionality of YAML is probably also the very thing that has held it back and prevented it from ever quite breaking into the mainstream. It's very complicated, and yet, for all that additional complication, doesn't bring that much additional functionality. Options are not intrinsically good; they always incur a cost and the options must be worth more than their cost. To my eye YAML has always been designed with the premise that options carry intrinsic benefits rather than costs, which is a major design mistake.
- RangerScience 10y ago
  You're talking about something like, but not exactly, choice paralysis? It's possible that's part of what's going on, but... I don't think so. Or, not so cleanly. YAML options aren't choices, they're things you can do if you end up wanting to. This is a theme in Ruby (and then Rails) programming. There's a bunch of stuff you can use, but you don't have to, and probably won't. There's an effect there, but it's not the same as choice paralysis. -- I don't see what you see - that YAML was designed with the idea that options are intrinsicially valuable - it said, "Here's a thing to do. What's the simplest way to do this?". Well-executed simplicity leads to options - think grep. There's a bunch of options when using grep, but really, it just does the one thing... but then there's a bunch of ways to use that one thing. Again, this is a Ruby thing. There's more than one way to do it because there's more than one situation in which you'll need to. Have a simple array? Brackets. Have a not simple array? Dash. In either case, it's pretty much the simplest way to do it, but one doesn't work (as well, or at all) for the other situation.
  - jerf 10y ago
    This is one of those duality things that comes up so often in programming and math: What is optional from the point of view of the user of the format is mandatory from the implementer's point of view. Pointing out that it's optional for the user does not remove the additional complexity the implementer must pay. YAML is a lot more complicated than JSON, and it's not all different ways of spelling the same thing (which is a sort of complexity that at least isolates itself to the parser), it's genuinely richer and more complex, and that price gets paid by somebody. Focusing on the one not paying that price doesn't make it go away. Further, "YAML is not as popular as JSON" is an observational fact, not something we can argue away. It's worth trying to figure out why and learning what we can from it. I've made my proposal. There are other options ("Javascript is a steamroller"). But I'm not really a big fan of the evergreen "other people are just too stupid to see the obvious truth" explanation, which is generally the one that seems to be given to explain why YAML hasn't beaten JSON. That explanation is almost always wrong. (Only almost, though.)
skrebbel 10y ago
Wait, did you read the article? How does YAML help with specifying JSON? Or with specifying YAML, for that matter?
- RangerScience 10y ago
  YAML supports tags, which could describe schema. JSON doesn't. Every method to describe schema for JSON will work for YAML, plus extras - like tags, and you could use node references to basically define types, and re-use them throughout. Sometimes I feel like I'll go to Ruby hell for saying this, but as far as I can tell, XML is actually really good at that part... because it's a markup syntax, not a data syntax, while JSON and YAML are data syntaxes, not markups.

bsandert 10y ago

Try writing YAML in combination with templating (such as in Salt). Because indentation means hierarchy, it's terrible. I'd much rather use JSON in such a context.

vithlani 10y ago
This is a problem with Salt's YAML abuse, not YAML.
nojvek 10y ago
What's salt?
- ptman 10y ago
  Probably https://saltstack.com/ https://saltstack.com/
RangerScience 10y ago
I couldn't find an example of Salt on that site; more specifically, I couldn't find an example of the templating you're talking about. I didn't look very hard, but I'm spoiled by things like Sinatra, Coffeescript, and SlimLang. Can you point me at an example of what you're talking about? I can't really evaluate what you're saying with the information I have.

tie_ 10y ago

Agreed. JSON is the new XML. This isn't to say that I would prefer JSON over XML - I most definitely wouldn't - but it is just as abused lately. I hope we will see its demise soon and something coming out of the YAML line (e.g. TOML) getting more widespread.

nojvek 10y ago
TOML? First time I'm hearing of it
- dozzie 10y ago
  Small, INI-like language for specifying configuration.
RangerScience 10y ago
TOML looks like slightly more complicated YAML (just because there are more sigils in a few places). I only skimmed the Github readme, what makes TOML better than YAML?
- espadrine 10y ago
  Simplicity. That's at the expense of a few things, however. For instance, array can't contain objects of different types; even [ 1, 2.0 ] is not allowed. Also, having a map (aka. a dictionary) in an array is really awkward to write, and there probably are cases that simply can't be expressed. It has first-class dates, though. I wrote about the state of settings formats around the time that TOML was born: <http://espadrine.tumblr.com/post/44576550326/a-history-of-settings-file-format-and-dotset> http://espadrine.tumblr.com/post/44576550326/a-history-of-se....
  - tie_ 10y ago
    Thanks for the great article! It echoes most of my thoughts. And thanks for Dotset - didn't know it exists, but it looks very, very neat. In most but the most basic configurations, however, I found myself missing some of variables, inheritance, dates. TOML solves the last two, but as you point out it has limitations. YAML solves the first two, though in a bit of an ugly and obscure way. No wonder Salt and Ansible, two heavy users of YAML configs both pass it through templating engines to reach their goals. For the lack of better alternatives, I usually end up with a Django-style Python module holding the configuration when I want it to be powerful. It still freaks (non-Python) people out though. Lua is not a half-bad choice if you ask me. It takes some time getting used to, but it's fast to interpret, and at least one project that I know of - Lsyncd - is making an absolutely great layered configuration on top of it.

mahyarm 10y ago

YAML & XML serialize / deserialize is slower than its JSON equivalent. On top of that schema assisted JSON serialization can be almost as fast as something like protobuf, but you don't have to deal with binary or a lot of codegen on both sides.

RangerScience 10y ago
Why? Is that a consequence of the specification, or an artifact of the implementations? Or, as in the case of XML, a consequence of common usage? PS - I'm not counting the inherent different from simply more characters as important: <obj> <string>foo</string> <obj> obj: string: foo { "obj": { "string":"foo"} } That's not important. If you have enough extra characters for that to be important, you have enough data that you should probably do something other than serialize to text.
- mahyarm 10y ago
  XML is significantly more complicated and creates a tree structure that doesn't map 1:1 to common programming strings, arrays, dictionaries and numbers. It creates nodes with attributes in a tree structure with namespaces and whole bunch more. The consumer parsing code is significantly more complicated too. YAML is missing things such as quote marks so you have to do things such as type inference to determine what an item is, which decreases speed. I don't know the specifics more than that, but just do serialization benchmarks and you'll see it pretty quickly.

jerf 10y ago

The extensive optionality of YAML is probably also the very thing that has held it back and prevented it from ever quite breaking into the mainstream. It's very complicated, and yet, for all that additional complication, doesn't bring that much additional functionality. Options are not intrinsically good; they always incur a cost and the options must be worth more than their cost. To my eye YAML has always been designed with the premise that options carry intrinsic benefits rather than costs, which is a major design mistake.

RangerScience 10y ago
You're talking about something like, but not exactly, choice paralysis? It's possible that's part of what's going on, but... I don't think so. Or, not so cleanly. YAML options aren't choices, they're things you can do if you end up wanting to. This is a theme in Ruby (and then Rails) programming. There's a bunch of stuff you can use, but you don't have to, and probably won't. There's an effect there, but it's not the same as choice paralysis. -- I don't see what you see - that YAML was designed with the idea that options are intrinsicially valuable - it said, "Here's a thing to do. What's the simplest way to do this?". Well-executed simplicity leads to options - think grep. There's a bunch of options when using grep, but really, it just does the one thing... but then there's a bunch of ways to use that one thing. Again, this is a Ruby thing. There's more than one way to do it because there's more than one situation in which you'll need to. Have a simple array? Brackets. Have a not simple array? Dash. In either case, it's pretty much the simplest way to do it, but one doesn't work (as well, or at all) for the other situation.
- jerf 10y ago
  This is one of those duality things that comes up so often in programming and math: What is optional from the point of view of the user of the format is mandatory from the implementer's point of view. Pointing out that it's optional for the user does not remove the additional complexity the implementer must pay. YAML is a lot more complicated than JSON, and it's not all different ways of spelling the same thing (which is a sort of complexity that at least isolates itself to the parser), it's genuinely richer and more complex, and that price gets paid by somebody. Focusing on the one not paying that price doesn't make it go away. Further, "YAML is not as popular as JSON" is an observational fact, not something we can argue away. It's worth trying to figure out why and learning what we can from it. I've made my proposal. There are other options ("Javascript is a steamroller"). But I'm not really a big fan of the evergreen "other people are just too stupid to see the obvious truth" explanation, which is generally the one that seems to be given to explain why YAML hasn't beaten JSON. That explanation is almost always wrong. (Only almost, though.)

skrebbel 10y ago

Wait, did you read the article? How does YAML help with specifying JSON? Or with specifying YAML, for that matter?

RangerScience 10y ago
YAML supports tags, which could describe schema. JSON doesn't. Every method to describe schema for JSON will work for YAML, plus extras - like tags, and you could use node references to basically define types, and re-use them throughout. Sometimes I feel like I'll go to Ruby hell for saying this, but as far as I can tell, XML is actually really good at that part... because it's a markup syntax, not a data syntax, while JSON and YAML are data syntaxes, not markups.