4 ms·

Counterpoint: In practically every language that supports comments, these "comments" are now used for language extensions (IDE folding markers, eslint-ignore, F

by moring 4y ago

Counterpoint: In practically every language that supports comments, these "comments" are now used for language extensions (IDE folding markers, eslint-ignore, FPGA synthesis hints, ...) Please don't do that to JSON.

IshKebab 4y ago
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.
- mst 4y ago
  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 implementations would end up acquiring the latter is pretty fair given our track record as a species.
  - IshKebab 4y ago
    > comments that affect the behaviour of the code itself... I agree, but those are extremely rare in my experience. SQL optimiser hints and HDL synthesis hints only affect performance. What examples are there of comments affecting actual behaviour such that tools must parse them for the code to even run? I can't think of any.
    - mst 4y ago
      I do see what you're getting at but in the SQL case an unhinted statement can potentially produce such a terrible plan it invariably times out and triggers a 500 from the service making the query. This sort of thing somewhat blurs the boundaries between affecting performance and affecting behaviour. I'm not claiming that there's an obviously right answer here, only that there can be more questions about whether something is a good idea on net than people always consider. Note: It would not surprise me to find that the actual motivation for leaving comments out of JSON went something like: 1) We can't have line comments because we don't want to be newline sensitive that way 2) If we do /* ... */ style comments people -will- write incompatible parsers for them no matter how carefully we specify them 3) Argh but I wasn't there at the time, so the question will have to remain open.
  - moring 4y ago
    > 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. I think there is no clear distinction between "hints for other tools" and "the behavior of the code itself" unless you implicitly assume a set of tools that define "the behavior of the code itself". You could argue that HDL synthesis hints don't change the behavior of the code, nor do SQL optimizer hints. I understand why you think that IDE folding hints are poor examples, but you would still force unrelated tools to leave those "comments" intact, possibly in cases where there is no clear definition of "intact" (massive transformations to the JSON structure). xkcd "spacebar heating" applies: https://xkcd.com/1172/ https://xkcd.com/1172/
  - alwaysbeconsing 4y ago
    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.
    - mst 4y ago
      When you're designing a specification (I mean, any code, really, but specifications especially), anticipating how users will use it and trying to guide them down the path of -not- misusing it is part of getting the design right. 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.

by moring 4y ago

IshKebab 4y ago

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.

mst 4y ago
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 implementations would end up acquiring the latter is pretty fair given our track record as a species.
- IshKebab 4y ago
  > comments that affect the behaviour of the code itself... I agree, but those are extremely rare in my experience. SQL optimiser hints and HDL synthesis hints only affect performance. What examples are there of comments affecting actual behaviour such that tools must parse them for the code to even run? I can't think of any.
  - mst 4y ago
    I do see what you're getting at but in the SQL case an unhinted statement can potentially produce such a terrible plan it invariably times out and triggers a 500 from the service making the query. This sort of thing somewhat blurs the boundaries between affecting performance and affecting behaviour. I'm not claiming that there's an obviously right answer here, only that there can be more questions about whether something is a good idea on net than people always consider. Note: It would not surprise me to find that the actual motivation for leaving comments out of JSON went something like: 1) We can't have line comments because we don't want to be newline sensitive that way 2) If we do /* ... */ style comments people -will- write incompatible parsers for them no matter how carefully we specify them 3) Argh but I wasn't there at the time, so the question will have to remain open.
- moring 4y ago
  > 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. I think there is no clear distinction between "hints for other tools" and "the behavior of the code itself" unless you implicitly assume a set of tools that define "the behavior of the code itself". You could argue that HDL synthesis hints don't change the behavior of the code, nor do SQL optimizer hints. I understand why you think that IDE folding hints are poor examples, but you would still force unrelated tools to leave those "comments" intact, possibly in cases where there is no clear definition of "intact" (massive transformations to the JSON structure). xkcd "spacebar heating" applies: https://xkcd.com/1172/ https://xkcd.com/1172/
- alwaysbeconsing 4y ago
  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.
  - mst 4y ago
    When you're designing a specification (I mean, any code, really, but specifications especially), anticipating how users will use it and trying to guide them down the path of -not- misusing it is part of getting the design right. 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.