Arguments against JSON-driven development • Hacker News Board

Re: Arguments against JSON-driven development

#241

Post by pdonis » Thu, Aug 25, 2016, 10:40 PM UTC

catnaroek wrote: post #231

pdonis wrote: post #229

Earlier quoted context omitted.

> I can write a program that treats all Python objects identically, by simply doing nothing. That doesn't make all Python objects actually identical. Yes, you can. Thank you for proving my point that Python programs don't have to use your definition of identity. But that's a silly example. Here's an example that's not silly: in an earlier discussion you said dictionary keys have to be values--which would imply that d…

> But two distinct Python tuples (1, 2, 3), which are not identical by your definition, do behave as identical keys in a Python dictionary. The numbers 2 and 4 behave identically when passed to a function that tests whether its argument is an even number. Are 2 and 4 identical now? > To you, it appears to mean that Python is violating Western logic. This is the third time I'm saying I never said Python is violating W…

> The numbers 2 and 4 behave identically when passed to a function that tests whether its argument is an even number. Are 2 and 4 identical now?

They are with respect to the even/odd property. So if that's the property I'm interested in, they're identical. They might not be if I'm interested in some other property.

In other words, as dragonwriter has already pointed out, there is more than one concept of identity.

Re: Arguments against JSON-driven development

#242

Post by dragonwriter » Thu, Aug 25, 2016, 10:43 PM UTC

pdonis wrote: post #207

dragonwriter wrote: post #187

Earlier quoted context omitted.

Python provides a value abstraction that includes (but is not distinct for) compound values. It also provides an independent mechanism for examining physical (rather than logical) identity -- which is object identity; for all compound values (and all but a very narrow subset of simple values) there is no guarantee that the logical identity of values is equivalent to physical/object identity. I don't see that this mak…

> I'd probably be happier if Python had (whether it was "is" or something else) a clean logical identity test operator. Isn't that what == is?

> > I'd probably be happier if Python had (whether it was "is" or something else) a clean logical identity test operator.

> Isn't that what == is?

Not really.

"is" is logical identity for mutable objects (where logical and storage identity are equivalent), and "==" is logical identity for values (where that is equivalent to structural equivalence) but (only) structural equivalence for mutable objects.

What I was thinking of is an operator that would be logical identity for both values and mutable objects.

Re: Arguments against JSON-driven development

#243

Post by pdonis » Thu, Aug 25, 2016, 10:46 PM UTC

catnaroek wrote: post #240

pdonis wrote: post #238

Earlier quoted context omitted.

> It's unreasonable to have a finer-grained distinction than logical identity. Maybe to you. Not to me. And not, I suspect, to most of the other programmers in this discussion. > The definition of compound value is simple Your definition. Why should I care? See below. > if you want to use equational reasoning, you need compound values. Ok, so this would mean that, according to you, it is impossible to use equational…

