[fivea]

> For example how would you take key k1 from a list of dicts [{k1: v1, k2: v2}, {k1: v3}]?

Do you mean something like:

    .[].k1

Give it a try.

https://jqplay.org/

jq does have a learning curve, but just like any query language, including SQL, first you need to learn the basics of the query language in order to get things to work.

In this case:

* you know that .[] iterates over objects, so you use it to unpack the root array,

* you know you get a stream of objects, thus from those you use the .k1 filter to get the values of each k1 key.

Here's jq's manual on basic filters: https://stedolan.github.io/jq/manual/#Basicfilters

After you get jq to filter out what you want, you can work on getting it to output results in whatever format you wish.

[sirsuki]

Well for comparison, I did that learning curve process with SQL and I was able to understand it. But I did the same learning curve process with JQ and I still don’t understand it.

[Zababa]

> jq does have a learning curve, but just like any query language, including SQL, first you need to learn the basics of the query language in order to get things to work.

SQL is based on solid mathematical theory, relational algebra. I personally learned that (and tuple relational calculus) in college before learning SQL, which made it easier. It helps making it coherant. Is there something like this for jq? Often when people invent languages that are not based on solid theory, they tend to lack coherence. This can make learning them difficult if you're someone that relies on your mental model of how things "should" work, like I am.

[fivea]

> Is there something like this for jq?

It's a filter. You can name-drop math stuff and even mention monads and the like, but it's just predicates, maps, a reductions.

Also, I'm not aware of a single person who ever looked at relational algebra beyond the introductory lessons of a relational databases 101 course, and even then that stuff was mostly in the way.

[Zababa]

Your are the one name-dropping three mathematical concepts though? I'm not sure I understand your reasoning here. I'm talking about the basis for jq in general, not just your example. And if your message is representative of how the people that created jq think, I guess the answer is no and jq falls into the "no solid theory behind it" category.

I don't think my message was implying that jq is a worse (or better) tool for it. I was just explaining that for some people, tools with a theory behind are easier to learn and understand than tools without.