Earlier quoted context omitted.
But there's a difference between changing it once when you serialize/deserialize it, and changing it every time you try to access the key.
A single constant will fix that problem.
Or even just a search and replace...
Arguments against JSON-driven development
281–290 of 306 posts
Re: Arguments against JSON-driven development
#282Earlier quoted context omitted.
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
You are, of course, correct. I appologize, and will go to greater lengths to remain civil in threads in the future.
Re: Arguments against JSON-driven development
#283Earlier quoted context omitted.
From the official source: "JSON (JavaScript Object Notation) is a lightweight data-interchange format. " http://json.org/ It's nothing about pressing into service. This is the authoritative source.
That's the source that pressed it into service: JSON is exactly what it says it is: Javascript Object Notation. Specifically, it's a subset of javascript's, well, object notation. The point is, the syntax behind JSON was originally designed for a specific language, as a textual representation of that language's objects. It just happened to make a convenient serialization format.
Just to be technically correct, because that's the best way to be correct...
JSON isn't a strict subset of JS. JSON strings can contain literal line terminators. JS strings cannot.
Re: Arguments against JSON-driven development
#284Thankfully there isn't really JSON driven development as a methodology. Its just a bit of a crappy pattern (for many tasks) that far too many people use. Hopefully no one is advocating it as the way to develop software.
Re: Arguments against JSON-driven development
#285I'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 woul…
Still, if there's way too much looping logic strewn around the code, that's probably because the code lacks good abstractions for the most routine data access tasks in this code.
If the code used more objects, each data type would be packaged up with its own methods for looping over the data. For code that doesn't wrap every bit of data in a specialized type, you may find that a few small utility abstractions will clean up your code substantially.
The tradeoff is that you must import these functions in every module that needs to use them, since they aren't passed to your code with the object.
Re: Arguments against JSON-driven development
#286Earlier quoted context omitted.
> 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.
I got the terminology right. The term “value” means what I mean by it, not what qwerty means by it. Check TAPL, pages 34 and 57.
Re: Arguments against JSON-driven development
#287Earlier quoted context omitted.
There's a differance between being abstraction challenged and wishing to understand the abstraction. We don't have a name for what you call values, as they're either irrelevant, or nonexistant in most contexts, and barely mentioned. However, we can't call them values, as that name is taken. Most CBV languages call them atoms, but that doesn't fit because they aren't necessarily atomic. Let's try... Symbolic value? It…
> 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.
Re: Arguments against JSON-driven development
#288Earlier quoted context omitted.
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
You are, of course, correct. I appologize, and will go to greater lengths to remain civil in threads in the future.
We very much appreciate it. Thank you.
Re: Arguments against JSON-driven development
#289Earlier 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.
I agree that it's strange, but the discussion has gone badly, and it has something to do with how you engage people. That's what I mean by unintentional trolling.
Re: Arguments against JSON-driven development
#290Earlier quoted context omitted.
> 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.
I got the terminology right. The term “value” means what I mean by it, not what qwerty means by it. Check TAPL, pages 34 and 57.
I'm talking about "expectation".