Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Arguments against JSON-driven development

okigiveup.net

Post reply on HN
Print view View original

271–280 of 306 posts

Re: Arguments against JSON-driven development

#271

Post by dang »

qwertyuiop924 wrote: post #53
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 ou…

You've repeatedly become uncivil in this thread. That's not ok, regardless of wrong or provocative someone else may be. If you can't remain civil, please don't comment here.

https://news.ycombinator.com/newsguidelines.html

https://news.ycombinator.com/newswelcome.html

Re: Arguments against JSON-driven development

#272

Post by catnaroek »

dang wrote: post #270
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.

I'm not sure what the dynamic is behind this weird flamewar, but it's definitely not the sort of discussion we want on HN, and your comments seem, presumably unintentionally, to have trolling effects. Please don't. We detached this subthread from https://news.ycombinator.com/item?id=12358875 and marked it off-topic.

> and your comments seem, presumably unintentionally, to have trolling effects.

I have no idea why stating facts would constitute “trolling”. But, anyway.

Re: Arguments against JSON-driven development

#273

Post by pdonis »

catnaroek wrote: post #268
pdonis wrote: post #266

Earlier quoted context omitted.

Is there some kind of reference that explains the terminology and theory you're using? Because it makes no sense to me as you're explaining it. It would be nice if such a reference also gave some real world examples where the terminology and theory you're using actually pays dividends, as I asked before.

> Is there some kind of reference that explains the terminology and theory you're using? On values: (0) “In call by value, the argument expression is evaluated, and the resulting value is bound to the corresponding variable in the function” ( https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_va... ) (1) “Most languages use a call by value [evaluation] strategy, in which only outermost redexes are reduced and…

I'm talking about a reference that explains this whole "equational reasoning" thing and the terminology and theory specific to that.

Re: Arguments against JSON-driven development

#274

Post by Retra »

catnaroek wrote: post #263
Retra wrote: post #262

Earlier quoted context omitted.

>There's only one: Two entities are equal if nothing can distinguish them. This is the “identity of indiscernibles”. This doesn't exist. If you can distinguish past and present, you can distinguish anything by time. An object in one moment is not identical to an object in another moment because the moment changed? No. You have to decide on what invariants you care about to have a consistent notion of identity. Yours…

> If you can distinguish past and present, you can distinguish anything by time. That's the thing: Objects exist in time. Values don't. Values exist in the language's semantics, which is a timeless mathematical object. Does it make sense to ask when the number 2 suddenly came into existence? > An object in one moment is not identical to an object in another moment because the moment changed? No. You have to decide on…

Oh right, we're talking about extradimensional computers. I didn't realize.

Re: Arguments against JSON-driven development

#275

Post by spc476 »

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…

That's the approach I took with my DNS library (https://github.com/spc476/SPCDNS)---extract the DNS packet into a C structure that's easier to deal with (for instance, the A RR structure: https://github.com/spc476/SPCDNS/blob/master/src/dns.h#L270).

Re: Arguments against JSON-driven development

#276

Post by tome »

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.

> I just expected (in the statistical sense of the term “expectation”)

If you're going to argue here about programming languages terminology it behooves you get terminology from other fields correct.

Re: Arguments against JSON-driven development

#277

Post by afroisalreadyin »

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…

I think I failed to represent the scale in the example. That's a heavily modified function from a code base I'm working on, and the inventory, book, cell etc. dictionaries and lists containing them are all over the place, with similar looping logic (e.g. find item with given label) and combinations are all over the place. Adding the objects to the above function would of course complicate it in the sense that it would get longer, but it would improve the actual example considerably. I will try to come up with better sample code that represents my worries better.

Re: Arguments against JSON-driven development

#278

Post by afroisalreadyin »

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…

Very good point. I would say that if your object is doing e.g. validation, or if/then/else'ing on field values to normalize them somehow, it's already far from anemic. But the key point is that you should not put data in objects, and then put the business logic, as in the small code sample, into some routine that simply accesses fields. That's the anti-pattern.

Re: Arguments against JSON-driven development

#279

Post by afroisalreadyin »

lmm wrote: post #11

The main reason this happens in Python is that creating actual datatypes is incredibly clunky (by Python standards) because of the tedious "def __init__(self, x): self.x = x". The solution here is to have a very lightweight syntax for more specific types, e.g. Scala's "case class". I'd also argue for using thrift, protobuf or even WS-* to put a little more strong typing into what goes over the network. Such schemata…

aeruder already posted the awesome glyphobet post on attrs; I agree with everything in there. The Python object protocol is great, but difficult to use for small classes. If you are not doing some kind of schema validation on REST endpoints, you're doing it wrong, I would say. But JSONSchema is also really sucky; write more JSON to validate JSON is not my idea of simplicity. Will have to look at the alternatives at some point.

Re: Arguments against JSON-driven development

#280

Post by dspillett »

oldmanjay wrote: post #249
dspillett wrote: post #123

Earlier quoted context omitted.

From the official source: "Democratic People's Republic of Korea" http://www.korea-dpr.com/ It's democratic, and for the people. It says nothing about being a totalitarian dictatorship. Not everything is/does what it says on the tin. You don't have to agree with official or otherwise authoritative sources without question. (not that I wish in any way to compare Mr Crockford or whoever runs json.org with DPRK or its l…

I hope you feel clever, because in context, this is far too inapplicable to the discussed reality of JSON to be an actual point.

> I hope you feel clever

I generally do, thanks, though I'm not any sort of genius by any measure.

> because in context, this is far too inapplicable to the discussed reality of JSON to be an actual point.

You seem to be missing a bit of an intentional context switch. The comment was more about the logic of the GP's response to " isn't really X" which was "yes is X, it says so on 's home page", than it was about or X in particular.

So it was relevant in the context of the discussion and the facts being used for reference but not, as you call out, in the context of the subject of the discussion (hence my somewhat defensive clarification of intent in the last sentence)

Post reply on HN