Arguments against JSON-driven development • Hacker News Board

Re: Arguments against JSON-driven development

#51

Post by sidlls » Thu, Aug 25, 2016, 2:31 PM UTC

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

I find myself shying away from rigorous adherence to encapsulation more and more these days. I prefer small functions that operate on data explicitly.

Edit: and I'm a bit confused how the example has anything to do with "JSON-driven development", other than the coincidence that a hash/dictionary is the core data structure being manipulated here. This example function could exist and be (mostly) reasonable had JSON never existed. I'd expect to see an argument that the JSON serialization schemes that abound are problematic, given the title.

Re: Arguments against JSON-driven development

#52

Post by clifanatic » Thu, Aug 25, 2016, 2:32 PM UTC

micimize wrote: post #41

While I see the point the Ulaş is getting at, I wouldn't call this JSON-driven development. I think JSON-driven development would use abstraction layers that are based on JSON, like JSON schema, and perhaps an OOP library that leverages it. What I'd actually call this problem is a lack of abstraction. In functional programming, simple data structures are often preferred, and composable functions are used to manage co…

Yeah, I was seeing code like that in Java long before the term "JSON" was coined.

Re: Arguments against JSON-driven development

#53

Post by qwertyuiop924 » Thu, Aug 25, 2016, 2:34 PM UTC

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.

Please stop it.

Every single time anything so much as slightly related comes up, you talk about compound object. Incessantly. And then you act superior when nobody knows what you mean, or cares about compound values. They're not really relevant to this discussion anyways, as storing data as desribed in GPP is perfectly reasonable.

The worst part is, your definition of "value" and "object" in this context is so far out of the ordinary that people should be expected to not understand it, and you should provide an explanation pre-emptively.

To quote Randall Munroe, "Communicating badly and then acting smug when you're misunderstood is not cleverness"

Re: Arguments against JSON-driven development

#54

Post by qwertyuiop924 » Thu, Aug 25, 2016, 2:35 PM UTC

catnaroek wrote: post #39

in_the_sticks wrote: post #37

Earlier quoted context omitted.

That's a useless distinction. Everything is an object in Python. Does that mean Python doesn't have values?

It has primitive values: (0) small enough numbers (1) True, False, None, etc. (2) object references But it doesn't have compound values. And the distinction isn't useless. Values have a richer equational theory than objects, enabling lots of automatic optimizations.

...And outside FP, nobody cares, or uses that definition of value. As noted in my above post.

Re: Arguments against JSON-driven development

#55

Post by collyw » Thu, Aug 25, 2016, 2:37 PM UTC

davexunit wrote: post #36

michaelfeathers wrote: post #25

This is space that the Clojure community has already visited.

And every other Lisp community.

And what was their outcome?

Re: Arguments against JSON-driven development

#56

Post by qwertyuiop924 » Thu, Aug 25, 2016, 2:37 PM UTC

micimize wrote: post #41

While I see the point the Ulaş is getting at, I wouldn't call this JSON-driven development. I think JSON-driven development would use abstraction layers that are based on JSON, like JSON schema, and perhaps an OOP library that leverages it. What I'd actually call this problem is a lack of abstraction. In functional programming, simple data structures are often preferred, and composable functions are used to manage co…

And then EVERY programmer would further abstraact that, as you really want the bare minimum of your code depending on your datastructure internals.

Re: Arguments against JSON-driven development

#57

Post by matwood » Thu, Aug 25, 2016, 2:38 PM UTC

adrianratnapala wrote: post #31

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…

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…

In Java land with Jackson/Gson they can use the getters/setters or reflection and find the private fields. The only time it is not completely automatic is when some json object is mixed cased myField1 and my_field1. Even then, just adding an annotation fixes it. For any special formats, for example iso8601 dates, you can quickly define a serializer/deserializer and be done.

Is it really that hard in c#? It is not something I ever think about in Java.

Re: Arguments against JSON-driven development

#58

Post by grandalf » Thu, Aug 25, 2016, 2:38 PM UTC

The code in the example has poor encapsulation, but I do not think it's the "JSON" style that causes that.

Much OOP code includes a hodgepodge of exposed internal state and methods that offer a combination of derived state and behavior to mutate that state.

Often, using data literals (like JSON) can make code clearer by making it explicit what is going on with state (when/if it is being mutated), and making the system easier to snapshot, test, etc.

While much code that uses JSON-like constructs is overly verbose and error prone, adding a bit of structural typing (with Flow) or creating schemas to ensure system invariants (jsonschema) can lead to a system that is easy to reason about and maintain.

Re: Arguments against JSON-driven development

#59

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

qwertyuiop924 wrote: post #54

catnaroek wrote: post #39

Earlier quoted context omitted.

It has primitive values: (0) small enough numbers (1) True, False, None, etc. (2) object references But it doesn't have compound values. And the distinction isn't useless. Values have a richer equational theory than objects, enabling lots of automatic optimizations.

...And outside FP, nobody cares, or uses that definition of value. As noted in my above post.

It's useful when writing Prolog programs too.

Re: Arguments against JSON-driven development

#60

Post by qwertyuiop924 » Thu, Aug 25, 2016, 2:40 PM UTC

mcms wrote: post #33

Anemic objects and whether they are harmful or harmless has been debated in software engineering for long. I find over-relying on encapsulation more harmful than useful nowadays specially if you are going to write scalable software that are inherently distributed. For example, hiding accessing a database behind a simple getter function makes another programmer ignore performance implication and other issues that may…

Yes, but OTOH, it lessens the likelyhood of errors, and means you'll have to rewrite minimum amounts of code when you, say, switch from MySQL to Postgres.

Abstraction always lessens awareness of that which is abstracted. Decide where to draw the line for your app.