4 ms·

Actually unless one is doing JavaScript, JSON is extremely difficult to parse correctly. I challenge you to write a simple, understandable JSON parser in Bourne

Actually unless one is doing JavaScript, JSON is extremely difficult to parse correctly. I challenge you to write a simple, understandable JSON parser in Bourne shell or in AWK.

repsilat 9y ago
> JSON is extremely difficult to parse correctly ... in Bourne shell or in AWK. Sorry for the misquote, but does it get to the heart of your objection? I'm torn here. On the one hand I want to say "Those are not languages one typically writes parsers in," but that's a really muddled argument: 1. People "parse" things often in bash/awk because they have to -- because bash etc deal in unstructured data. 2. Maybe "reasonable" languages should be trivially parseable so we can do it in Bash (etc). I'm kinda torn. On the one hand bash is unreasonably effective, on the other I want data types to be opaque so people don't even try to parse them... would love to hear arguments though.
- arghwhat 9y ago
  You definitely shouldn't write a parser for anything in bash. If you want to deal with JSON, I'd recommend jq as an easy manipulation tool.
  - Annatar 9y ago
    I wrote Bourne shell and both of you assumed bash. Horrid state of affairs in today’s IT. All hail Linux hegemony! And AWK, if it’s not easily parsable with the language specifically designed for parsing data, something is wrong with that data.
- Annatar 9y ago
  Shell and AWK programs have fewest dependencies, are extremely light on resources’ consumption and are extremely fast. When someone’s program emits JSON because the author assumed that programs which ingest that data will also be JavaScript programs, that’s a really bad assumption. It would force the consumer of that data to replicate the environment. This goes against core UNIX principles, as discussed at length in “The art of UNIX programming” book. It’s a rookie mistake to make.
  - nnq 9y ago
    > It would force the consumer of that data to replicate the environment. It won't, because JSON is a standard. Imperfect like all standards but practically good enough. And "plain text" just means "an undefined syntax that I have to mostly guess". And nobody "programs" in bash or awk anymore. The "standard scripting languages" for all sane devs are Python or Ruby (and some Perl legacy) and parsing JSON in them is trivial. The "UNIX philosophy" was a cancerous bad idea anyway and now it's thankfully being eaten alive by its own children, so time to... rejoice?! EDIT+: Also, if I feel truly lazy/evil (like in "something I'll only in this JS project"), I would use something much much less standard than JSON, like JSON-5 (https://github.com/json5/json5 https://github.com/json5/json5), which will practically truly force all consumers to use JS :P
    - fao_ 9y ago
      The standard for plain text output in the terminal is and has always been TSV.
      - nnq 9y ago
        ...and how does one do nested/tree-like data in TSV? One doesn't, only just ad-hoc invents something akin to sexps or json but unstandardized. Real-world data rarely has a natural fit for "tabl
        fao_ 9y ago
        How many standard UNIX programs do you know that output tree data? And almost always you can find an alternative to non-tree-based representation without having to reinvent sexprs. Look at how ps represents the process tree, for example.
arghwhat 9y ago
Why in the world would I write a parser in bash or awk, regardless of the format? I certainly have better things to do. It doesn't matter how sensible a format is, those tools are simply not appropriate to write a parser in. I have, however, written a JSON parser before at a previous company in C++ (they didn't want to pull in a library). It wasn't particularly hard. And yes, like any other parser, it accepted additional non-JSON constructs. This was simply because it was take additional work to error out on those constructs, which would be a waste of time.
- Annatar 9y ago
  Why in the world would I have to use JavaScript or any object oriented programming language just because the application is poorly thought out and emits JSON? I certainly have better things to do. It doesn't matter how sensible a format is, those tools are simply not appropriate to write a parser in. AWK is a language designed for data parsing and processing. That is what it is designed to do. How did you solve the parsing of arbitrarily nested structures?
  - jhomedall 9y ago
    > How did you solve the parsing of arbitrarily nested structures? Write a recursive descent parser, or use a parser generator. Or, more realistically, use one of the many libraries available for parsing it (pretty much every language has one at this point).
  - mikerybka 9y ago
    Hope one of these helps with your problem: https://github.com/step-/JSON.awk https://github.com/step-/JSON.awk https://github.com/dominictarr/JSON.sh https://github.com/dominictarr/JSON.sh
  - rarepostinlurkr 9y ago
    Json is clearly data. If awk cannot parse it, perhaps it’s a shortcoming of awk? =)
    - 9y ago