> Ok, so this would mean that, according to you, it is impossible to use equational reasoning with Python programs. You can use equational reasoning on the values that Python actually gives you: small numbers, special constants and object references. > Whereas, according to me, it is only impossible to do this with Python programs that use mutable objects (where "mutable" here includes tuples whose slots point to mut…

> You can't use equational reasoning on objects themselves.

I didn't say you could. I said you could use equational reasoning on programs that only manipulate immutable objects. "Immutable" means that the object's value can never change, so you can substitute the object's value for the object itself everywhere it appears in the program. Then you can apply equational reasoning to the values so obtained.

In the particular case I described, you would end up using equational reasoning on the value transformation implemented by the code that constructs the new immutable object. You would obtain that transformation, as above, by substituting object values for objects in the syntactic statement of the code.

> You can in principle use equational reasoning on programs that manipulate mutable objects.

How do you reason using an object's value if that value can change?

Re: Arguments against JSON-driven development

#244

Post by keithnz » Thu, Aug 25, 2016, 10:49 PM UTC

Lots of religion in this thread!

I think the point is, if json is your data exchange format it could be bad if you let that structure propagate into your application.

so in general you should prefer :-

json =>

over json =>

Different languages are going to have different mechanisms. Some languages you may abstract from json completely, some languages may natively deal with json, and your persistence layer may deal with json also.

So what you need is a well considered design that takes advantage of your chosen languages philosophy / mechanics, whatever that may be. There is no one way to design anything. The thing to avoid is - not working out how to structure your code to make things easy / appropriate to the task at hand. That path leads to messy code.

Re: Arguments against JSON-driven development

#245

Post by catnaroek » Thu, Aug 25, 2016, 10:50 PM UTC

Bjartr wrote: post #233

catnaroek wrote: post #114

Earlier 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.

Why do you not mind being poorly understood? The goal of effective communication is to have others understand you. Since you're not trying to communicate effectively, what exactly is it that you think you are doing?

> Why do you not mind being poorly understood?

What I said I didn't mind is the “ire you are experiencing”. It somewhat saddens me that programmers, supposedly logical thinkers, can't see the distinction between a value and an object.

> Since you're not trying to communicate effectively, what exactly is it that you think you are doing?

I'm pointing to the distinction between values and objects pretty clearly:

(0) Objects exist in memory. Values exist in the language's semantics, not in computer memory, but representations of values exist in computer memory. Furthermore, objects exist in memory exactly once, but a value may be represented in memory any number of times.

(1) It doesn't make sense to distinguish between representations of the same value. If a program treats two memory blobs differently, their contents represent different values, period. (The converse is not true, of course.)

(2) The language implementation has absolute freedom to represent values as it wishes, as long as (1) isn't violated.

But this isn't the first time I've said all of this in this thread.

Re: Arguments against JSON-driven development

#246

Post by catnaroek » Thu, Aug 25, 2016, 10:52 PM UTC

pdonis wrote: post #241

catnaroek wrote: post #231

Earlier quoted context omitted.

> But two distinct Python tuples (1, 2, 3), which are not identical by your definition, do behave as identical keys in a Python dictionary. The numbers 2 and 4 behave identically when passed to a function that tests whether its argument is an even number. Are 2 and 4 identical now? > To you, it appears to mean that Python is violating Western logic. This is the third time I'm saying I never said Python is violating W…

> The numbers 2 and 4 behave identically when passed to a function that tests whether its argument is an even number. Are 2 and 4 identical now? They are with respect to the even/odd property. So if that's the property I'm interested in, they're identical. They might not be if I'm interested in some other property. In other words, as dragonwriter has already pointed out, there is more than one concept of identity.

> there is more than one concept of identity.

There's only one: Two entities are equal if nothing can distinguish them. This is the “identity of indiscernibles”.

In a language with abstract data types, such as Standard ML, you could define a new type whose internal representation is an integer, but which provides no operations that would distinguish between two even or two odd numbers. But Python doesn't have this.

Re: Arguments against JSON-driven development

#247

Post by catnaroek » Thu, Aug 25, 2016, 10:53 PM UTC

pdonis wrote: post #243

catnaroek wrote: post #240

Earlier quoted context omitted.

> Ok, so this would mean that, according to you, it is impossible to use equational reasoning with Python programs. You can use equational reasoning on the values that Python actually gives you: small numbers, special constants and object references. > Whereas, according to me, it is only impossible to do this with Python programs that use mutable objects (where "mutable" here includes tuples whose slots point to mut…

> You can't use equational reasoning on objects themselves. I didn't say you could. I said you could use equational reasoning on programs that only manipulate immutable objects. "Immutable" means that the object's value can never change, so you can substitute the object's value for the object itself everywhere it appears in the program. Then you can apply equational reasoning to the values so obtained. In the particu…

> "Immutable" means that the object's value can never change, so you can substitute the object's value for the object itself everywhere it appears in the program.

No, you can't. Immutable objects still have physical identities. If you want to do equational reasoning, you need to get a hold of the value itself.

> How do you reason using an object's value if that value can change?

Objects don't have “values”, they have “states”. And I said you can reason about programs that manipulate objects, not about the states of these objects. (Though maybe in a few special cases you can do the latter too.)

Re: Arguments against JSON-driven development

#248

Post by catnaroek » Thu, Aug 25, 2016, 10:56 PM UTC

dragonwriter wrote: post #239

catnaroek wrote: post #230

Earlier quoted context omitted.

> which includes both what you call "objects" and representations of values This is exactly what I'm saying is wrong: branching on the representations of values. > For most python value representations, the relationship between storage identity of the representation and logical identity of the value is undefined . If it's undefined, then how come I can query it?

> This is exactly what I'm saying is wrong: branching on the representations of values. Well, yes, its wrong in that (except in the cases where value identity and representation storage identity are guaranteed to be equivalent) you generally shouldn't do it (the exception being if you are building code to do something oomphaloskeptic where the purpose of code is to answer questions about what its own implementation i…

> Well, yes, its wrong in that (except in the cases where value identity and representation storage identity are guaranteed to be equivalent) you generally shouldn't do it

A language's semantics doesn't tell me what I “should” do. It tells me what I can do, and what other people who write code that interacts with mine can do.

> At runtime, every representation of a value has some storage identity

Not in the semantics of the source language. Value representations are purely an implementation artifact.

Re: Arguments against JSON-driven development

#249

Post by oldmanjay » Thu, Aug 25, 2016, 10:57 PM UTC

dspillett wrote: post #123

recursive wrote: post #92

Earlier 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.

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.

Re: Arguments against JSON-driven development

#250

Post by Goladus » Thu, Aug 25, 2016, 11:18 PM UTC

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…

This right here is the correct approach. Serialisation formats should be serialisation formats, ... application data should be application data.

True, although the OP seems to be advocating having your app pretty much ignore serialization altogether in favor of object-oriented design. In particular the author objects to use of dictionaries and lists instead of objects.

It is true that if you're designing an application with a json api in mind, you're likely to stick with the data structures that are easiest to serialize.

Personally, I started writing programs that way before json became so common. I did it simply to take full advantage of the native data structures and to avoid prematurely confining myself into an object hierarchy that wasn't a good fit for the problem domain. It also winds up making code more generic and easier to rewrite in a different language if necessary (for example, moving server-side code to client javascript).