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

81–90 of 306 posts

Re: Arguments against JSON-driven development

#81

Post by mattnewton »

parenthephobia wrote: post #71
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…

What are serialization formats, then? What makes them different from notations for data structures?

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.

Re: Arguments against JSON-driven development

#82

Post by StavrosK »

smizell wrote: post #32

Coupling your code to the JSON you receive over the web can lead to some interesting problems. If the system on the other end decides to make some change you are not expecting, it can lead to errors. In JavaScript, a simple thing that helps is to use lodash.get and provide a path to the property you are wanting. lodash.get(someObject, 'path.to.a.property') If the path isn't there, the lodash.get returns undefined. Th…

Yeah, this is currently pretty bad in Python, which led me to create the jsane library:

https://pypi.python.org/pypi/jsane

>>> j = jsane.loads('{"foo": {"bar": {"baz": ["well", "hello", "there"]}}}')

>>> j.foo.bar.baz[1].r()

u'hello'

Re: Arguments against JSON-driven development

#83

Post by StavrosK »

ajdlinux wrote: post #10
falcolas wrote: post #6

If you're in Python, and are afraid of "anemic" objects, I would recommend checking out collections.namedtuple. It's a fantastic lightweight and performant object-like data structure. You also get a few additional features, such as in-order iteration, the parameters are fixed at run time, and there's a method for turning it into an ordered dictionary (which is serializable in, wait for it, JSON).

If you're not limited to the standard library, https://github.com/hynek/attrs is also worth taking a look at.

I just found out about it in this article, and already posted a new story (it looks that good):

https://news.ycombinator.com/item?id=12359522

Re: Arguments against JSON-driven development

#84

Post by jdmichal »

catnaroek wrote: post #73
qwertyuiop924 wrote: post #66

Earlier quoted context omitted.

Well than FFS express yourself clearly.

Nobody other than an object-oriented programmer would think a value is something that evolves over time.

Here, look, I can do overly-broad, potentially-insulting generalizations too:

Only a functional programmer would think that recreating the entire universe is necessary to change a value.

See? Not very helpful or particularly insightful, is it?

Re: Arguments against JSON-driven development

#85

Post by ajmurmann »

joelcorrea wrote: post #72

Pretty much statically typed vs dinamically-typed discussion. It depends on your particular case, if there is a sufficiently defined schema or not

I don't see how this is related to statically typed vs dynamically typed. This is more a case of Primitive Obsession http://c2.com/cgi/wiki?PrimitiveObsession and a lack of a adapter/serialization layer.

Re: Arguments against JSON-driven development

#86

Post by catnaroek »

jdmichal wrote: post #84
catnaroek wrote: post #73

Earlier quoted context omitted.

Nobody other than an object-oriented programmer would think a value is something that evolves over time.

Here, look, I can do overly-broad, potentially-insulting generalizations too: Only a functional programmer would think that recreating the entire universe is necessary to change a value. See? Not very helpful or particularly insightful, is it?

> Only a functional programmer would think that recreating the entire universe is necessary to change a value.

That's wrong. You can't change a value at all. What you can change is the state of an object. And functional languages have mutable objects too:

https://docs.microsoft.com/en-us/dotnet/articles/fsharp/lang...

http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-IO...

Re: Arguments against JSON-driven development

#87

Post by jdmichal »

catnaroek wrote: post #86
jdmichal wrote: post #84

Earlier quoted context omitted.

Here, look, I can do overly-broad, potentially-insulting generalizations too: Only a functional programmer would think that recreating the entire universe is necessary to change a value. See? Not very helpful or particularly insightful, is it?

> Only a functional programmer would think that recreating the entire universe is necessary to change a value. That's wrong. You can't change a value at all. What you can change is the state of an object. And functional languages have mutable objects too: https://docs.microsoft.com/en-us/dotnet/articles/fsharp/lang... http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-IO...

It wasn't meant to be correct... That's the whole point.

"What we've got here, is a failure to communicate."

Your definition of a "value" seems to be a strictly immutable, functional-oriented definition. Which is fine; that's a valid definition and there's nothing wrong with it. The issues come from the fact that you seem to refuse to accept that that is one definition of many, and continue to push it without compromise.

Re: Arguments against JSON-driven development

#88

Post by adrianratnapala »

curveship wrote: post #67
adrianratnapala wrote: post #31

Earlier quoted context omitted.

I've never had good experiences with automated serialisation -- even though it sounds like other people do it with success. What's the secret? To give you a flavour of the kind of poblem: In C# (or rather .net) json.net reads JSON and calls setters from the target class. That means the setters have to be public, and you don't know what order they will be called in, and you have no real signal about when it is all don…

It sounds like you're parsing the JSON straight into your business objects, which is the source of the problem. You need an intermediate class which represents a strongly-typed version of the JSON message. So JSON.net goes from a JSON string into this message object, then you write your own code (or, if it works for you, use a tool like automapper), to go from that into your business classes.

This is what I settled on -- at least in the hard cases. And if I understand his acronyms, it's also what @mythz is recommending.

Perhaps I should have done it for the easy cases as well (where the business objects are struct-like enough that it doesn't matter) and just lived with the boilerplate.

But I see little advantage in this over just having a dictionary that I can inspect to initialise my real business object. True that is not strongly-typed, but the stage between the message-object and the business object can have validation errors anyway, so why not treat typechecking as part of that?

Re: Arguments against JSON-driven development

#89

Post by catnaroek »

jdmichal wrote: post #87
catnaroek wrote: post #86

Earlier quoted context omitted.

> Only a functional programmer would think that recreating the entire universe is necessary to change a value. That's wrong. You can't change a value at all. What you can change is the state of an object. And functional languages have mutable objects too: https://docs.microsoft.com/en-us/dotnet/articles/fsharp/lang... http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-IO...

It wasn't meant to be correct... That's the whole point. "What we've got here, is a failure to communicate." Your definition of a "value" seems to be a strictly immutable, functional-oriented definition. Which is fine; that's a valid definition and there's nothing wrong with it. The issues come from the fact that you seem to refuse to accept that that is one definition of many, and continue to push it without comprom…

The difference is that what I said was actually correct.

Re: Arguments against JSON-driven development

#90

Post by mythz »

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 additional knowledge of Types in order to access serialized data, so you can happily consume data structures in separate processes without the additional dependency of an external type system that's coupled and needs to be carried along with your data.

This is why Redux uses vanilla data structures in its store or why JSON has become popular for data interchange, any valid JSON can be converted into a JavaScript object with just `JSON.parse()` which saves a tonne of ceremony and manual effort then the old school way of having to extract data from data formats with poor programatic fit like an XML document into concrete types.

If your data objects don't need to be serialized or accessed outside of the process boundary than there's little benefit to using loose-typed data structures, in which case my preference would be using classes in a static type system to benefit from the static analysis feedback of using Types.

Post reply on HN