Arguments against JSON-driven development • Hacker News Board

Re: Arguments against JSON-driven development

#231

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

pdonis wrote: post #229

catnaroek wrote: post #226

Earlier quoted context omitted.

> Which says absolutely nothing about how I can write programs using them, I can write a program that treats all Python objects identically, by simply doing nothing. That doesn't make all Python objects actually identical. > We're talking about programming here, not philosophy. Programming is applied logic, which is a branch of philosophy.

> 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 Western logic. It's like saying I made a machine that violates gravity - it's literally impossible! Python just doesn't have compound values.

Re: Arguments against JSON-driven development

#232

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

catnaroek wrote: post #211

pdonis wrote: post #209

Earlier quoted context omitted.

> It violates the indiscernibility of identicals, which is one of the cornerstones of Western logic. Oh, please. Python isn't violating any principles of Western logic. It's only violating your idiosyncratic insistence that there can only be one in-memory representation of any immutable value. Python does this for some types but not for others. Yet computers manage to run Python just fine, Western logic notwithstandi…

> It's only violating your idiosyncratic insistence that there can only be one in-memory representation of any immutable value. I never said this! There can be multiple representations of the same value. For example, the same ordered set may be represented as two distinct red-black trees, balanced differently. Values are different from their memory representations. Different memory representations of the same value a…

> > It's only violating your idiosyncratic insistence that there can only be one in-memory representation of any immutable value.

> I never said this!

The standards you have set require either

(1) That there is only one in-memory representation of a given value, or

(2) The language has no facilities that allow you to inquire about the in-memory representation used by a particular reference to a value.

Re: Arguments against JSON-driven development

#233

Post by Bjartr » Thu, Aug 25, 2016, 10:23 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.

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?

Re: Arguments against JSON-driven development

#234

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

sheepmullet wrote: post #218

jowiar wrote: post #138

Earlier quoted context omitted.

Lists are lists, and I have no issues there. It's dicts as objects (often nested) where things to get hairy. I often see folks end up relying on internal implementation details of other libraries, or other data sources, and things can subtly break (or explode in a ball of fire). The more systems I've built, the more I've wanted to have very well-defined seams between "inside" and "outside" -- well-defined interfaces…

> I often see folks end up relying on internal implementation details of other libraries, or other data sources, and things can subtly break I'm not sure how you can get around this as a consumer of a service? How do you know what is an internal implementation detail? Why are they exposing implementation details? As a producer of a service there are lots of techniques. E.g. - Only expose data and provide a spec for t…

As a consumer, you're not going to get around it. But what you can do is quarantine it to a specific area within your application. I find dependencies to be a very natural place to divide up an application -- at the very least, to consider "What would have to change if I ripped this thing out entirely?". "What are the methods I would need to implement?", etc, and writing a translation layer implementing that interface.

As a hypothetical, let's say you needed to implement a binary persistence layer in your application. Rather than interacting with S3 in 10 different places, you define a "BlobStore" interface with the methods that you need, code against that interface, then implement an S3BlobStore that handles the calls to Amazon using whatever library necessary.

Re: Arguments against JSON-driven development

#235

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

jerf wrote: post #133

czardoz wrote: post #125

Earlier quoted context omitted.

> In strongly-typed languages there's a stronger focus on parsing the JSON instead I think you mean _statically_ typed languages here. Python is a strongly typed language.

The definition of "strongly-typed" that Python conforms to is a useless one, because very few weakly-typed languages exist anymore, and even those are only very, very partially "weakly typed" by having operators that are defined to do automatic coercion, generally only between strings and numbers, which isn't even the way the original "weakly typed" was meant. The only truly "weakly typed" language I know of that is…

I guess you need a term for "typing of moderate strength"

Re: Arguments against JSON-driven development

#236

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

dragonwriter wrote: post #232

catnaroek wrote: post #211

Earlier quoted context omitted.

> It's only violating your idiosyncratic insistence that there can only be one in-memory representation of any immutable value. I never said this! There can be multiple representations of the same value. For example, the same ordered set may be represented as two distinct red-black trees, balanced differently. Values are different from their memory representations. Different memory representations of the same value a…

> > It's only violating your idiosyncratic insistence that there can only be one in-memory representation of any immutable value. > I never said this! The standards you have set require either (1) That there is only one in-memory representation of a given value, or (2) The language has no facilities that allow you to inquire about the in-memory representation used by a particular reference to a value.

