Select Transform: JSON template over JSON • Hacker News Board

Re: Select Transform: JSON template over JSON

#51

Post by earthboundkid » Wed, Oct 18, 2017, 4:15 PM UTC

arkh wrote: post #15

Gotta love JSON. It's XML without the tools so you get to reinvent everything to pad your resume. XML -> JSON WSDL -> JSON schema XPath -> JSON path XSLT -> JSON template? SOAP -> Swagger and friends One or two decades from now there will be too many tools and things to learn about JSON so another generation will reinvent a new "perfect format for everything". And a new cycle will have started.

I tweeted in Apr. 2016,

"You know how you feel when you have to parse XML from 2005? That’s how we’ll all feel about JSON in 2025. It’s not bad, just bloat-y."

XML, JSON, gRPC… These are all technologies to solve a problem. The trouble is people confuse technology with a business solution and they start applying it as though by "having a REST API" you've done something. You can't say you've accomplished anything until you actually demonstrably deliver value!

Re: Select Transform: JSON template over JSON

#52

Post by DEinspanjer » Wed, Oct 18, 2017, 4:16 PM UTC

This seems pretty interesting, and I will be happy to play around with it.

I am a bit concerned that there is no discussion in the docs of the potential security risks of allowing direct native JS execution of arbitrary instructions passed in by an untrusted source.

I use a project called JSONLogic (jsonlogic.com) which bears some similarity to ST in terms of being able to select and transform values. The biggest advantage I see with it is, unless you explicitly plug in a rule that parses and executes user data, there is no way for the data to "escape the sandbox". This means you can safely build a query syntax on top of it where you can directly consume the arbitrarily complex query from an untrusted source and execute it in a secure manner.

Re: Select Transform: JSON template over JSON

#53

Post by earthboundkid » Wed, Oct 18, 2017, 4:20 PM UTC

sly010 wrote: post #28

rtpg wrote: post #14

I think there's a lot of useful unexplored territory in this sort of tool. So much work nowadays is happening in maps/dictionaries/what-have-you, with a lot of work being, essentially, data shape transformation. Despite this, many languages aren't great at this! we have tools that work alright on first-order operations but fall apart on higher level things. Even really simple things like "conditionally include a key"…

