4 ms·
These types of languages are a bad idea, just as XPath was. They are complex enough to be a maintenance/bug risk AND don't bring any additional benefit to just
by pydry 3y ago
These types of languages are a bad idea, just as XPath was. They are complex enough to be a maintenance/bug risk AND don't bring any additional benefit to just writing code in your normal programming language to do the same thing.
You can take my list comprehensions from my cold, dead hands.
There isn't a use case I've seen where these types of mini languages fit well. Ostensibly, you could give it to a user to write to query JSON in a domain-agnostic way in an app but I think it would just confuse most users as well as not being powerful enough for half of their use cases.
Sometimes it's better just to write code.
- Adiqq 3y ago> don't bring any additional benefit to just writing code in your normal programming language to do the same thing. In some cases advantage is that you don't create new code and you just use some relatively standard tool. You just fetch some public package that handles various edge cases and you just prepare script that describes what you want to do with some program. This is useful, if you work in containerized environment and configuration exists as json or yaml. Often I just use jq or yq, instead of reinventing wheel to just read or write some values.
- Drakim 3y agoI agree, it gives the same vibe as wanting to somehow bring back the simplicity of excel formulas rather than having to write normal code, to revive that dream of convenient one-liners. But there is a reason excel has a ceiling of maintainability that always turns it into a spaghetti mess once it's big enough.
- Silphendio 3y agoJSON Path: $.store.book[?@.price < 10].title Python: [x['title'] for x in data['store']['book'] if x['price'] < 10] Javascript: data.store.book.filter(x=>x.price < 10).map(x=>x.title)
- fmbb 3y agoThat javascript version is obviously objectively the best alternative.
- OskarS 3y agoYeah, it's not bad. Guido famously preferred the list comprehension style over the functional style, but when you have nested data types and the "monadic style" (ish) functions, it does really make sense. You could imagine it in Python (lets pretend lists have map and filter): data['store']['book'].filter(lambda x: x.price < 10).map(lambda x: x.title) Yeah, not nearly as good. The syntax sugar of a.b instead of a['b'] and arrow functions instead of lambda really does make a pretty big difference.
- vbezhenar 3y agoBest syntax for closures I've ever seen in Scala. Would look something like data.store.book.filter(_.price < 10).map(_.title) Every language should just adapt it.
- OskarS 3y agoRaku does a version of that as well, it's sick.
- librasteve 3y agoin Raku, this data.store.book.filter(_.price < 10).map(_.title) would be written as data.store.book.grep(*.price < 10).map(*.title)
- williamcotton 3y agoF# just added this syntax: let possibleNow = people |> List.distinctBy _.Name |> List.groupBy _.Age |> List.map snd |> List.map _.Head.Name |> List.sortBy _.ToString()
- 3y ago
- sbarre 3y agoAll these examples assume an understanding ahead of time of your data structure. Can you write examples in Python and Javascript where you'd extract those titles from an arbitrary JSON structure? ;-)
- Silphendio 3y agoYou mean searching for keys? $..book[?@.price<10].title Yeah, I don't think javascript has that function in the standard library. Writing one is not super complicated, but having to put that into every file (or importing it) is not ideal. find_key = (data, key) => { if(data instanceof Array){ return data.map(x=>find_key(x, key)).flat() } if(data instanceof Object){ let res = Object.keys(data).map(x=>find_key(data[x], key)) if(data.hasOwnProperty(key)){ res.push(data[key]) } return res.flat() } return [] } find_key(data, "book").filter(x=>x.price < 10).map(x=>x.title)
- aeonik 3y agoI tried this once, and I accidentally invented a poorly implemented and incomplete version of Lisp.
- g4zj 3y ago> All these examples assume an understanding ahead of time of your data structure. How would one use JSONPath to extract all book titles from an arbitrary JSON structure? Also, when might that use case apply? I can't think of when I've ever needed to do something like this, but I'm interested in learning. :)
- sbarre 3y agoJSONPath has excellent documentation, you can absolutely answer that question for yourself very easily.
- pydry 3y agoSo do you regularly hard code the number 10 in your code? I think you missed my point. In realistic code you'd be using string interpolation to put the number 10 into this query language, and worrying about injection vulnerabilities while you did it. Or even calling another arbitrary function to do the filtering. Which this query language can't handle at all.
- ruuda 3y agoRCL (https://rcl-lang.org https://rcl-lang.org): [ for book in input.store.book: if book.price < 10: book.title ]
- wmil 3y agoThose become a bit messier if store or book can be null.
- arter 3y agoYep. You wouldnt use json path as replacement to any language. It might be marginally useful in configurations or passing queries between different services. But the complex syntax limits it in both cases, because you cannot easily automatically modify the query. In the case of configs it would be great to analyze hundreds of configs on different systems and change them automaticaly, same with queries exchanged between services which might even get stored in a database. I do not understand why domain languages aren't designed with limited syntax in mind. In the style of lisp for instance. Because actually being able to programatically work with the language is a massive advantage that imo far outweights your own frustration with typing a paranthesis or two extra.
- exceptione 3y agoI think in the Javascript version you have to check for null as well.
- int_19h 3y agoWith https://www.jsoniq.org https://www.jsoniq.org, you can do either: store.book[][$$.price lt 10].title or the more verbose: for $book in store.book[] where $book.price lt 10 return $book.title
- stoperaticless 3y agoAre you also against file paths?
- psnehanshu 3y agoHow's that related?
- HarHarVeryFunny 3y agoIt's pretty much the exact same thing - let's you specify a file to access with a string (pathname) such as "/foo/bar/cat" rather than having to go step by step first open/reading directory "foo", then open/reading directory "bar", then finally accessing file "cat". With XPath and JSONPath you're just dealing with DOM nodes and children rather than directories and children.
- exyi 3y agoExcept that XPath and JSONPath are overpowered. I'd welcome a simple standard path syntax for JSON, for instance, I'd want to use for reporting schema errors in JSON document ($.users[10].name must be a string). I can use JSONPath, sure, but even this subset is annoying to parse - compared to a filepath which you can parse with `path.split('/')`.
- HarHarVeryFunny 3y agoAgreed - for a lot of use cases all you need is a pathname-like way to refer to elements in the DOM, not a search/filtering mechanism.
- hgyjnbdet 3y agoYou might like gron then. https://github.com/tomnomnom/gron https://github.com/tomnomnom/gron For 90% on my needs this is all I need.
- husam212 3y ago> don't bring any additional benefit to just writing code in your normal programming language What if the query is implemented in a lower level and more efficient programming language, or probably a completely separate DB engine.
- pydry 3y agoWhat if the filtering criteria required a function call? The benefits of having a well designed Turing complete language available for the filtering criteria far outweigh the disadvantages.
- chuckadams 3y agoThe disadvantages in being tied to the execution model of said Turing Complete language are also significant when compared to one that can do optimizations like stream fusion without having to work such optimizations into the language as a whole. But there's no technical reason we can't have both.
- sesm 3y agoOne advantage is slightly less typing, which might be useful in CLI tools and UI filters. Also, people don't want to bring a full JS interpreter in those kinds of interfaces for various reasons.
- pydry 3y agoFewer characters to write is an advantage but it's an advantage that is more than offset by the disadvantages of a familiar, more powerful language. The philosophy of language terseness uber alles ought to have died with Perl.
- samatman 3y agoOne of the advantages of this sort of DSL is that they're easy to share between languages. One needs one implementation of JSON path per programming language, and then it's easy to, for example, iterate on the query in the REPL of a dynamic language, then copy it to a fast compiled language. Or share a query between the browser and the server. That sort of thing. Regex has similar advantages, if one sticks to the subset of regex which is commonly understood between languages: so less so, for that very reason. Another plus is the principle of least power. A JSON Path will halt, and it won't make syscalls. There are circumstances where that's useful.
- philstu 3y agoIf you read the article you'd know that this is about using OpenAPI Overlays and other use cases where JSONPath is literally a requirement. I think you just read the first paragraph then wrote a few about how its bad. More and more parts of the API ecosystem require JSONPath, and just saying "you should write code instead" doesn't actually help anyone write OpenAPI Overlays, so whats the point?