4 ms·
The n, no, off thing is just sad. It's a 100% avoidable issue. But whoever put that into spec was just so clever that they overflew and became stupid.
by raincole 1y ago
The n, no, off thing is just sad. It's a 100% avoidable issue. But whoever put that into spec was just so clever that they overflew and became stupid.
- __alexs 1y agoThis is basically every problem in YAML. Someone couldn't resist adding more stuff and either didn't realise or didn't care about the ambiguities it created.
- kevincox 1y agoIt basically feels like overfitting. They saw some use case so they added it. But they didn't think about how this would generalize and now this nice use case is disproportionately supported at the cost of surprising everyone who doesn't need time-of-day fields in their file.
- baobrien 1y agoToo clever by half
- phpnode 1y agoWhoever thought supporting sexagesimal numbers was a good idea needs to spend some extended time away from their computer to reflect on what they’ve done
- chrisandchris 1y agoWe wanted a file format that's easy to read and less verbose than xml and all we got was something that is so full of pitfalls that it would be easier just not to use it.
- microtherion 1y agoPresumably that was to support time values.
- Ajedi32 1y agoThat makes sense, but I think the vast majority of tools that need time values would actually expect users to just input a string and parse that themselves. IMO anything other than the basic types supported by JSON (number, true, false, null) ought to be be parsed as a string. Or if you really insist, some kind of special syntax to make it clear it's not a string would probably be acceptable.
- imglorp 1y agoDoes anyone do it that way?
- VMG 1y agoWhat do you mean by "support"?
- microtherion 1y agofastest_mile: 2:54 Not saying it's a good idea, mind you, but at least it's an ethos.