Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Arguments against JSON-driven development

okigiveup.net

Post reply on HN
Print view View original

11–20 of 306 posts

Re: Arguments against JSON-driven development

#11

Post by lmm »

The main reason this happens in Python is that creating actual datatypes is incredibly clunky (by Python standards) because of the tedious "def __init__(self, x): self.x = x". The solution here is to have a very lightweight syntax for more specific types, e.g. Scala's "case class".

I'd also argue for using thrift, protobuf or even WS-* to put a little more strong typing into what goes over the network. Such schemata won't catch everything (they have to have a lowest-common-denominator notion of type) but distributed bugs are the hardest bugs to track down; anything that helps you spot a bad network request earlier is well worth having.

Re: Arguments against JSON-driven development

#13

Post by jowiar »

With dynamic languages (certainly Python, Ruby, and JS), there's a definite lack of nudge from the tooling to translate from "interchange" format into an internal "smart" format (procedural code + everything is a hash = easy hacks). Whereas with something like Scala, the tools make it very clear that if you serialize/deserialize on the periphery, you're in for a bag of hurt (or, at the very least, fighting with one hand tied behind your back).

This is not to say that one tool is better than the others, but tools do have opinions, and while being more permissive/ambivalent makes throwing together a quick script easier, a tool that nudges you in the direction of building something in a more-sustainable way is useful when building nontrivial systems.

Re: Arguments against JSON-driven development

#14

Post by zdw »

And this is where we end up without easy to use and well supported schemas...

If this was XML, you'd write a very simple RELAX NG grammar (use the compact syntax: http://relaxng.org/compact-tutorial-20030326.html ) that describes the structure of the incoming data, then use it to validate the input data before processing it.

After that, you know data is valid and in the right structure, so you can throw away most of the "is this in the right place?" checks.

JSON and YAML's various schema implementations can't hold a candle to this, and it's been around for over a decade.

The XML ecosystem does have some very bad parts, but it's not all bad, so it's worth learning from places where it actually works well.

Re: Arguments against JSON-driven development

#15

Post by tantalor »

lmm wrote: post #11

The main reason this happens in Python is that creating actual datatypes is incredibly clunky (by Python standards) because of the tedious "def __init__(self, x): self.x = x". The solution here is to have a very lightweight syntax for more specific types, e.g. Scala's "case class". I'd also argue for using thrift, protobuf or even WS-* to put a little more strong typing into what goes over the network. Such schemata…

Named tuples assign meaning to each position in a tuple and allow for more readable, self-documenting code. They can be used wherever regular tuples are used, and they add the ability to access fields by name instead of position index.

https://docs.python.org/2/library/collections.html#collectio...

Re: Arguments against JSON-driven development

#16

Post by rm999 »

More generally, using data structures well-suited to your problem is really important but often underappreciated in software engineering. Elegant code and algorithms naturally follow.

In the example in the article, OO seems like a good way to go.

Re: Arguments against JSON-driven development

#18

Post by amyjess »

lmm wrote: post #11

The main reason this happens in Python is that creating actual datatypes is incredibly clunky (by Python standards) because of the tedious "def __init__(self, x): self.x = x". The solution here is to have a very lightweight syntax for more specific types, e.g. Scala's "case class". I'd also argue for using thrift, protobuf or even WS-* to put a little more strong typing into what goes over the network. Such schemata…

At one company I worked at, we used Avro to transfer data over the network. It's strongly typed with schemas, and it has both a compact binary form for transfer over the network and a text-based form for storage on disk that looks like JSON except field order matters (the schema and data are stored in separate files).

Re: Arguments against JSON-driven development

#19

Post by sk5t »

zdw wrote: post #14

And this is where we end up without easy to use and well supported schemas... If this was XML, you'd write a very simple RELAX NG grammar (use the compact syntax: http://relaxng.org/compact-tutorial-20030326.html ) that describes the structure of the incoming data, then use it to validate the input data before processing it. After that, you know data is valid and in the right structure, so you can throw away most of…

In Java land, swagger + dropwizard validation do a rather good job of this with json. I wouldn't be excited to return to using soap/xml all the time.

Re: Arguments against JSON-driven development

#20

Post by joshmarlow »

lmm wrote: post #11

The main reason this happens in Python is that creating actual datatypes is incredibly clunky (by Python standards) because of the tedious "def __init__(self, x): self.x = x". The solution here is to have a very lightweight syntax for more specific types, e.g. Scala's "case class". I'd also argue for using thrift, protobuf or even WS-* to put a little more strong typing into what goes over the network. Such schemata…

I've not yet made use of it, but using the `type` keyword to create new classes quickly looks promising.

https://docs.python.org/3.5/library/functions.html#type

Post reply on HN