Live data from Hacker News

Arguments against JSON-driven development

okigiveup.net

301–306 of 306 posts

Re: Arguments against JSON-driven development

#301

Earlier quoted context omitted.

Both definitions of "value" are accurate. That's what makes this whole thing so confusing. Officially, yes, cat is right, but in common usage, value leans more towards my definition.

It doesn't make sense to talk of value as a location. A value is a piece of data, plain and simple. So lvalues and objects aren't values. OTOH, I can agree with the imperative programmer's intuition of a variable as a location where you can store a value (rather than a symbol that can be consistently substituted with a value). It's not a mathematical variable, but it's a sufficiently established meaning to be taken i…

>It doesn't make sense to talk of value as a location. A value is a piece of data, plain and simple. So lvalues and objects aren't values.

It doesn't have to make sense (I think it makes perfect sense, but that's neither here nor there): people do it, and the default assumed definition of a value is broad enough that it allows for it, IME.

I don't object to your definition, but can you please just tell everybody what you mean by value in your comment if it's not what people expect, so that people like me don't have to build a deeply nested discussion thread to establish what you mean?

If I was sure of its legality by the rules of HN, I'd be lf half a mind actually write a bot to insert the definition below your posts, and save people a lot of time trying to ascertain what you mean, so the we could all have a more interesting discussion about the ideas, rather than the terminology.

Re: Arguments against JSON-driven development

#302

I agree 100% with the article. I've just written a script which makes every one of the mistakes listed in the article. I am consuming a JSON based API in a long ugly mash of code, exactly as described. It doesn't look pretty. In my defence, I wrote the code as I was trying to understand the API. I had not read ahead and didn't really know which API's I would need or how fiddly it would be to bring it all together. I…

I went back and fixed the script to turn a portion of the JSON API into a set of useful Python objects. The code looks mostly OK now.

It's no surprise that it took about the same amount of time again to tidy it up. Apart from making me feel better, and a promise of less work in the future for updates, it's hard to justify the extra effort.

Re: Arguments against JSON-driven development

#303
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…

I agree, but the problem is that usually the representation of the data comes before the logic you need around it, which can accumulate over a period of months or years. Depending on the application, depending on the programmer(s), that logic can turn into a real mess since there's no obvious place for it to live. This reduces code reuse, which leads to bugs.

It's not always appropriate, but building some language-idiomatic encapsulation around data from the very start makes it much less likely that the inevitable addition of hundreds or thousands of lines of logic will descend into incomprehensible spaghetti hell. This doesn't have to be OOP; it could just as easily be e.g. a module in a purely functional language.

Re: Arguments against JSON-driven development

#304

Earlier quoted context omitted.

It doesn't make sense to talk of value as a location. A value is a piece of data, plain and simple. So lvalues and objects aren't values. OTOH, I can agree with the imperative programmer's intuition of a variable as a location where you can store a value (rather than a symbol that can be consistently substituted with a value). It's not a mathematical variable, but it's a sufficiently established meaning to be taken i…

>It doesn't make sense to talk of value as a location. A value is a piece of data, plain and simple. So lvalues and objects aren't values. It doesn't have to make sense (I think it makes perfect sense, but that's neither here nor there): people do it, and the default assumed definition of a value is broad enough that it allows for it, IME. I don't object to your definition, but can you please just tell everybody what…

> I think it makes perfect sense, but that's neither here nor there

Would you conflate a word with the piece of paper in which it's written?

Re: Arguments against JSON-driven development

#305

Earlier quoted context omitted.

> We don't have a name for what you call values, as they're either irrelevant, or nonexistant in most contexts, and barely mentioned. They do exist. Python has va... errr... the-thing-for-which-we-don't-yet-have-a-name: small enough numbers, special constants and object references. And they are relevant, because these are the things that you can bind to variables, pass to and return from functions, etc. If you think…

Why do you reference call-by-value? Call-by-value vs. call-by-reference (and the related value- and reference-type semantics) is entirely about the in-memory representation of parameters, and you have been very adamant that your definition of value does not depend on in-memory semantics.

I was comparing call-by-value with non-strict evaluation strategies like call-by-name and call-by-need.

Re: Arguments against JSON-driven development

#306
post #270

Earlier quoted context omitted.

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.

It's entirely possible to communicate other things while - first order - only stating uncontroversial facts. What, you don't think your shop is nice? You don't think it would be a shame if something happened to it?

Given that, it's also entirely possible for people to perceive other things as communicated in cases where there's maybe not the intent.

Post reply on HN