Arguments against JSON-driven development • Hacker News Board

Re: Arguments against JSON-driven development

#101

Post by betenoire » Thu, Aug 25, 2016, 3:22 PM UTC

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.

"lightweight data interchange format" is not the same as "serialization formats".

For one, serialization usually handles binary data as well. And types, lots of types. Serialization includes class definitions, etc, which are used to create a (in this case) python object. JSON is literally javascript object notation, and has nothing to do with pickling python.

Re: Arguments against JSON-driven development

#102

Post by catnaroek » Thu, Aug 25, 2016, 3:22 PM UTC

jdmichal wrote: post #96

catnaroek wrote: post #89

Earlier quoted context omitted.

The difference is that what I said was actually correct.

It's correct only using your definitions and axioms. Other definitions and axioms can and do come to other conclusions. Your refusal to acknowledge that other definitions and axioms even exist is what is earning you the ire you are experiencing.

> Your definition of a "value" seems to be a strictly immutable, functional-oriented definition.

The very question of mutability only makes sense for objects that reside in computer memory. Asking whether values mutate is as meaningless as asking what the color of your feelings is.

> the ire you are experiencing.

I'm deliberately provoking it.

Re: Arguments against JSON-driven development

#103

Post by spdustin » Thu, Aug 25, 2016, 3:22 PM UTC

I may be missing something, so I'd appreciate a correction, but why all that effort when you can use collections.namedtuple and a custom object_hook for json.loads?

    import json
    from collections import namedtuple
    
    data = '{JSON string goes here}'
    fancy_data = json.loads(data, object_hook=lambda d: namedtuple('X', d.keys())(*d.values()))

Re: Arguments against JSON-driven development

#104

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

dragonwriter wrote: post #100

catnaroek wrote: post #17

> If an object is just there to store data and no behaviour, then that's fine - don't add behaviour if it doesn't need it. In that case, you want values rather than objects. Alas, Python doesn't have compound values.

> In that case, you want values rather than objects. In dynamic OOP languages, value/object distinctions are often not exposed to the language user (they may actually exist in the underlying implementation, but from the PoV of the programmer using the language, there may be no discernible distinction between an "immutable object" and "value".) Conceptually (and ignoring the implementation details, which may have perf…

> Conceptually ... immutable objects are equivalent to values, anyhow.

Nope. Since values don't reside in computer memory other than through their representations, the language implementation (compiler, runtime system, etc.) is free to apply optimizations such as:

(0) Determine whether a value is represented more than once in memory, and eliminate the redundant representations.

(1) Store multiple values in a single dynamically allocated memory block.

If object identities matter, all of this is unsound.

> ... (and ignoring the implementation details, which may have performance implications), ...

The performance implications can be constrained by equipping the language with a cost semantics.

Re: Arguments against JSON-driven development

#105

Post by jdmichal » Thu, Aug 25, 2016, 3:27 PM UTC

dragonwriter wrote: post #91

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.

Actually, OOP, particularly statically-typed OOP, seems to be a major domain in which the distinction between "value types" which contain "values" which do not evolve over time and "object types" which contain "objects" which may evolve over time is used frequently [0]. There are some OOP languages that take an "everything is an object" approach and provide no clear object/value distinction (this seems to be more the…

C# is an interesting case, in relation to your comment. It has `struct`, which defines value-semantic types instead of reference-semantic types. However, `struct` types still inherit from `System.Object` and may still encapsulate and provide behavior. So you don't necessarily need a dynamic type system to blur these lines.

Re: Arguments against JSON-driven development

#106

Post by sevensor » Thu, Aug 25, 2016, 3:27 PM UTC

catnaroek wrote: post #29

sevensor wrote: post #27

Earlier quoted context omitted.

As tantalor reminds us in a sibling comment, the named tuple works nicely in this role.

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

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?

Re: Arguments against JSON-driven development

#107

Post by kazinator » Thu, Aug 25, 2016, 3:28 PM UTC

qwertyuiop924 wrote: post #45

wtbob wrote: post #5

> The fundamental advice on Unicode is decode and encode on system boundaries. That is, you should never be working on non-unicode strings within your business logic. The same should apply to JSON. Decode it into business logic objects on entry into system, rejecting invalid data. Instead of relying on key errors and membership lookups, leave the orthogonal business of type validity to object instantiation. This righ…

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…

A notation for a data structure is a serialization format.

> In Lisp, that Sexpr will be crawled for data, or maybe even executed.

A s-expression cannot be executed; it's just text.

The object which it denotes can be walked or executed via eval.

Before that happens, the s-expression must be converted to that object.

In other words, deserialized by the reader.

Re: Arguments against JSON-driven development

#108

Post by wvenable » Thu, Aug 25, 2016, 3:28 PM UTC

beat wrote: post #93

I think this article is somewhat off-base. The problem isn't JSON, it's lack of respect for separation of duties. JSON is just a data exchange format. Want to program in an OO way using JSON? Easy. Just build a factory to generate objects from JSON input. Put your validation and error handling right there. Now you can get a known valid object from the JSON, a class instance with all the encapsulation and business log…

The author isn't saying the problem is JSON.

The same programming style exists quite a bit in older PHP code as well. This is because one of it's primary data types is an list/hashtable hybrid. And JSON is similar -- it promotes those same structural types; the list and the hashtable (array and object, respectively). So programmers are using them, not just for building structures for data interchange, but for actual programming logic.

The fix for the problem is just education.

Re: Arguments against JSON-driven development

#109

Post by spullara » Thu, Aug 25, 2016, 3:29 PM UTC

At this point everyone should be using an evolvable (thrift, protocol buffers, avro, etc) schema format when they are storing or transmitting their data if they want to run an always on service - there is no downtime for migrations in the real world. Trying to do this ad-hoc with JSON is a lost cause and will eventually lead you to failure at runtime or worse, data loss situations.

Re: Arguments against JSON-driven development

#110

Post by milesvp » Thu, Aug 25, 2016, 3:29 PM UTC

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 data (very possibly serialized). Nearly every time I've seen coworkers try to improve things with classes, it complicates the code, and often adds little encapsulation given how much we do is reliant on external data sources.

Every once in a while I think how nice it would be to be able to use typed data and smart setters to avoid much of the bounds checking I have to do, but I find there's never enough code between the boundaries of serialization to make it worth the added complexity that this introduces (also my problem domain involves mostly copy so most things are basically strings, ints, or datetimes anyways).