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

121–130 of 306 posts

Re: Arguments against JSON-driven development

#121

Post by mattnewton »

steveklabnik wrote: post #94
mattnewton wrote: post #81

Earlier quoted context omitted.

Not gp, but one difference is you can have a notation that can't capture some state: think of the date class in JavaScript. JSON can't serialize this without resorting to string encoding, whereas something like a protobuf or pickle could.

That means JSON is missing support for some kinds of data, that doesn't mean that it's not a serialization format at all. Just one with less descriptive power.

That's fair, I guess it's not really a different class but a different shade of the same thing.

Re: Arguments against JSON-driven development

#122

Post by catnaroek »

dragonwriter wrote: post #117
catnaroek wrote: post #29

Earlier quoted context omitted.

All you need to do is use the `is` operator to see how even tuples (named or otherwise) are objects, not values.

> All you need to do is use the `is` operator to see how even tuples (named or otherwise) are objects, not values. That is not language feature of Python but an implementation detail. Python implementations are permitted (but not required) to intern any immutable value (which tuples, contrary to your description, are ), and "is" is a mechanism for revealing what the implementation has done . You seem to be equivocati…

> That is not language feature of Python but an implementation detail.

So you're saying that the behavior of the `is` operator is implementation-defined?

> values as a logical thing (where Python absolutely has compound values, including tuples)

The (informal, unspecified) metalanguage that you're using to reason about Python programs has compound values. Python itself doesn't.

Re: Arguments against JSON-driven development

#123

Post by dspillett »

recursive wrote: post #92
qwertyuiop924 wrote: post #45

Earlier quoted context omitted.

Part of the problem is that JSON and Sexprs aren't that they AREN'T serialization formats. They've been pressed into service as such, but they are actually notation for datastructures: In python, it may not be idiomatic to crawl dicts like this, but in JS, those aren't dicts, they're objects. If they've been de-serialized to some degree, they may even have their own methods. By the same token, in Lisp, Sexprs aren't…

From the official source: "JSON (JavaScript Object Notation) is a lightweight data-interchange format. " http://json.org/ It's nothing about pressing into service. This is the authoritative source.

From the official source: "Democratic People's Republic of Korea"

http://www.korea-dpr.com/

It's democratic, and for the people. It says nothing about being a totalitarian dictatorship.

Not everything is/does what it says on the tin. You don't have to agree with official or otherwise authoritative sources without question.

(not that I wish in any way to compare Mr Crockford or whoever runs json.org with DPRK or its leadership - I'm just using a deliberatly extreme example to highlight that what is written may not be what is, at least not from absolutely everyone's point of view)

Re: Arguments against JSON-driven development

#124

Post by lanestp »

I take a couple of issues with the author here. I don't personally worry much about breaking away from strict OOP. When a pattern like this develops it is usually because the data is too dynamic for a static property list. An obvious example is for creating reports. No one is going to sit down and hand design every single multi column report in a large project (I tell a lie, people do, it just makes the code base a horror show). By letting the data be more dynamic (Usually with JSON) it is trivial to create generic report structures and populate them.

Additionally, if you are using NoSQL as a backing store then solutions like class serialization don't make any sense since you will need to communicate in JSON anyway.

Re: Arguments against JSON-driven development

#125

Post by czardoz »

jerf wrote: post #120
qwertyuiop924 wrote: post #45

Earlier quoted context omitted.

Part of the problem is that JSON and Sexprs aren't that they AREN'T serialization formats. They've been pressed into service as such, but they are actually notation for datastructures: In python, it may not be idiomatic to crawl dicts like this, but in JS, those aren't dicts, they're objects. If they've been de-serialized to some degree, they may even have their own methods. By the same token, in Lisp, Sexprs aren't…

JSON is a serialization format that was based on the data structure notation for Javascript. It is, however, a serialization format. Javascript objects are a superset of JSON, as they can contain arbitrary objects and functions, which JSON can not, and "true" Javascript object notation can elide quote marks or use apostrophes for keys, whereas JSON strictly specifies double-quotes around keys. The problem that arises…

> In strongly-typed languages there's a stronger focus on parsing the JSON instead

I think you mean _statically_ typed languages here. Python is a strongly typed language.

Re: Arguments against JSON-driven development

#126

Post by Nullabillity »

mythz wrote: post #90

