Bringing the Unix philosophy to the 21st century (2019)

Post by pjmlp » Sun, Aug 22, 2021, 7:42 PM UTC

lfnoise wrote: post #42

eadmund wrote: post #23

Why not go all the way and use a format capable of expressing code and data? I refer, of course, to S-expressions. They also have the benefit of properly handling numbers. Some might look at the absence of maps as a negative, but I think alists are preferable anyway due to their constant ordering.

Yes. I never understood why JSON over s-exprs. The absence of maps is not a negative. S-exprs can represent maps. There are no maps in JSON, really anyway. It is just text. How that data is represented in memory is the output of parsing. You could just as well parse (dict (a 1)(b 2)(c 3)) into a hash table if you wanted. You could also have sets (set 1 2 3) or whatever other data structure.

Post by mcswell » Sun, Aug 22, 2021, 7:48 PM UTC

Post by hackerbrother » Sun, Aug 22, 2021, 8:04 PM UTC

pdimitar wrote: post #29

kbrazil wrote: post #21

Earlier quoted context omitted.

I don’t think the issue is that it’s hard to manually parse. The problem is that it’s hard for someone else to read your ad-hoc parser years later and reason about what you did if they need to modify it. Disclaimer: I am the author of the article and JC.

This is even more true for the ungodly long `jq` incantations that people write. It's like I get it, the old way is ugly and not always easy to decipher but at least it's shorter and your chances of understanding it are better. I've had both -- the classic piped chain of UNIX commands and various JSON-producing tools piped to `jq`. The former were still easier to work with.

  * Collates

  * [

  *    { 

  *        id: 4

  *        dept: 'oncology',

  *        name: 'Joe S.'

  *    }

  *    .

  *    .

  *    .

  *  ]

  *

  *  into

  *

  *  {

  *     4: {  // id

  *        'Joe. S': { // name

  *           dept: oncology

  *        }

  *     .     

  *     .     

  *     .     

  *   }

  */

Post by NegativeLatency » Sun, Aug 22, 2021, 8:19 PM UTC

kbrazil wrote: post #31

pdimitar wrote: post #29

Earlier quoted context omitted.

This is even more true for the ungodly long `jq` incantations that people write. It's like I get it, the old way is ugly and not always easy to decipher but at least it's shorter and your chances of understanding it are better. I've had both -- the classic piped chain of UNIX commands and various JSON-producing tools piped to `jq`. The former were still easier to work with.

Yes, I have seen those too! That’s why I also wrote Jello, which is like jq but uses pure python without the boilerplate. Python is nearly universal now and typically easy to read, though more verbose. Jq is just as much a write-once tool as awk and perl for more complex queries. For simple attribute calls, though, it’s both terse and readable.

Post by cle » Sun, Aug 22, 2021, 8:26 PM UTC

athrowaway3z wrote: post #47

c0l0 wrote: post #19

So I've been writing shell scripts for about two decades, about 75% of that time professionally. Parsing the unstructured, text-based output of utilities is not the problem for anyone who's had maybe a few weeks of training. Most `... | grep ... | cut ... | sed ... | awk ...`-abominations the post laments can be replaced by a single informed call to `awk`, making everything a lot more elegant and concise. Having JSON…

I know enough awk to know it solves my problem, but use it to little to remember how, and the development experience is never very clean. What i would like is an cli awk ide. (Rolls of the tongue right? ) Ideally i could write ... | awk-ide "scripts/thing.awk" | ... If it exists, run it. Otherwise have it open an editor session that runs an awk program as i type it on some buffered data, shows the result, and have so…