Actually unless one is doing JavaScript, JSON is extremely difficult to parse correctly. I challenge you to write a simple, understandable JSON parser in Bourne shell or in AWK.

repsilat 9y ago

> JSON is extremely difficult to parse correctly ... in Bourne shell or in AWK. Sorry for the misquote, but does it get to the heart of your objection? I'm torn here. On the one hand I want to say "Those are not languages one typically writes parsers in," but that's a really muddled argument: 1. People "parse" things often in bash/awk because they have to -- because bash etc deal in unstructured data. 2. Maybe "reasonable" languages should be trivially parseable so we can do it in Bash (etc). I'm kinda torn. On the one hand bash is unreasonably effective, on the other I want data types to be opaque so people don't even try to parse them... would love to hear arguments though.

arghwhat 9y ago
You definitely shouldn't write a parser for anything in bash. If you want to deal with JSON, I'd recommend jq as an easy manipulation tool.
- Annatar 9y ago
  I wrote Bourne shell and both of you assumed bash. Horrid state of affairs in today’s IT. All hail Linux hegemony! And AWK, if it’s not easily parsable with the language specifically designed for parsing data, something is wrong with that data.
Annatar 9y ago
Shell and AWK programs have fewest dependencies, are extremely light on resources’ consumption and are extremely fast. When someone’s program emits JSON because the author assumed that programs which ingest that data will also be JavaScript programs, that’s a really bad assumption. It would force the consumer of that data to replicate the environment. This goes against core UNIX principles, as discussed at length in “The art of UNIX programming” book. It’s a rookie mistake to make.
- nnq 9y ago
  > It would force the consumer of that data to replicate the environment. It won't, because JSON is a standard. Imperfect like all standards but practically good enough. And "plain text" just means "an undefined syntax that I have to mostly guess". And nobody "programs" in bash or awk anymore. The "standard scripting languages" for all sane devs are Python or Ruby (and some Perl legacy) and parsing JSON in them is trivial. The "UNIX philosophy" was a cancerous bad idea anyway and now it's thankfully being eaten alive by its own children, so time to... rejoice?! EDIT+: Also, if I feel truly lazy/evil (like in "something I'll only in this JS project"), I would use something much much less standard than JSON, like JSON-5 (https://github.com/json5/json5 https://github.com/json5/json5), which will practically truly force all consumers to use JS :P
  - fao_ 9y ago
    The standard for plain text output in the terminal is and has always been TSV.
    - nnq 9y ago
      ...and how does one do nested/tree-like data in TSV? One doesn't, only just ad-hoc invents something akin to sexps or json but unstandardized. Real-world data rarely has a natural fit for "tabl
      - fao_ 9y ago
        How many standard UNIX programs do you know that output tree data? And almost always you can find an alternative to non-tree-based representation without having to reinvent sexprs. Look at how ps represents the process tree, for example.

arghwhat 9y ago

Why in the world would I write a parser in bash or awk, regardless of the format? I certainly have better things to do. It doesn't matter how sensible a format is, those tools are simply not appropriate to write a parser in. I have, however, written a JSON parser before at a previous company in C++ (they didn't want to pull in a library). It wasn't particularly hard. And yes, like any other parser, it accepted additional non-JSON constructs. This was simply because it was take additional work to error out on those constructs, which would be a waste of time.

Annatar 9y ago
Why in the world would I have to use JavaScript or any object oriented programming language just because the application is poorly thought out and emits JSON? I certainly have better things to do. It doesn't matter how sensible a format is, those tools are simply not appropriate to write a parser in. AWK is a language designed for data parsing and processing. That is what it is designed to do. How did you solve the parsing of arbitrarily nested structures?
- jhomedall 9y ago
  > How did you solve the parsing of arbitrarily nested structures? Write a recursive descent parser, or use a parser generator. Or, more realistically, use one of the many libraries available for parsing it (pretty much every language has one at this point).
- mikerybka 9y ago
  Hope one of these helps with your problem: https://github.com/step-/JSON.awk https://github.com/step-/JSON.awk https://github.com/dominictarr/JSON.sh https://github.com/dominictarr/JSON.sh
- rarepostinlurkr 9y ago
  Json is clearly data. If awk cannot parse it, perhaps it’s a shortcoming of awk? =)
  - 9y ago