261–270 of 339 posts
Earlier quoted context omitted.
Looks fine to me: [[a.b]] c = 1 d = [ { e = 2 }, { f = { g = 3 } } ]
An improvement, but the original YAML is still significantly better, in my opinion.
Earlier quoted context omitted.
XML and XML Schema solved this more than 20 years ago. It had to be replaced with JSON by the web developers though, so they could just “eval() it” to get their data.
If all the smart people like you used XML, how come it was so painful to use and it died?
I had a chance of using SOAP at one point. It was a F5 device and I used a python library. What I really liked is that when it connected to it it downloaded its schema, and then used that to generate an object. At that point you just communicated with device like you did with any object in Python.
We abandoned it for inferior technologies like REST and JSON, because they were harder to use from JS, as parent mentioned.
The world desperately needs a replacement for YAML. TOML is fine for configuration, but not an adequate solution for representing arbitrary data. JSON is a fine data exchange format, but is not particularly human-friendly, and is especially poor for editable content: Lacks comments, multi-line strings, is far too strict about unimportant syntax, etc. Jsonnet (a derivative of Google's internal configuration language)…
XML and XML Schema solved this more than 20 years ago. It had to be replaced with JSON by the web developers though, so they could just “eval() it” to get their data.
The world desperately needs a replacement for YAML. TOML is fine for configuration, but not an adequate solution for representing arbitrary data. JSON is a fine data exchange format, but is not particularly human-friendly, and is especially poor for editable content: Lacks comments, multi-line strings, is far too strict about unimportant syntax, etc. Jsonnet (a derivative of Google's internal configuration language)…
S-expressions are super easy to parse and are fairly easy for humans to read. See e.g. using s-expressions in OCaml: https://dev.realworldocaml.org/data-serialization.html
You get neat ways of nesting data, but that is not enough for a robust and mistake-resilient configuration language.
The problem isn't parsing in itself. The problem is having clear sematics, without devolving into full SGML DTDs (or worse still, XML schemas).
Earlier quoted context omitted.
That’s a shrewd observation. Static types help with this somewhat. E.g. in Inflex, if I import some CSV and the string “00.10” as 0.1, then later when you try to do work on it like x == “00.10” You’ll get a type error that x is a decimal and the string literal is a string. So then you know you have to reimport it in the right way. So the type system told you that an assumption was violated. This won’t always happen,…
> E.g. sort by this field will happily do a decimal sort instead of the string 00.10. So that system is not consistent with type checking? How is this not considered a bug?
Types only help if you pick the right ones.
Earlier quoted context omitted.
XML and XML Schema solved this more than 20 years ago. It had to be replaced with JSON by the web developers though, so they could just “eval() it” to get their data.
If all the smart people like you used XML, how come it was so painful to use and it died?
Earlier quoted context omitted.
Nope nope nope. YAML is awful and needs to die. The more you look at it the worse it gets. The basic functionality is elegant (at least until you consider stuff like The Norway Problem), but the advanced parts of YAML are batshit insane.
“The Norway Problem" is a YAML 1.1 problem, of which there are many. What advanced parts of YAML are you talking about that remain problems in YAML 1.2?
> The most tragic aspect of this bug, howevere, is that it is intended behavior according to the YAML 2.0 specification.
Earlier quoted context omitted.
You might like this one as well. Load soap into the dishwasher after emptying rather than after loading . If the soap dispenser is closed, the dishes are dirty.
I want to have two dishwashers. One with the dirty dishes and one with the clean dishes. So you never have to put the dishes away. They go from the clean dishwasher to the table to the dirty one. And then flip them.
[0] https://www.reddit.com/r/self/comments/ayr9c/when_im_rich_im...
Earlier quoted context omitted.
> JSON, which is [...] unambiguous about its types With the one exception that with floatig point values the precision is not specified in the JSON spec and thus is implementation defined[1] which may lead to its own issues and corner cases. It for sure is better than YAML's 'NO' problem, but depending on your needs JSON may have issues as well [1]: https://stackoverflow.com/questions/35709595/why-would-you-u...
Also JSON's complete lack of many commonly used types, and no way to define any new ones.
Earlier quoted context omitted.
My rule is that loading the dishwasher means that one loads all the available dishes, and runs it, even if it's only x% full. We use the (large) sink as an input buffer. If the dishwasher has dishes in it and it's not running, they're clean.
This is exactly our algorithm as all. I can't really imagine flipping it the other way, since leaving dirty dishes in a dishwasher will just let them completely dry out, making it more likely they won't get fully clean when the cycle is eventually run.