This isn't JSON-driven development, it's just choosing to apply logic over loose-typed data structures instead of named constructs. It's more awkward in Python because it doesn't have sugar syntax to index an object like JavaScript has. But using clean built-in data structures instead of named types has its benefits especially if you need to serialize for persistence of communication as it doesn't require any additio…

> as it doesn't require any additional knowledge of Types in order to access serialized data

You still need to know the shape of the data you're working with, or you won't get anything useful done. So you can't skip defining types or a format, you're just skipping the tools that help you follow said format.

Re: Arguments against JSON-driven development

#127

Post by kodablah »

solatic wrote: post #118
Cthulhu_ wrote: post #7

Earlier quoted context omitted.

When using parsers like e.g. Jackson or Gson for Java, this process is completely transparent and does not require any active thought from the developer - well, maybe if there's very specific formats that don't map 1:1 with the class that should be instantiated or generated from the json object. It's a bit more tricky in JS, both client-side and node. You can't work with the json string there, but after that you work…

Automated serialization is the devil. Gson and Jackson require you to write EJB-style objects to get automatic serialization - default constructors, with getters and setters for each field - to achieve automatic serialization. The problem with this approach is that you've completely abdicated the power of the type system to ensure that your objects are valid. What happens if a field is missing from the JSON? Well, th…

Automatic serialization is not the devil, overly forgiving automatic serialization is the devil. I use JSON serialization libs all the time in Scala which properly support optional vs required fields. For Java devs, Gson has bad required/optional support [0] but Jackson does have it for creator properties [1]. It is important to qualify statements like your initial one to include the specific situation which it is bad instead of using a broad brush.

0 - https://github.com/google/gson/issues/61 1 - http://static.javadoc.io/com.fasterxml.jackson.core/jackson-...

Re: Arguments against JSON-driven development

#128

Post by dragonwriter »

catnaroek wrote: post #122
dragonwriter wrote: post #117

Earlier quoted context omitted.

> All you need to do is use the `is` operator to see how even tuples (named or otherwise) are objects, not values. That is not language feature of Python but an implementation detail. Python implementations are permitted (but not required) to intern any immutable value (which tuples, contrary to your description, are ), and "is" is a mechanism for revealing what the implementation has done . You seem to be equivocati…

> That is not language feature of Python but an implementation detail. So you're saying that the behavior of the `is` operator is implementation-defined? > values as a logical thing (where Python absolutely has compound values, including tuples) The (informal, unspecified) metalanguage that you're using to reason about Python programs has compound values. Python itself doesn't.

> So you're saying that the behavior of the `is` operator is implementation-defined?

No, the behavior has a standard definition: it reveals whether the operands refer to the same in-memory construct.

Whether immutable values are stored in the same in-memory construct is, however, AIUI, implementation dependent.

Re: Arguments against JSON-driven development

#129

Post by catnaroek »

dragonwriter wrote: post #128
catnaroek wrote: post #122

Earlier quoted context omitted.

> That is not language feature of Python but an implementation detail. So you're saying that the behavior of the `is` operator is implementation-defined? > values as a logical thing (where Python absolutely has compound values, including tuples) The (informal, unspecified) metalanguage that you're using to reason about Python programs has compound values. Python itself doesn't.

> So you're saying that the behavior of the `is` operator is implementation-defined? No, the behavior has a standard definition: it reveals whether the operands refer to the same in-memory construct. Whether immutable values are stored in the same in-memory construct is, however, AIUI, implementation dependent.

> Whether immutable values are stored in the same in-memory construct is, however, AIUI, implementation dependent.

If I can't bind it to a variable, it isn't a value. You can't bind the list [1,2,3] to a variable, because Python has no such thing as the list [1,2,3].

Re: Arguments against JSON-driven development

#130

Post by mythz »

Nullabillity wrote: post #126
mythz wrote: post #90

This isn't JSON-driven development, it's just choosing to apply logic over loose-typed data structures instead of named constructs. It's more awkward in Python because it doesn't have sugar syntax to index an object like JavaScript has. But using clean built-in data structures instead of named types has its benefits especially if you need to serialize for persistence of communication as it doesn't require any additio…

> as it doesn't require any additional knowledge of Types in order to access serialized data You still need to know the shape of the data you're working with, or you won't get anything useful done. So you can't skip defining types or a format, you're just skipping the tools that help you follow said format.

You only need to know how to access the data you need, not the entire class structure that's coupled to the monolith that created it.
Post reply on HN