Arguments against JSON-driven development • Hacker News Board

Re: Arguments against JSON-driven development

#151

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

dpark wrote: post #150

catnaroek wrote: post #95

Earlier quoted context omitted.

> Though in most such languages, the distinction between object and value involves more than just mutability, and is more deeply associated with indirection of storage Values, unlike objects, don't reside on memory, but rather in the semantics of the language. Of course, representations of values reside in memory. But that's an implementation detail. What matters is the abstraction the programmer is exposed to.

So your assertion is that objects are not an abstraction or defined by language semantics?

Objects are a different abstraction: they're defined by the language's semantics to have a unique identity and be stored in memory exactly once at runtime. I won't blame objects for not being values.

Re: Arguments against JSON-driven development

#152

Post by lgunsch » Thu, Aug 25, 2016, 4:44 PM UTC

I find that code that uses dictionaries a lot ends up with mysterious unnamed types used in various places throughout the system disguised as dictionaries. They have required fields, and must interacted with using business logic that is not obvious. This becomes a real problem when the original authors of the system are gone, and new maintainers have taken over and have to implement new features.

By using objects, or lightweight objects like namedtuple, which have already been mentioned in other comments a bunch, you formally document the data-structure. You give it a name, expected fields, and required behaviours when interacting with it. The code becomes much easier to follow and understand clearly. Bugs don't creep in when a new maintainer forgets about the mysterious undocumented required business logic.

Re: Arguments against JSON-driven development

#153

Post by jjzieve » Thu, Aug 25, 2016, 4:47 PM UTC

At least lists, dictionaries map relatively well to a tabular (SQL) format. Objects don't map well at all! Anyone who's spent enough time with "mature" ORMs knows this. Especially when there's a deadline and you have to write "native" SQL just to get whatever the hell you needed in the first place. "Well maybe you should have read everything and understood the ORM to its most minute detail..." NO! That's the whole point of abstraction! If I understood everything about that code, I'd be better off re-writing it to better suit MY specific problem. Look, I don't want to be another OO basher. OO definitely has a place in complex systems like game development, where the lives of the objects are longer than a page refresh. But in web dev, its becoming increasingly obvious to me that the OO paradigm is a huge time suck. /rant

Re: Arguments against JSON-driven development

#154

Post by codedokode » Thu, Aug 25, 2016, 4:50 PM UTC

In PHP we call it "Array Oriented Programming" ( http://www.epixa.com/2012/04/array-oriented-programming.html ). So looks like Python developers finally discovered this paradigm too. Let's wait for JS developers now.

By the way, PHP has type hints for functions that help to understand what are the types of arguments and the return type.

Re: Arguments against JSON-driven development

#155

Post by badminton1 » Thu, Aug 25, 2016, 4:50 PM UTC

I like to wrap relevant objects around a type, that is responsible for creating, validating, serializing, deserializing and mutating that object.

But taking a JSON and passing it around, with no ownership, no predictability... it's the mindset of the tech debt programmer.

Re: Arguments against JSON-driven development

#156

Post by Millennium » Thu, Aug 25, 2016, 4:52 PM UTC

It sounds to me like these arguments aren't so much against JSON, per se. They're against using JSON.parse() (or json.loads() in Python, json_decode() in PHP, or whatever) as your entire data-import process.

Instead, the argument goes, one should load the JSON, walk the redulting structure, and use it to build your native data structure/objects/whatever. Similarly, when the time comes to save, you crawl through your native structure to build a dict/array/primitive structure, then call JSON.stringify() (or the analogous function) to serialize that.

Uncoupling your data structure from the serialization format, though, is really just basic good software design anyway, is it not? Does anyone argue in favor what this article calls "JSON-driven development" as a design principle? Or is it just a shortcut that developers -and I am no less guilty of this than anyone else- sometimes take in the interest of getting a quick-and-dirty solution out the door?

Yes, working directly on the output of JSON.parse() is a code smell. But I'm not sure that claiming there's a rising trend of "JSON-driven development" is entirely founded. It's just people taking shortcuts.

Re: Arguments against JSON-driven development

#157

Post by astazangasta » Thu, Aug 25, 2016, 4:57 PM UTC

JSON is the equivalent of a UNIX pipe; it is for passing data between applications on the Internet, just like a pipe is a way for passing data between applications on a machine.

Re: Arguments against JSON-driven development

#158

Post by joelcorrea » Thu, Aug 25, 2016, 4:57 PM UTC

ajmurmann wrote: post #85

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.

I meant, typed vs not-typed. Someone mentioned Clojure, and for me thats the whole point: on one hand, and for a whole category of problems the best abstraction is not to have a strong schema, given the variable parts. On the other hand however there are scenarios where you already know the structure sufficiently well. A matter of abstraction IMO

Re: Arguments against JSON-driven development

#159

Post by debaserab2 » Thu, Aug 25, 2016, 5:01 PM UTC

catnaroek wrote: post #95

dragonwriter wrote: post #91

Earlier quoted context omitted.

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…

> Though in most such languages, the distinction between object and value involves more than just mutability, and is more deeply associated with indirection of storage Values, unlike objects, don't reside on memory, but rather in the semantics of the language. Of course, representations of values reside in memory. But that's an implementation detail. What matters is the abstraction the programmer is exposed to.

I think we might have just found the Ken M. of hacker news.

Re: Arguments against JSON-driven development

#160

Post by mixmastamyk » Thu, Aug 25, 2016, 5:02 PM UTC

spullara wrote: post #109

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.

Anyone have a good blog post handy on this?