Hacker News Reader

Comment by raincole | Hacker News Reader

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.

View on HN

Whoever 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

Presumably that was to support time values.

That 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.

What do you mean by "support"?

   fastest_mile: 2:54

Not saying it's a good idea, mind you, but at least it's an ethos.

Does anyone do it that way?

We 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.

This 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.

It 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.

Too clever by half

Reply on news.ycombinator.com