I suspect the JMESPath people would argue that if you want to do major transformations to the input, you should write a proper program, and that a CLI query tool should focus on, well, querying.

I'm personally trying to move away from jq and towards jp, because

- there's a standard defining it, not just an implementation, decreasing the odds of being stuck with an unmaintained tool

- there are libraries supporting the syntax for most of the major programming languages

- JMESPath's relative simplicity compared to jq is a good thing, IMO - Turing-completeness is a two-edged sword

- JMESPath is the AWS CLI query language, which is a convenient bonus

> JMESPath is the AWS CLI query language, which is a convenient bonus

And in ansible, too, FWIW, but yes it's my hand-to-hand combat with the language in both of those circumstances that has formed my opinion about it

Regrettably, "kubectl get -o jsonpath" is _almost_ the same, but just different enough to trip me up :-(

Despite using Ansible for several different projects in the past few years, I had no idea there was a corner involving JMESPath. Thanks for the heads-up.

FWIW, my choice to move towards JMESPath is definitely a pragmatic one, not an aesthetic preference. I can't say JMESPath fills me with joy, and the syntax does not come naturally to me - it just solves the problem acceptably well and in a way that has some network effects.

I have plenty of respect for "I've used this tool in the wild and the experience was unpleasant."

From a computer science point of view, what kind of transformations are impossible to express in jmespath but are possible in jq?

I dunno how to speak to your "computer science" part, but pragmatically anything that requires a "backreference", because unlike with JSONPath (and, of course, jq) there are no "root object" references

    $ printf '{"a": {"b":"c", "d":["d0","d1"]}}' | jq -r '[ .a as $a | $a.d[] | {x: ., y: $a.b}]'
    [
      {
        "x": "d0",
        "y": "c"
      },
      {
        "x": "d1",
        "y": "c"
      }
    ]

and I realize this isn't as pure CS-y as you were asking, but this syntax is hell on quoting

    $ printf '["a","b"]' | jp -u 'join(`"\n"`, @)'
    # vs
    $ printf '["a","b"]' | jq -r 'join("\n")'

I see. The need to quote JSON values and the need for @ seem like a high price to pay for removing the . in field accesses.

I also find jq more intuitive but I really dislike that we have three standards each used by a number of tools, e.g. jsonpath, jmespath, and jq.