Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON with Commas and Comments

nigeltao.github.io

Post reply on HN
Print view View original

241–250 of 251 posts

Re: JSON with Commas and Comments

#241

Post by 0xbadcafebee »

eknkc wrote: post #115
crubier wrote: post #98

Earlier quoted context omitted.

No it doesn’t. I know the HN-crowd feeling about this, but no, YML doesn’t suck as a human configuration language. TOML or XML properly suck. YML is actually a superset of JSON with comments and less brackets if you want. It’s widespread and supported and fulfill the need of OP, so no need to add yet another format. Or use JSON5. But please not yet another standard

How is TOML bad as a config language? I would not transmit data in TOML but is makes a lot of sense as a config language.

Neither YAML or TOML are config languages, they are data formats.

A data format is a way of structuring or serializing data. The whole point of the format is to read and write arbitrary data. It may have a simple schema, or features designed for the loading and unloading of data. But all those features are designed to assist the machine, not the human operator.

A config format is designed specifically to assist a human operator, not a program. Humans should not have to consider data types when they write a config, or when they feed it to a program. Humans should have useful features to make their lives easier, like variable substitution, pattern matching, inheritance, namespaces, simple newline-separated whitespace-indifferent commands, etc.

Programming languages are just elaborate configuration formats. And that's where the problem begins: how much "power" do you give the configuration format before it gets unruly? It's difficult to find a balance. People end up using simple data formats because the parsers are widely available and they can "fake" advanced features by making programs interpret a specifically-crafted data structure as a configuration instruction. But there's very little thought put into how this can be extended to make more complex configurations easier.

Most web servers and other complex software [usually run by sysadmins] have a real configuration format or configuration language. Poorly-written software pretends a data format is a programming language, or even worse, forces you to use an actual programming language. These designers fundamentally don't understand or don't care about the user.

Re: JSON with Commas and Comments

#242

Post by colejohnson66 »

banana_giraffe wrote: post #68
skissane wrote: post #54

Earlier quoted context omitted.

> Current parsers cannot start returning BigInts instead of numbers without that being a breaking change. Current parsers aren't uniform here. Since the JSON spec is silent on what post-parsing format is used for numbers, each parser is free to do whatever makes sense in the context of the host language. I reckon you'll find some JSON parsers use bigints already, especially in languages with first-class bigint suppor…

> I reckon you'll find some JSON parsers already use bigints already Yep. Python is one such language. I've seen this catch people by surprise when they discover their serial number (which granted, should have been a string in the first place) doesn't survive a trip from Python to JSON to Javascript, among other languages.

It doesn’t help that it’s called a serial number, and is sequential (hence, serial, but some manufacturers don’t care). num++ is easier than implementing increment_number_string that works on ASCII digits.

Re: JSON with Commas and Comments

#243

Post by banana_giraffe »

colejohnson66 wrote: post #242
banana_giraffe wrote: post #68

Earlier quoted context omitted.

> I reckon you'll find some JSON parsers already use bigints already Yep. Python is one such language. I've seen this catch people by surprise when they discover their serial number (which granted, should have been a string in the first place) doesn't survive a trip from Python to JSON to Javascript, among other languages.

It doesn’t help that it’s called a serial number , and is sequential (hence, serial , but some manufacturers don’t care). num++ is easier than implementing increment_number_string that works on ASCII digits.

Yep, "serial number" was basically the argument for using a number type in the first place, and here they were sequential. Even then, ignoring the JSON peculiarities, it would have been ok up till someone had the brilliant idea to have x digit serial numbers for one product line, and y digit for another. With only zero padding to tell them apart. This person, not a programmer, could not fathom why it caused the "tech heads to go crazy".

Sometimes I debate collecting stories like this.

Re: JSON with Commas and Comments

#244

Post by jugg1es »

onion2k wrote: post #95
jugg1es wrote: post #66

Why can't these no-brainer features just be added to browsers without a new standard!!

That would make fetching JSON data significantly more complicated. You'd need to write your fetch call to detect if the browser supports comments and commas in JSON, and then make the request to the server to ask for whichever variant the user's browser supports, presumably with a different Accept header. Users who haven't updated to a new version of the browser would still ask for the old JSON format, and users who…

yea but it would be cool if you could include comments, wouldn't it?

Re: JSON with Commas and Comments

#245

Post by coldtea »

eesmith wrote: post #174
coldtea wrote: post #150

Earlier quoted context omitted.

From the very page you link to: Nonetheless, according to Stephen J. Lukasik, who as Deputy Director and Director of DARPA (1967–1974) was "the person who signed most of the checks for Arpanet's development: "The goal was to exploit new computer technologies to meet the needs of military command and control against nuclear threats, achieve survivable control of US nuclear forces, and improve military tactical and man…

That quote was immediately after a quote from Charles Herzfeld, ARPA Director: > "The ARPANET was not started to create a Command and Control System that would survive a nuclear attack, as many now claim. To build such a system was, clearly, a major military need, but it was not ARPA's mission to do this; in fact, we would have been severely criticized had we tried." History's complicated, isn't it? So, we look at ot…

