Arguments against JSON-driven development • Hacker News Board

Re: Arguments against JSON-driven development

#161

Post by jbattle » Thu, Aug 25, 2016, 5:04 PM UTC

tantalor wrote: post #21

Cthulhu_ wrote: post #8

I disagree with the anemic object argument. 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. A large portion of back-end services are CRUD and data wrangling operations anyway - as in, convert data format A to data format B (which I guess could be a constructor or factory method if you're comfortable with having the conversion logic in a data cla…

Especially true if your business objects are generated code, e.g., protocol buffers. Combining business logic with business objects is a mistake. That's a textbook example of tight coupling.

> Combining business logic with business objects is a mistake. That's a textbook example of tight coupling.

Isn't that a textbook example of object oriented programming? Whether OOP is a mistake in and of itself is another question ...

Re: Arguments against JSON-driven development

#162

Post by sbov » Thu, Aug 25, 2016, 5:08 PM UTC

matwood wrote: post #57

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…

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 som…

Even beyond that, Jackson can use a private constructor if you use the @JsonCreator annotation on the constructor and @JsonProperty annotations on each parameter.

Re: Arguments against JSON-driven development

#163

Post by codedokode » Thu, Aug 25, 2016, 5:14 PM UTC

mythz wrote: post #90

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 additio…

Maybe they use untyped hashes and arrays just because there is no other data structures in JS?

Re: Arguments against JSON-driven development

#164

Post by dragonwriter » Thu, Aug 25, 2016, 5:18 PM UTC

catnaroek wrote: post #141

sevensor wrote: post #137

Earlier quoted context omitted.

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?

As things stand now, the main reason why Python can't do it is because it could potentially break programs.

> As things stand now, the main reason why Python can't do it is because it could potentially break programs.

Since the documented behavior of Python is compatible with what is suggested as a change, any program that relies on the behavior not reflecting as described in the "change" is asking to be broken (and quite possibly already broken across different implementations -- including different versions of the same implementation.) Immutable types in python already are defined with the semantics of values, in that "for immutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for mutable objects this is not allowed." [0]

[0] https://docs.python.org/2/reference/datamodel.html

Re: Arguments against JSON-driven development

#165

Post by okreallywtf » Thu, Aug 25, 2016, 5:18 PM UTC

jjzieve wrote: post #153

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 po…

I feel like we have this discussion at work daily involving nhibernate. It is an abstraction that makes 80% of work quicker and easier, but what it makes easier and cleaner would have been trivial anyways.

Re: Arguments against JSON-driven development

#166

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

catnaroek wrote: post #70

qwertyuiop924 wrote: post #65

Earlier quoted context omitted.

Logic programming's actually pretty close to FP.

Not really. Prolog is first-order. Functional languages, just like object-oriented ones, are higher-order.

"Close," not "is."

Re: Arguments against JSON-driven development

#167

Post by qwertyuiop924 » Thu, Aug 25, 2016, 5:29 PM UTC

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.

I'm not an object oriented programmer. The word "value" is used in many contexts. Functions take values and return the same, sometimes mutating the values they took. rvalues, which are almost anything, are assigned to lvalues, which are locations. You can probably think of more.

OTOH, your definition of object is almost entirely unique outside FP, AFAIK.

Re: Arguments against JSON-driven development

#168

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

qwertyuiop924 wrote: post #166

catnaroek wrote: post #70

Earlier quoted context omitted.

Not really. Prolog is first-order. Functional languages, just like object-oriented ones, are higher-order.

"Close," not "is."

There's very little in common, beyond the notions of mathematical variable and value. Syntactically, a functional program is an expression, but a logic program is a proposition. Operationally, functional programs run already constructed proofs, but logic programs search for proofs. Pragmatically, transcribing a logic program into a functional language or vice versa is difficult without effectively writing an interpreter for an embedded DSL.

Or maybe by “close”, you mean “both are about equally difficult to wrap my head around”?

Re: Arguments against JSON-driven development

#169

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

qwertyuiop924 wrote: post #167

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.

I'm not an object oriented programmer. The word "value" is used in many contexts. Functions take values and return the same, sometimes mutating the values they took. rvalues, which are almost anything, are assigned to lvalues, which are locations. You can probably think of more. OTOH, your definition of object is almost entirely unique outside FP, AFAIK.

> assigned to lvalues, which are locations.

lvalues aren't values.

Re: Arguments against JSON-driven development

#170

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

catnaroek wrote: post #114

jdmichal wrote: post #111

Earlier quoted context omitted.

> I'm deliberately provoking it. I'll just start flagging you for trolling then. It's one thing to attempt to have a meaningful discussion and unintentionally provoke ire. Meaningfully doing it by being obtuse and smug... I guess qwerty was spot on with the Randall Monroe quote.

> Meaningfully doing it by being obtuse and smug... I don't think I was being obtuse. I just expected (in the statistical sense of the term “expectation”) the reaction I got, and decided that it don't mind it.

...And that should have taught you something: it should have taught you that the language you're using isn't being readily understood, and that you need to either explain it, or change it.