Arguments against JSON-driven development • Hacker News Board

Re: Arguments against JSON-driven development

#131

Post by wst_ » Thu, Aug 25, 2016, 3:52 PM UTC

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…

Jackson allows you to create immutable object without any problems, with final fields initialized in constructor. It also supports numerous annotations that will throw an exception when field is missing, etc. You just have to know your tool and use it properly, that's all.

Re: Arguments against JSON-driven development

#132

Post by corysama » Thu, Aug 25, 2016, 3:53 PM UTC

The author has lots of good points. Because I write most of my Python in the style he is advising against, I recognize that style has issues. The main issue for me is that a dict of dicts of dicts is not an interface. It doesn't have any constraints. It doesn't communicate expectations for use for the actual intent of the code. The best you can do is a comment explaining what to expect and a lot of error checking.

That said, almost all of the python I write these days is in the form of functional transforms on built-in data structures. And I love it!

There was a great Pycon2012 talk titled "Stop Writing Classes". You can find it linked and discussed here https://news.ycombinator.com/item?id=3717715

Re: Arguments against JSON-driven development

#133

Post by jerf » Thu, Aug 25, 2016, 3:53 PM UTC

czardoz wrote: post #125

jerf wrote: post #120

Earlier quoted context omitted.

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.

The definition of "strongly-typed" that Python conforms to is a useless one, because very few weakly-typed languages exist anymore, and even those are only very, very partially "weakly typed" by having operators that are defined to do automatic coercion, generally only between strings and numbers, which isn't even the way the original "weakly typed" was meant. The only truly "weakly typed" language I know of that is still extant is assembler/machine language, which can never really go away, where all you ever have are numbers, and thus absolutely nothing stops you from adding a string pointer to the first element of some structure. (Modulo some distinctions that still may exist between floats and integers and such... even assembler isn't as weak as it used to be, though it is still by no means a strongly-typed language.)

So I don't use the useless definition. By any useful definition of strong vs. weak typing, that is, one that actually creates two or more non-empty, non-trivial sets of members in the universe of discourse, Python is a weakly-typed language.

Re: Arguments against JSON-driven development

#134

Post by dgb23 » Thu, Aug 25, 2016, 3:53 PM UTC

From an OO perspective I can completely agree with this and the encode/decode pattern the author is suggesting seems to be the right way to deal with this problem as it will also hopefully translate in having an esperanto data type which can be used for all sorts of APIs and formats.

But from a functional perspective I would disagree. The code example wouldn't even make sense in that world. You would query it as is and compare it with other data or create new structures as with any other data you handle in your language.

Re: Arguments against JSON-driven development

#135

Post by davidism » Thu, Aug 25, 2016, 3:56 PM UTC

corysama wrote: post #132

The author has lots of good points. Because I write most of my Python in the style he is advising against, I recognize that style has issues. The main issue for me is that a dict of dicts of dicts is not an interface. It doesn't have any constraints. It doesn't communicate expectations for use for the actual intent of the code. The best you can do is a comment explaining what to expect and a lot of error checking. Th…

Start Writing More Classes: http://lucumr.pocoo.org/2013/2/13/moar-classes/

HN discussion: https://news.ycombinator.com/item?id=5204967

Re: Arguments against JSON-driven development

#136

Post by malodyets » Thu, Aug 25, 2016, 3:58 PM UTC

I prefer XML + schema (for which I use RelaxNG + jing) because this makes validating the input very straightforward and normalizes that process. But I understand the appeal of JSON and use it for some APIs myself. What experiences do people have with JSON.net Schema? Does anyone know of a json schema + validator system that is cross-language?

Re: Arguments against JSON-driven development

#137

Post by sevensor » Thu, Aug 25, 2016, 4:02 PM UTC

catnaroek wrote: post #113

sevensor wrote: post #106

Earlier quoted context omitted.

While that's a good point, the namedtuple is value-like enough to address the "anemic objects" problem. Could you expand on the advantages of this: (a, b, c) is (a, b, c) being True instead of False?

The runtime system's memory manager could automatically hash-cons equal compound values, reducing their memory footprint. It's like the flyweight pattern, except the runtime system gives it to you for free.

I agree that's nice for memory use. It's totally consistent with the immutability of tuples, too. I suppose Python has elected to take the memory hit to reduce complexity in the interpreter?

Re: Arguments against JSON-driven development

#138

Post by jowiar » Thu, Aug 25, 2016, 4:02 PM UTC

milesvp wrote: post #110

sidlls wrote: post #51

I'm not entirely in agreement. Use of object-oriented programming paradigms here would merely distribute the logic that is necessary to achieve the desired mapping over multiple points in the code. The example function presented is only marginally too complicated. I'd split it in two: one to obtain the book list given the same arguments as the example function, and one taking the result as its only argument to build…

This. I've been programming this way for over a decade. Long before JSON was a thing. I find I rarely need anythng more than a list or a dict for most of the data manipulation I do. Being on the web has only strengthened my tendency for this, since everything ends up being stringly typed anyways. Nearly every function/API I write is: get some data from somewhere (hopefully serialized), manipulate the data, return dat…

Lists are lists, and I have no issues there. It's dicts as objects (often nested) where things to get hairy. I often see folks end up relying on internal implementation details of other libraries, or other data sources, and things can subtly break (or explode in a ball of fire).

The more systems I've built, the more I've wanted to have very well-defined seams between "inside" and "outside" -- well-defined interfaces with external APIs, libraries, databases, systems that may be maintained at a different speed, etc. Having an explicit translation/serialization/etc. step forces you to do this. It's not the only way, but pretty much every codebase I've interacted with that doesn't do this gets careless, and it's can get really messy when things get any longer than a "script".

Re: Arguments against JSON-driven development

#139

Post by whateveracct » Thu, Aug 25, 2016, 4:03 PM UTC

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…

> 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.

I've used Gson fine with Scala case classes.

Although now I just use Scala JSON libraries, which do not suffer from the two problems you list at all.

Re: Arguments against JSON-driven development

#140

Post by jroseattle » Thu, Aug 25, 2016, 4:05 PM UTC

Just an aside, I'm not sure I agree with the title of "JSON-driven" development.

The problem being described is about using parts of a language in an inefficient or ineffective way of solving a problem.

The solution to this particular problem can be summed up in concepts like encapsulation or DRY. More to the point, let's not blame components like JSON for basically poor implementation.