>History's complicated, isn't it?

Yes, but in the end it's he who pays the bills who decides. Without them it's lights out.

Re: JSON with Commas and Comments

#246

Post by coldtea »

sagonar wrote: post #168
coldtea wrote: post #56

Earlier quoted context omitted.

> Doug not only explains the reason Just because he had a reason to give doesn't mean it wasn't a bad reason. His stated reasoning failed with hindsight. (a) People already do what he thought was preventing (custom parser behavior) by removing comments, (so his choice failed to prevent what he wanted to prevent) (b) people have already created dozens of JSON parser variants that accept comments, because we really wan…

I disagree, he has DONE a common data format that works. If you do mod it, for example add comment to the data sent, 99.9% of the people agree, it is no longer JSON.

Which is neither here, nor there.

People still do it, and they still call it JSON. Heck, many JSON parsers, who otherwise work fine with regular JSON still accept it.

Even parsers using a different name like JSONC still allude to the JSON connection - and still are an argument that people found a lack in JSON.

Etymology/originology never produced much benefit over pragmatic non-prescriptive examination of how people use things. If anything, it helped confused the situation with pedantic objections.

Re: JSON with Commas and Comments

#247

Post by eesmith »

coldtea wrote: post #245
eesmith wrote: post #174

Earlier quoted context omitted.

That quote was immediately after a quote from Charles Herzfeld, ARPA Director: > "The ARPANET was not started to create a Command and Control System that would survive a nuclear attack, as many now claim. To build such a system was, clearly, a major military need, but it was not ARPA's mission to do this; in fact, we would have been severely criticized had we tried." History's complicated, isn't it? So, we look at ot…

> History's complicated, isn't it? Yes, but in the end it's he who pays the bills who decides. Without them it's lights out.

Herzfeld paid the initial bills. Herzfeld said "ARPANET was not started to create a Command and Control System that would survive a nuclear attack".

Lukasik came in later, and had no signing authority or supervisory position on the initial ARPANET work.

Following your guideline, the ARPANET therefore wasn't "created to have a war-proof network for army use"; that was a design goal which came later, after the collaboration goal.

Re: JSON with Commas and Comments

#248

Post by rswail »

coldtea wrote: post #56
aaron-santos wrote: post #2

> Yes, Doug Crockford deliberately removed comments from JSON but people keep putting them back in. If we’re going to have comment-enriched JSON (e.g. for human-editable configuration files), we might as well have a standard one. The text "deliberately removed comments from JSON" links to https://web.archive.org/web/20150105080225if_/https://plus.g... where Doug not only explains the reason, but also a solution which…

> Doug not only explains the reason Just because he had a reason to give doesn't mean it wasn't a bad reason. His stated reasoning failed with hindsight. (a) People already do what he thought was preventing (custom parser behavior) by removing comments, (so his choice failed to prevent what he wanted to prevent) (b) people have already created dozens of JSON parser variants that accept comments, because we really wan…

> It wasn't his place to define whether we get comments or not based on some potential parser abuse. But he did it, and now we're stuck with that decision...

He was writing the specification, of course it was his place to do so. Who else would be in the right "place" to write his own specification that no one was enforced to use.

Re: JSON with Commas and Comments

#249

Post by nooorofe »

BugsJustFindMe wrote: post #134
nooorofe wrote: post #128

Earlier quoted context omitted.

JSON schema exist exactly for that reason, hacks like adding type is just nonsense. If somebody need comments, types it - XML has all that. Also how hard is to write {"type": "datetime", "value": "2021-02-23 12:46:37.07"}?

> JSON schema exist exactly for that reason, hacks like adding type is just nonsense Creating schemas for declaring types is literally a hack for adding type! I think its very bizarre to say "You dont need to do X because you can just do X." > Also how hard is to write {"type": "datetime", "value": "2021-02-23 12:46:37.07"} "datetime" isn't a universal format specification. 2021-01-10 could be October 1 or January 10…

> Creating schemas for declaring types is literally a hack for adding type!

It is a "communication protocol" - base of any messaging system. Message has header with protocol name and version: HTTP, TCP, DB connection, SOAP, any message queue - everything working that way.

> "datetime" isn't a universal format specification. than use another (see the comment above)

self-contained message is anti-pattern

Re: JSON with Commas and Comments

#250

Post by kevingadd »

wruza wrote: post #180
kevingadd wrote: post #33

Earlier quoted context omitted.

JavaScript wouldn't be able to consume those resulting objects, so it would be pretty diminished as an alternative to JSON. Object keys are all strings.

Not that I find this idea useful for otherwise limited DTO format, which JSON is, but JS has Map, which may be used for such maps.

Sadly because arrays are not immutable you can't meaningfully use them as Map keys. You'd need a tuple type, which does not currently exist.
Post reply on HN