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

261–270 of 306 posts

Re: Arguments against JSON-driven development

#261

Post by [deleted] »

catnaroek wrote: post #216
qwertyuiop924 wrote: post #214

Earlier quoted context omitted.

They are somewhat close in paradigm: They both favor declarativism, and have mathematical values. Given, they're pretty far apart in paradigm, but those are some strong similarities.

> declarativism I'm not familiar with that term. Could you give a rigorous definition? Anyway, after some googling, I found a very plausible definition that makes functional programming not a declarative paradigm: http://semantic-domain.blogspot.com/2013/07/what-declarative...

[deleted]

Re: Arguments against JSON-driven development

#262

Post by Retra »

catnaroek wrote: post #246
pdonis wrote: post #241

Earlier quoted context omitted.

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

>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 is inadequate to do anything, as you demand the whole universe be invariant in all aspects; such a thing is trivial and vacuous. And it surely is not the structure encoded in any usage of the term "identity", as that word has non-trivial structure.

Re: Arguments against JSON-driven development

#263

Post by catnaroek »

Retra wrote: post #262
catnaroek wrote: post #246

Earlier quoted context omitted.

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

>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 what invariants you care about to have a consistent notion of identity.

You're confusing “identity of indiscernibles” with “indiscernibility of identicals”.

And, obviously, you can't use the temporal properties of objects to determine whether their atemporal identities are equal.

> Yours is inadequate to do anything, as you demand the whole universe be invariant in all aspects; such a thing is trivial and vacuous.

Nope. It just requires you to distinguish between things that exist in time and things that exist independently of time.

Re: Arguments against JSON-driven development

#264

Post by [deleted] »

catnaroek wrote: post #104
dragonwriter wrote: post #100

Earlier quoted context omitted.

> In that case, you want values rather than objects. In dynamic OOP languages, value/object distinctions are often not exposed to the language user (they may actually exist in the underlying implementation, but from the PoV of the programmer using the language, there may be no discernible distinction between an "immutable object" and "value".) Conceptually (and ignoring the implementation details, which may have perf…

> Conceptually ... immutable objects are equivalent to values, anyhow. Nope. Since values don't reside in computer memory other than through their representations, the language implementation (compiler, runtime system, etc.) is free to apply optimizations such as: (0) Determine whether a value is represented more than once in memory, and eliminate the redundant representations. (1) Store multiple values in a single d…

[deleted]

Re: Arguments against JSON-driven development

#265

Post by Retra »

st3v3r wrote: post #213
niftich wrote: post #185

Earlier quoted context omitted.

You change your code. Loose coupling a nice goal to aim for, but at the end of the day, somewhere deep down inside the code, you have to tightly couple to actually get anything done. Where that transition occurs is entirely programmer's discretion.

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.

Re: Arguments against JSON-driven development

#266

Post by pdonis »

catnaroek wrote: post #247
pdonis wrote: post #243

Earlier quoted context omitted.

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

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.

Re: Arguments against JSON-driven development

#267

Post by pdonis »

catnaroek wrote: post #246
pdonis wrote: post #241

Earlier quoted context omitted.

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

> There's only one

Maybe to you. Not to me. And not, I suspect, to most of the programmers in this discussion.

> Python doesn't have this.

Sure it does:

  class NerfedInteger(object):
      
      def __init__(self, i):
          self.__i = i
      
      def __repr__(self):
          return "".format(self.__i)
      
      def __str__(self):
          return str(self.__i)
      
      @property
      def i(self):
          return self.__i

Re: Arguments against JSON-driven development

#268

Post by catnaroek »

pdonis wrote: post #266
catnaroek wrote: post #247

Earlier quoted context omitted.

> "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…

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 where a redex is reduced only when its right-hand side has already been reduced to a value - a term that has finished computing and cannot be reduced any further.” (Types and Programming Languages, p. 57)

For the definition of redex, see: https://en.wikipedia.org/wiki/Reduction_strategy_(code_optim...

On objects:

(0) “In computer science, an object can be a variable, a data structure, or a function or a method, and as such, is a location in memory having a value and possibly referenced by an identifier.” ( https://en.wikipedia.org/wiki/Object_(computer_science) ) In some languages, object states aren't values, though.

(1) “object: a cell (unless otherwise explicitly stated)” (p. 325), “cell: a number of contiguous memory fields forming a single logical structure” (Garbage Collection: Algorithms for Automatic Dynamic Memory Management, p. 322)

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

Compiler authors take advantage of the notion of value all the time. For example, If two expressions are guaranteed to evaluate to the same value, a compiler may emit code that evaluates the expression once, then reuses the result twice.

---

Sorry, I can't reply to you directly because I'm “submitting too fast”, but:

These blog posts show how to do equational reasoning on Haskell programs. (Technically, the subset of Haskell that doesn't contain nonproductive infinite loops.)

http://www.haskellforall.com/2013/12/equational-reasoning.ht...

http://www.haskellforall.com/2014/07/equational-reasoning-at...

http://www.haskellforall.com/2013/10/manual-proofs-for-pipes...

Although Haskell is particularly well suited for using equational reasoning, it can also be used in other languages, provided your program primarily manipulates values, rather than objects.

Re: Arguments against JSON-driven development

#269

Post by catnaroek »

pdonis wrote: post #267
catnaroek wrote: post #246

Earlier quoted context omitted.

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

> There's only one Maybe to you. Not to me. And not, I suspect, to most of the programmers in this discussion. > Python doesn't have this. Sure it does: class NerfedInteger(object): def __init__(self, i): self.__i = i def __repr__(self): return " ".format(self.__i) def __str__(self): return str(self.__i) @property def i(self): return self.__i

What you've implemented isn't an abstract type. You can inspect the internal representation anytime, distinguishing between things that were meant never to be distinguished.

Re: Arguments against JSON-driven development

#270

Post by dang »

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.

Post reply on HN