IMHO any tool that converts JSON to JSON is pointing to the wrong direction. Json should strictly be used as a serialization format and everyone who touches it should immediately parse it into a typed data-structure that represents your domain better. In fact you really should represent your data in your code using whatever native object hierarchy / algebraic data types / option types / etc. your language supports. (…

You are very correct. Boilerplate (de)serialization code is 100x better to have to write than code with JSON-blobs pretending to be business objects.

Re: Select Transform: JSON template over JSON

#54

Post by Matt3o12_ » Wed, Oct 18, 2017, 4:25 PM UTC

skocznymroczny wrote: post #49

tchaffee wrote: post #46

Earlier quoted context omitted.

JSON is a lot easier to read. { "employees": [ { "name": "John Crichton", "gender": "male" }, { "name": "Aeryn Sun", "gender": "female" } ] } versus John Crichton male Aeryn Sun female

Or

I believe that was OP's point. Using the annotation you cannot add an attribute with subattributes. What if you wanted to add the employee's last six salaries. Suddenly you need to restructure your xml:

    
      
        John Crichton
        male
        
            10000
            10000
            10000
        
      
      
        Aeryn Sun
        female

Using JSON, you just so: “salaries”: [10000,10000,10000]

JSON is not only less verbose, it is also more flexible and easier to read and understand. You don’t have to worry about should I use tags or attributes for that because I late might have to use sub tags, and that makes it far easier to use (and honestly parse as well because many XML documents I have gotten are very inconsistent).

Re: Select Transform: JSON template over JSON

#55

Post by tome » Wed, Oct 18, 2017, 4:42 PM UTC

dualogy wrote: post #34

rtpg wrote: post #14

I think there's a lot of useful unexplored territory in this sort of tool. So much work nowadays is happening in maps/dictionaries/what-have-you, with a lot of work being, essentially, data shape transformation. Despite this, many languages aren't great at this! we have tools that work alright on first-order operations but fall apart on higher level things. Even really simple things like "conditionally include a key"…

> Haskell lenses kinda goes into this stuff They seem neat but I haven't come across a case where whipping up, in vanilla old-school Haskell, a custom set of small simple ADTs and the related handful of recursing walk-and-transform functions didn't do the job perfectly cleanly and comprehensibly.. this sort of stuff is already very compact to write and code-gen like TH seems almost overkill to me. Guess I'm itching t…

If you like writing

    let x = y { foo = foo y { bar = bar (foo y) + 1 } }

instead of

   let x = over (foo.bar) (+1) y

then more power to you!

Re: Select Transform: JSON template over JSON

#56

Post by eponeponepon » Wed, Oct 18, 2017, 4:44 PM UTC

Latty wrote: post #40

skocznymroczny wrote: post #2

XSLT for JSON?

Do people not remember how terrible XSLT was? I mean, sure, it could do the job, but did anyone ever sit down at a file of XSLT and think "yes, this is the best way this information about transforming this XML could be represented"? JSON is even less suitable for this. It's horrible to read this stuff, horrible to write.

XSLT was, and still is (imho) a great language - at least after 2.0.

There's a steep learning curve full of false summits, for sure, but once you grasp it, there is always an elegant way of solving a problem using it. Sometimes there's even a fast way!

Use of it in the wild, though, leaves a lot to be desired. The false summits lead people to write bad code, the bad code gives it a bad rep, the bad rep leads people to dislike using it, people's dislike leads to then writing bad code... and so on.

Re: Select Transform: JSON template over JSON

#57

Post by tchaffee » Wed, Oct 18, 2017, 4:46 PM UTC

skocznymroczny wrote: post #49

tchaffee wrote: post #46

Earlier quoted context omitted.

JSON is a lot easier to read. { "employees": [ { "name": "John Crichton", "gender": "male" }, { "name": "Aeryn Sun", "gender": "female" } ] } versus John Crichton male Aeryn Sun female

Or

Still more typing and less readable than the JSON. I happily used XML for years and have nothing against it. But JSON is almost always more readable. Big deal. Technology evolves. Trends that aren't an evolution usually fade. JSON does not seem to be one of those. It offers enough advantages over XML to have quickly replaced it in many cases.

Re: Select Transform: JSON template over JSON

#58

Post by dualogy » Wed, Oct 18, 2017, 4:58 PM UTC

tome wrote: post #55

dualogy wrote: post #34

Earlier quoted context omitted.

> Haskell lenses kinda goes into this stuff They seem neat but I haven't come across a case where whipping up, in vanilla old-school Haskell, a custom set of small simple ADTs and the related handful of recursing walk-and-transform functions didn't do the job perfectly cleanly and comprehensibly.. this sort of stuff is already very compact to write and code-gen like TH seems almost overkill to me. Guess I'm itching t…

If you like writing let x = y { foo = foo y { bar = bar (foo y) + 1 } } instead of let x = over (foo.bar) (+1) y then more power to you!

A neat example indeed! Yeah that makes sense. Especially I guess in code-bases where such deeply-nested record updates abound everywhere repeatedly time-and-again --- have not run into such myself yet. Writing the above on-the-rare-occasion is hardly troublesome. But I get the idea there now. (Although in the above, half the verbosity comes from using records instead of ADTs' ctors and I believe aren't there common idiomatic "standard" GHC lang-extensions to trim record updates in a shorter fashion --- ah well, been a while, I'm dabbling more in PureScript these days which sports a terser record-updates notation anyway =)

Re: Select Transform: JSON template over JSON

#59

Post by koonsolo » Wed, Oct 18, 2017, 5:03 PM UTC

tchaffee wrote: post #46

jimktrains2 wrote: post #38

Earlier quoted context omitted.

Why is it super awkward and how does JSON solve this problem any better?

JSON is a lot easier to read. { "employees": [ { "name": "John Crichton", "gender": "male" }, { "name": "Aeryn Sun", "gender": "female" } ] } versus John Crichton male Aeryn Sun female

I hate those comma's, forgetting them or having too many. So therefore I use YAML. Still way easier to read.

    employees:
        - name: John Crichton
          gender: male
        - name: Aeryn Sun
          gender: female

Re: Select Transform: JSON template over JSON

#60

Post by addicted » Wed, Oct 18, 2017, 5:47 PM UTC

mishoo wrote: post #29

What's wrong with: return { labels: data.items.map(function(value){ return { type: "label", value: value > 10 ? value : value * 100 }; }) }; I hope your project does not get too popular.

Even cleaner with ES6.

return { labels: data.items.map(value => { type: "label", value: value > 10 ? value : value * 100 }) };