11 ms·
JSON has become today's machine-readable output format on Unix
- Ygg2 2y agoJSON is a human readable format. Machine readable means only a specialized program can be used to make human understand it.
- AndrewDucker 2y agoMachine readable just means a machine can read it. Whether humans can read it as well is irrelevant to the definition. (And there are pretty much no formats that a human hasn't learned to read, up to and including binary)
- Ygg2 2y agoSo every text is machine-readable? Because even English can now be readable by a machine via LLM. Then why use machine-readable? Just say text.
- AndrewDucker 2y agoIt generally means something with a well specified format which can be processed by a parser.
- Ygg2 2y agoTechnically, LLM can be a parser, if you tell it to output its findings in another data format, as: A parser is a software component that takes input data (typically text) and builds a data structure
- raverbashing 2y agoThat is a very good way of shooting yourself in the foot Now every API call is a "call to an LLM"? How much will that cost? Oh and how are you calling the LLM API in the first place?
- Ygg2 2y agoKeep in mind, I consider what's machine-readable to mean, what's only readable by a machine. I.e. a magnetic tape is machine-readable, while JSON is human-readable.
- oneeyedpigeon 2y agoThat's a minority definition. Few of the rest of us would say "JSON isn't machine-readable".
- javawizard 2y ago> I consider what's machine-readable to mean [...] I hate to break it to you but the world has a very different and well agreed-upon definition of what "machine readable" means. You're going to get nowhere if you continue to argue that your definition is the correct one. That ship sailed long ago.
- Ygg2 2y agoOk. But what is machine-readable, then? Is a picture of my passport machine-readable? Is a PDF machine-readable? How do you classify it? And what happens when ten years in the future once algorithms become more optimized? If an AI can read Shakespeare, and parse its paragraph for verbing a noun, is all human written stuff then machine-readable?
- iinnPP 2y agoThe picture of your passport is machine-readable to any machine that can read it. That is not all machines. The significance of JSON, and the submission itself, seems to be in the ubiquity of JSON making it more machine-readable than other formats. You're being too strict with language and definitions.
- DonHopkins 2y agoParsers don't hallucinate.
- cladopa 2y agoAt 2 tokens per second? Needing a network connection or sending your data(including confidential's) to the cloud? needing very expensive GPUs? With hallucinations and tremendous energy expense. I parse things usually at a rate of 2-20 million tokens per second, on a local computer. Never hallucinates and it is always perfect. Don't get me wrong. I use LLMs a lot, but they are good at what they are good at.
- discreteevent 2y agoIt's both. "Readable" means "possible to read it". On the human readability side, though, the obligation to enquote string keys irks me a lot.
- Ygg2 2y agoHaving had to have displeasure to program parsers for YAML, the ability to start your word with a valid token symbol in an unquoted string (for example :this or ,this or &:hate_you) is so limiting and prevents many optimizations.
- Philpax 2y ago"Trivially parseable by machines" is not mutually exclusive with "Trivially parseable by humans". JSON is both.
- rusk 2y agoJSON is machine readable first; and human readable for convenience. Its primary purpose is for machine to machine communication, but it does allow human intervention. People have used that as a signal to start using it for configuration files but that is an anti pattern in my opinion. If you want something like JSON that is designed for humans take a look at YAML
- orphea 2y agoI will pick JSON over YAML every single time. Not because JSON is so good, it's just YAML is so much more cancerous.
- yas_hmaheshwari 2y agoCan you explain why is Yaml cancerous (Genuine question) I have always preferred (even without thinking) to use configuration files as Yaml and kept Json for interprocess communication
- orphea 2y agoMany people explained it better than I ever could, so let me defer to them. TL;DR: YAML is an overcomplicated spec with too many footguns. - https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr... - https://www.arp242.net/yaml-config.html https://www.arp242.net/yaml-config.html - https://noyaml.com/ https://noyaml.com/ (couldn't not mention this famous piece)
- rusk 2y ago“I don’t want to learn how to use it properly therefore it’s like [bad thing I clearly have no experience of]” JSON is not fit for purpose as a configuration format. Use YAML or don’t, use properties if you like. JSON is first and foremost for m2m- it’s even in the name “Object Notation”
- deleted 2y ago[deleted]
- cladopa 2y agoNo. It means that the parsing code is trivial to make instead of using some kind of LALR, SLR, Earley monstrosities with hundreds of megabytes of grammar tables in memory, just to understand the output of a program like "ls" or "find" or "grep". JSON is ALSO easy for machines to read. I know because I made several JSON parsers myself. I have also made parsers for computer languages(with things like PEG) and natural languages and there is a world of difference.
- nayuki 2y agoOddly enough, BitTorrent's bencode format is a significant subset of JSON but is much easier to parse as a binary format. Bencode only supports integers, byte strings, lists, and dictionaries. I wrote a more detailed comparison on: https://www.nayuki.io/page/bittorrent-bencode-format-tools https://www.nayuki.io/page/bittorrent-bencode-format-tools
- skerit 2y agoOh, I didn't know about Bencode. It looks interesting. Thank you for sharing!
- sriram_malhar 2y agoI really like bencode. The only thing I miss is floats.
- kali_00 2y ago[dead]
- victorstanciu 2y agoYou can use two integers, one that represents the entire number including decimals, and one that represents the precision, to know how many decimals are there. For example, you'd represent "123.45" as 12345 and 2. That's often how monetary amounts are stored in databases, to avoid a lot of common floating-point arithmetic pitfalls.
- thrance 2y agoBut that's just floats with extra steps? Floats have two parts in their binary representation: mantissa and exponent (and sign), which correspond exactly to your "entire number" and "precision", only in base 2 instead of 10.
- wavemode 2y agothe difference being that with integers you never end up with rounding errors when doing addition subtraction or multiplication (only division)
- skerit 2y agoI like that more and more CLI tools are implementing a json-output mode. Like `ip -j a`
- IcyWindows 2y agoThis is part of the reason I love working with powershell. I like having things already in a json-like format by default.
- rffn 2y agoThe article suggests that Gnu Awk might soon improve its understanding of JSON. Can somebody please shed some light at this? Will gawk get JSON support. Or is is already there and I just need to get a recent version?
- shakna 2y agoGNU awk already does. [0] Sorta. The "non-essential" stuff, like xml, json, redis gets put into gawkextlib. Usually packaged for your platform. [0] https://www.gnu.org/software/gawk/manual/html_node/gawkextlib.html https://www.gnu.org/software/gawk/manual/html_node/gawkextli...
- rffn 2y agoThanks. I wasn't aware about this library.
- braggerxyz 2y agoI agree, and I feel like the reason to this is the mere existence of 'jq'. Without 'jq' working with json in a Unix shell would be a lot more uncomfortable, but not impossible.
- stemlord 2y agoThough jq syntax leaves a lot to be desired
- jauntywundrkind 2y agoThe syntax felt ok to me; selectors felt natural and pipes felt very conventionally shell-like. Ut man, the vocabulary, the variety of different operators you'll need to use in this circumstance or that–brutal. There's some decent cookbooks/recipes but they're still 1/5th as big as they could be.
- s_dev 2y agoWhat do you think the trade off here with syntax is and what jq was designed for? A bash script might need to execute it and you want something without lots of funny characters or whitespace as it's going straight in to the terminal. That necessary terseness makes it the opposite of readable.
- pyuser583 2y agoAlso Python. Python handles json really well, at least compared to say bash. I want to say server side JavaScript plays a role in this too, but I’m not a JS developer.
- JasonFive 2y agoI prefer JSON5 myself but not well support unfortunately https://json5.org/ https://json5.org/
- silon42 2y agoNot sure why they had to add additional white space characters... also, single line comment seems problematic in this respect... machine readable JSON is often one line.
- sim7c00 2y agoabout time to move from undefined to atleast something... programs should have clear interfaces for in and output. im sure there were sound reasons, but slapping wads of unstructured text to and fro in 2025 sounds almost primordial -_-
- teddyh 2y agoSee also: <https://varlink.org/ https://varlink.org/>
- enriquto 2y agosort of agree... but only because you can gron it to remove the madness and then grep/cut/sed/awk the output like a human being. JSON is just a modern flavor of XML, and in a few years we'll likely mock both of them as if they were the same silly thing. They are functionally equivalent: not human-writable, cumbersome, crufty, with unclear semantics, with unclear semantic usage, and all around ugly.
- maccard 2y agoI unfortunately write a bit of both xml and json as part of my day to day. JSON is significantly easier to read and write as a human. So many xml files use a combination of the file structure, the nodes and the attributes to encode their data - meaning to parse it you need to know the specifics of how it was written. JSON is much simpler and 95% of the time can be thought of as map<string, JsonObject> and it just works. Yml goes too far in the brevity side - I find the 2 space indent, use of “-“ as a list delimiter, white space sensitivity and confusing behaviour with quoted vs unquoted strings incredibly hard to work with.
- enriquto 2y ago> 95% of the time can be thought of as map<string, JsonObject> But for that case you don't need json. A dockerfile-like text file with lines of the form STRING other stuff is trivial to parse in any language and without requiring any library. And it's actually human-editable. Using json for such trivial stuff is like using a linear algebra library to compute b/a (the quotient of two numbers) by calling linalg.solve([[a]],[b]). Of course it will work. Of course it is more general. But it feels silly.
- maccard 2y ago> But for that case you don't need json. A dockerfile-like text file with lines of the form I don't think that would solve any of your listed problems with json. The key thing is that it's represented by: struct JsonObject { Dictionary<string, JsonObject> entries; } and that's the entire data structure. Your dockerfile example handles the absolute most basic of cases, e.g. { "foo": ["bar", "baz"] } would be FOO ["bar", "baz"] But when you nest objects .e.g. { "foo": { "bar": "baz" } } The dockerfile-style example is FOO { BAR baz } or FOO BAR baz # Now we're whitespace sensitive Or maybe we're: Foo # What do we put here? Foo.bar baz > Using json for such trivial stuff is like using a linear algebra library I disagree. I think using xml for that is like using a linear algebra library, as you can have: <Foo>Bar</Foo> <Foo value="Bar"></Foo> <Foo><Bar>Baz</Bar></Foo> <Foo bar="Baz"></Foo> <Foo><Bar value="Baz"></Bar></Foo> and end up with the same thing. But with json, it's just: { "Foo": "Bar"} and { "Foo": { "Bar: "Baz" } } E: Formatting
- kstenerud 2y agoJSON solves enough problems and is a simple enough format to become ubiquitous. My only beef is with the serialization/deserialization costs. That's why I've made a 1:1 binary format https://github.com/kstenerud/bonjson https://github.com/kstenerud/bonjson
- dfawcus 2y agoOh dear - bitten by his "scraping" protection. As his site no longer allows me to view with Firefox-115 ESR, it being deemed as "too old" despite still being a supported release.
- beej71 2y agoI hit reload on FF and it worked...? I don't know why I got flagged once and not subsequent times.
- thatcks 2y agoThere was a little glitch in the scraping protection where an errant regular expression briefly blocked all Firefox versions. Which is especially bad because I (the blog author) exclusively use Firefox, so I was blocking myself. The management apologizes for the problem (and generally allows much older Firefox versions than Chrome versions, as people seem to still use them on various platforms).
- dfawcus 2y agoHmm - it still blocks me when my browser reports its native string of: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0 however if I override it to the following, the site lets be through: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
- thatcks 2y agoThis should be fixed for you now. To my surprise, some legitimate versions of Firefox report 'rv:109.0' with a Firefox/<ver> version that is not 109 (along with all of the crawlers that have latched on to 'rv:109.0' as something they put in their User-Agent strings along with random old Firefox versions).
- philkrylov 2y agoHi, I am still blocked with "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:109.0) Gecko/20100101 Firefox/115.0"
- tonijn 2y agoNo love for XML…
- DanielHB 2y agoFYI if anyone is looking into data formats for high performance stuff I recommend looking into CBOR: https://en.wikipedia.org/wiki/CBOR https://en.wikipedia.org/wiki/CBOR It is very popular in embedded systems and IoT. It is basically binary JSON, but supports numbers as key, variable-sized ints/floats, utf-8 strings. CBOR binary blobs can be converted to JSON keeping similar semantics (number keys will be converted to strings) and parsed with `jq` for human-readability/debugging. It can also be read in "pull parsing" mode so you don't need to keep the whole message in memory. This is the opposite of "DOM parsing" although I don't know if these terms are applicable in non XML contexts. When you only have 256KB of RAM this is quite important.
- damnitbuilds 2y agoJson needs comments. The reasoning behind forbidding them is spurious.