> That there is only one in-memory representation of a given value, or

No.

> The language has no facilities that allow you to inquire about the in-memory representation used by a particular reference to a value.

s/reference to// , otherwise yes.

Re: Arguments against JSON-driven development

#237

Post by [deleted] » Thu, Aug 25, 2016, 10:26 PM UTC

dragonwriter wrote: post #232

catnaroek wrote: post #211

Earlier quoted context omitted.

> It's only violating your idiosyncratic insistence that there can only be one in-memory representation of any immutable value. I never said this! There can be multiple representations of the same value. For example, the same ordered set may be represented as two distinct red-black trees, balanced differently. Values are different from their memory representations. Different memory representations of the same value a…

> > It's only violating your idiosyncratic insistence that there can only be one in-memory representation of any immutable value. > I never said this! The standards you have set require either (1) That there is only one in-memory representation of a given value, or (2) The language has no facilities that allow you to inquire about the in-memory representation used by a particular reference to a value.

[deleted]

Re: Arguments against JSON-driven development

#238

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

catnaroek wrote: post #225

pdonis wrote: post #223

Earlier quoted context omitted.

> I never said this! As Rhett Butler said to Scarlett O'Hara, you gave a very good imitation. > Different memory representations of the same value are okay. Branching on the difference is not. Branching on a difference other than a difference in logical identity, if you are intending to test for logical identity, is obviously an error. The fix for that in Python is simple: if you want to test for logical identity, us…

> Branching on a difference other than a difference in logical identity, if you're interested in a difference other than a difference in logical identity, is perfectly reasonable. It's unreasonable to have a finer-grained distinction than logical identity. If two things are the same, they are the same. If they are not, well, they are not. Again, tautologies! > That doesn't mean the Python developers are violating Wes…

> 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 reasoning with Python programs. 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 mutable objects). And of course this wouldn't just apply to Python; the general distinction here could be drawn, in principle, in any language. Or even independently of choosing a language.

So I have another tradeoff here: I can use mutable objects, which can make programs easier to write, but then I can't reason rigorously about them; or I can restrict myself to immutable objects (which means that any time I would have mutated an object writing programs the other way, I instead have to construct a new immutable object with the same logical properties that the mutated object would have had), which makes programs harder to write, but allows me to reason rigorously about them.

Can you show me any real-world examples where using the latter programming style has paid dividends?

Re: Arguments against JSON-driven development

#239

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

catnaroek wrote: post #230

dragonwriter wrote: post #228

Earlier quoted context omitted.

> By definition identity checking is the finest-grained distinction you can make between things. Yes, but there are different identities. "is" implements storage identity checking between python objects (a term broader than the sense in which you use "objects", which includes both what you call "objects" and representations of values). Logical identity checking between Python values (as well as object equivalence, bu…

> 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 is doing.)

But the fact that doing that is possible in Python does not change the fact that Python does, in fact, support values (including compound values) with value-oriented semantics.

> If it's undefined, then how come I can query it?

The relation between physical identity of the storage representations and logical identity of the values they represent is undefined by the language specification.

At runtime, every representation of a value has some storage identity, and you can query the relationship between that and the storage identity of another representation of a value. But the answer you get has no guaranteed correlation to whether the values represented by those representations are the same value (which you can also query.)

Re: Arguments against JSON-driven development

#240

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

pdonis wrote: post #238

catnaroek wrote: post #225

Earlier quoted context omitted.

> Branching on a difference other than a difference in logical identity, if you're interested in a difference other than a difference in logical identity, is perfectly reasonable. It's unreasonable to have a finer-grained distinction than logical identity. If two things are the same, they are the same. If they are not, well, they are not. Again, tautologies! > That doesn't mean the Python developers are violating Wes…

> 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 mutable objects).

You can in principle use equational reasoning on programs that manipulate mutable objects. What you can't do is treat two distinct objects as equal. But, of course, in practice, you can do whatever you want. Whether your reasoning is sound is a-whole-nother matter.

> I instead have to construct a new immutable object with the same logical properties that the mutated object would have had), which makes programs harder to write, but allows me to reason rigorously about them.

No, this would be wrong. You can't use equational reasoning on objects themselves. You can only use equational reasoning on values. The value itself might be a program that manipulates objects, but you can't equate two distinct objects.