51–60 of 66 posts
Earlier quoted context omitted.
JSON5 exists and allows both comments and trailing commas. It's basically like defining objects in plain JavaScript syntax.
what's the difference between JSON5 and the config language that vs code uses ,JSON + comments (as best I can tell).
For a format designed to be human readable, JSON not supporting comments is a major let down. And not supporting trailing comma.
What’s wrong with using a ‘comment’ key? I’d say not supporting large ints is worse. https://stackoverflow.com/questions/209869/what-is-the-accep...
Earlier quoted context omitted.
What exactly is wrong with that? Comment hints like that are quite common and with a few exceptions (synthesis hints) they are all optional hints that have no effect on the main interpretation of the code. IDE folding markers aren't going to hurt anyone. Chrome doesn't care about lint waivers. Etc.
Things like comments being used to provide optimiser hints in SQL queries are the bane of people writing parsers or anything that depends on them. I think folding/lint/etc. markers are poor examples here, because they're basically annotations for other tools which seems entirely fine. However comments that affect the behaviour of the code itself are really much less fun to deal with. Worrying that JSON implementation…
Earlier quoted context omitted.
Just because you can doesn’t mean you should. If someone told me tags must appear in a specific sequence for their markup to work, I call the implementation flawed. That’s been the downfall of XML - doing way too much for it’s own good.
> Just because you can doesn’t mean you should. This is where you are wrong. If you are making a validator, if the format can do something, the validator should deal with that possibility. If validator is incomplete wrt' validated features, it cannot be used to guarantee the document validity, which is... well, it's most important function. It has nothing to do with your emotional attachments to tags and sequences.
Let's look at the concrete reality we're dealing with: XML usage has declined, JSON (maybe supported by JSON schema) is ubiquitous. I'd be inclined to say the pendulum has swung a little too far in terms of simplicity - but overall, it's very clear why XML failed, and too few dimensions of meaning is definitely none of the reasons.
Well, time will tell. If they get it right, people will use it. If they don’t, it will wither on the vine. Pretty darwinian, but This Is The Way. XML Schema is a fiendishly complex, awkward, and verbose standard, but it is very much in use. Personally, I hate it, but I have used it fairly often. I would like it to succeed, and will use it, if it does; even if it’s ugly. If it doesn’t work, I won’t use it. My experien…
I just realized that sentence doesn't make sense.
I meant that people will build on an API, and make assumptions to "fill in the gaps."
As long as there's nothing in the current API that "codifies" these assumptions, I consider it OK, to add stuff that breaks the assumptions, but I won't go and make changes to stuff I've codified.
An example is some work I was doing, with an Apple UIKit API. I was calling a set of functions in a particular order. Apple released a system update that reset one of the settings, so I needed to move the call that affected that setting, to the end of the chain. They never specified the order (nor did they do so, after that, even though they probably should have), so I had no room to complain.
Earlier quoted context omitted.
It's a terrible & self-interested & small-minded design philosophy making awful trade-offs. It's an actively dangerous way of building, to the exclusion of allowing possibility, and for false gain ("no new major versions but it will totally change maybe & no one else has freedom"). I use strong terms because this breaks so many internet ethos, logos, & pathos. Picking the narrowest path should be warded & hazarded ag…
They've explicitly said they're looking at finding a way to still be able to express custom properties. So done right the end result will be basically no different from the use of X- headers in HTTP and friends. What they're talking about doing could easily be -implemented- badly, but your reaction to the idea of doing it at all seems rather more exothermic than indicated by the situation.
I wish they'd actually elaborated like a dozen cases in the wild, that show there's a real problem here & why they'd do this. I agree, Im having a strong reaction to this. It really seems like any workarounds that happens here are going to be ugly, going to be gross, and it feels like such a false need, such a non-issue to make new problems over.
Earlier quoted context omitted.
What’s wrong with using a ‘comment’ key? I’d say not supporting large ints is worse. https://stackoverflow.com/questions/209869/what-is-the-accep...
JSON supports numbers of arbitrary and just fine. It's just many reader/writers of JSON does not, and those are so ubiquitous that it's often not practical to use.
For a format designed to be human readable, JSON not supporting comments is a major let down. And not supporting trailing comma.
Comments were an explicit anti-feature. Douglas Crockford in 2012:
> I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability.
* https://web.archive.org/web/20120507104813/https://plus.goog...
* https://news.ycombinator.com/item?id=3912149 (discussion at the time)
And JSON primary purpose was to be a data interchange format; the fact that is human-readable text is a nice bonus.
For a format designed to be human readable, JSON not supporting comments is a major let down. And not supporting trailing comma.
> For a format designed to be human readable, JSON not supporting comments is a major let down. Comments were an explicit anti-feature. Douglas Crockford in 2012: > I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. * https://web.archive.org/web/20120507104813/https://plus.goog... * https://news.ycombinator.com/item?id=…
As things are now trailing commas and comments would make JSON a better format, whether they were a good compromise at the time is not really the point.
Earlier quoted context omitted.
Things like comments being used to provide optimiser hints in SQL queries are the bane of people writing parsers or anything that depends on them. I think folding/lint/etc. markers are poor examples here, because they're basically annotations for other tools which seems entirely fine. However comments that affect the behaviour of the code itself are really much less fun to deal with. Worrying that JSON implementation…
This is a clear case of blaming the tool for its misuse. A hammer helps you build things, but you can also break your thumb with it. Yet many people keep hammers at home.
Sometimes deliberately leaving a potential feature out makes for a better end result. Sometimes it doesn't. But either way it's better to make the choice deliberately.