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

201–210 of 306 posts

Re: Arguments against JSON-driven development

#201

Post by catnaroek »

sevensor wrote: post #198
catnaroek wrote: post #190

Earlier quoted context omitted.

This simply doesn't make sense. It violates the indiscernibility of identicals, which is one of the cornerstones of Western logic. I can accept different opinions on several matters (e.g., the extent to which using objects is a good idea), but throwing logic out of the window is just too much.

I would argue that, because Python requires its users to reason about storage and interpreter state, we shouldn't consider (a,b,c) and (a,b,c) identical under is unless they're aliases for the same structure in memory. I'm not sure I understand dragonwriter's idea for a third equality operator, however. Isn't == adequate for that purpose? By the way, I'd like to thank both catnaroek and dragonwriter for an excellent…

> we shouldn't consider (a,b,c) and (a,b,c) identical under is unless they're aliases for the same structure in memory.

Which is the entirety of my point.

Re: Arguments against JSON-driven development

#202

Post by Terr_ »

dragonwriter wrote: post #117
catnaroek wrote: post #29

Earlier quoted context omitted.

All you need to do is use the `is` operator to see how even tuples (named or otherwise) are objects, not values.

> All you need to do is use the `is` operator to see how even tuples (named or otherwise) are objects, not values. That is not language feature of Python but an implementation detail. Python implementations are permitted (but not required) to intern any immutable value (which tuples, contrary to your description, are ), and "is" is a mechanism for revealing what the implementation has done . You seem to be equivocati…

That sounds like basically the same newbie-pitfall that exists with code-literal Strings in Java: Just because a certain comparison operation can work in some circumstances (where the underlying platform makes an optimization) doesn't mean is a safe/sane choice in general.

Re: Arguments against JSON-driven development

#203

Post by kazagistar »

aeruder wrote: post #22
lmm wrote: post #11

The main reason this happens in Python is that creating actual datatypes is incredibly clunky (by Python standards) because of the tedious "def __init__(self, x): self.x = x". The solution here is to have a very lightweight syntax for more specific types, e.g. Scala's "case class". I'd also argue for using thrift, protobuf or even WS-* to put a little more strong typing into what goes over the network. Such schemata…

An article about the "attrs" library was posted here a couple weeks ago. Really highlighted the tedium of Python objects while offering a neat solution. https://glyph.twistedmatrix.com/2016/08/attrs.html Regarding protobuf, I'm a bit disappointed with the direction of version 3. Fields can no longer be marked as required - everything is optional; i.e. almost every protobuf needs to be wrapped with some sort of valida…

How, if at all, does attrs interact with serialization and deserialization?

Re: Arguments against JSON-driven development

#205

Post by jholman »

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…

Here's a plausible definition: Strongly typed languages disallow programs to escape the type system (e.g. put an integer into into memory, then treat it as a float, or vice versa, as in the famous Quake fast-inverse-sqrt hack.). Oh, look, Python is strongly-typed and C is weakly-typed.

Note that I do not endorse using "strongly-typed" to mean this definition, or any other. There are no useful definitions of this phrase, don't use it, except when correcting people.

Re: Arguments against JSON-driven development

#206

Post by iamleppert »

Is the OP familiar with Object.keys()?

You don't have to hard-code explicit dot notation into your code when you're processing JSON or any other hierarchical object serialization format, which is what JSON is.

If you want to make your code more robust, you should process the structure of the JSON document and infer meaning from its keys based upon your position in the tree and of the values of the key names that are meaningful to your application.

This makes it possible to accept any kind of JSON, even if the original format changes, and you won't get uncaught exceptions and your application can decide what to do in a more graceful manner.

You should also centralize the code that is responsible for serializing and deserializing your JSON wire format and creating objects. There's no reason to have ad-hoc code in each object constructor like his example. A good example of such a thing is dnode https://www.npmjs.com/package/dnode. It handles all the JSON abstraction (in this case for RPC) and you don't even need to worry about the JSON ever again.

This has nothing to do with JSON and more to do with poor design and tight coupling of interfaces.

Re: Arguments against JSON-driven development

#207

Post by pdonis »

dragonwriter wrote: post #187
catnaroek wrote: post #180

Earlier quoted context omitted.

So, which is the case? (0) Python provides a compound value abstraction, but this abstraction leaks, because we can distinguish between multiple representations of the same compound value. (1) Python doesn't provide a compound value abstraction. With a few exceptions (e.g., garbage collection, which pretends memory is infinite, even though it's not), I tend not to consider so-called “leaky abstractions” actual abstra…

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?

Re: Arguments against JSON-driven development

#208

Post by catnaroek »

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?

Somehow Python lets you distinguish “logically identical” things, though.

Re: Arguments against JSON-driven development

#209

Post by pdonis »

catnaroek wrote: post #190
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…

This simply doesn't make sense. It violates the indiscernibility of identicals, which is one of the cornerstones of Western logic. I can accept different opinions on several matters (e.g., the extent to which using objects is a good idea), but throwing logic out of the window is just too much.

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

If you want to argue that Python ought to change its implementation to guarantee that, for example, any two references to the tuple (1, 2, 3) must refer to the same in-memory representation (so the 'is' operator would always return True), because that would save memory, or make the runtime faster, or whatever, that's fine. Then we can talk about the tradeoffs involved, such as increasing complexity in the interpreter code. But trying to claim that Python is violating "one of the cornerstones of Western logic" is just too much.

Re: Arguments against JSON-driven development

#210

Post by vonmoltke »

solatic wrote: post #118
Cthulhu_ wrote: post #7

Earlier quoted context omitted.

When using parsers like e.g. Jackson or Gson for Java, this process is completely transparent and does not require any active thought from the developer - well, maybe if there's very specific formats that don't map 1:1 with the class that should be instantiated or generated from the json object. It's a bit more tricky in JS, both client-side and node. You can't work with the json string there, but after that you work…

Automated serialization is the devil. Gson and Jackson require you to write EJB-style objects to get automatic serialization - default constructors, with getters and setters for each field - to achieve automatic serialization. The problem with this approach is that you've completely abdicated the power of the type system to ensure that your objects are valid. What happens if a field is missing from the JSON? Well, th…

> Automated serialization is the devil. Gson and Jackson require you to write EJB-style objects to get automatic serialization - default constructors, with getters and setters for each field - to achieve automatic serialization.

Gson does not require this. The following class will serialize and deserialze fine with Gson:

    class Example {
      private final int foo;
      private final String bar;
    
      private Example(final int foo, final String bar) {
        this.foo = foo;
        this.bar = bar;
      }
    }
More complicated cases will require custom serializers and deserializers, but any class that defines only basic data types (including collections) works just fine.
Post reply on HN