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

171–180 of 306 posts

Re: Arguments against JSON-driven development

#171

Post by qwertyuiop924 »

kazinator wrote: post #107
qwertyuiop924 wrote: post #45

Earlier quoted context omitted.

Part of the problem is that JSON and Sexprs aren't that they AREN'T serialization formats. They've been pressed into service as such, but they are actually notation for datastructures: In python, it may not be idiomatic to crawl dicts like this, but in JS, those aren't dicts, they're objects. If they've been de-serialized to some degree, they may even have their own methods. By the same token, in Lisp, Sexprs aren't…

A notation for a data structure is a serialization format. > In Lisp, that Sexpr will be crawled for data, or maybe even executed. A s-expression cannot be executed; it's just text. The object which it denotes can be walked or executed via eval. Before that happens, the s-expression must be converted to that object. In other words, deserialized by the reader.

Good point kaz. I meant that the notation signifies a specific set of general data structures, unlike XML, which doesn't specify the data-structure used in memory afaik, only the actual tree structure of the data itself.

Re: Arguments against JSON-driven development

#172

Post by dragonwriter »

catnaroek wrote: post #169
qwertyuiop924 wrote: post #167

Earlier quoted context omitted.

I'm not an object oriented programmer. The word "value" is used in many contexts. Functions take values and return the same, sometimes mutating the values they took. rvalues, which are almost anything, are assigned to lvalues, which are locations. You can probably think of more. OTOH, your definition of object is almost entirely unique outside FP, AFAIK.

> assigned to lvalues, which are locations. lvalues aren't values.

> lvalues aren't values.

lvalues are values in the same way that object references (not objects themselves) are values; perhaps more precisely, lvalues are values the same way that pointer values are values.

Re: Arguments against JSON-driven development

#173

Post by ohyes »

kazinator wrote: post #107
qwertyuiop924 wrote: post #45

Earlier quoted context omitted.

Part of the problem is that JSON and Sexprs aren't that they AREN'T serialization formats. They've been pressed into service as such, but they are actually notation for datastructures: In python, it may not be idiomatic to crawl dicts like this, but in JS, those aren't dicts, they're objects. If they've been de-serialized to some degree, they may even have their own methods. By the same token, in Lisp, Sexprs aren't…

A notation for a data structure is a serialization format. > In Lisp, that Sexpr will be crawled for data, or maybe even executed. A s-expression cannot be executed; it's just text. The object which it denotes can be walked or executed via eval. Before that happens, the s-expression must be converted to that object. In other words, deserialized by the reader.

In that s-expressions are a notation for computation, they can be executed by an interpreter. This is what we refer to as execution. Even assembly is like this, there's no other reasonable way for it to work right now.

This feels like you're hairsplitting to no obvious benefit other than increasing confusion. I could as easily say "mathematical notation isn't math it's just text, you can't evaluate '1 + 2' without a human being because otherwise those are just marks on the page otherwise." This is true(ish) (with the correct escaping), but it's difficult for me to see how it's relevant to the discussion? We could imagine the situation where I've created the Texpr, which has slightly different notation but the same properties. I don't know that we would necessarily classify it differently or treat it differently.

This leads to the alternate conclusion that maybe the s-expression is the underlying set of objects in the interpreter/compiler. (S-expressions are a special type of linked list, in that case). This rings true(er) to me, because of the way that we talk about s-expression manipulation in lisps. We most certainly are not using string operations to generate them. In which case the thing with the many parenthesis is merely standard lisp syntax, not s-expressions. This is further justified by the existence of different syntax in Dylan or Clojure, and availability of reader macro manipulation as its own entity.

Tldr; it most certainly is not text! Nor can it be executed.

Re: Arguments against JSON-driven development

#174

Post by _skel »

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…

You can use whatever definition you want in your own head, but you cannot expect anyone else to accept it.

Furthermore, one of the most popular languages in use today is weakly typed: JavaScript!

Re: Arguments against JSON-driven development

#175

Post by moosey »

This is what keeps dragging me back to moose & perl5. You describe the attributes of a class, the constructor for that class is created for you, and you can pass in hashes and it will automatically instantiate (and fail if the rules you have set for attributes are not met).

I've found that you can kinda sorta do the same with other languages (python/ruby/javascript) by writing static factory builders inside the class that do this checking for you and raise an exception or return an object for you, but it still doesn't compare to me to Moose/Moose::Util::TypeConstraints::coerce/subtype and attributes with the coerce option set. It makes it so easy to coerce a deep json object into a deep class structure.

I always try to hunt down things that are similar in other languages (python allows named arguments from a dict, IIRC, and that allows similar things, but you still have to write the constructor yourself), but I've yet to find something that makes it as simple.

Re: Arguments against JSON-driven development

#176

Post by qwertyuiop924 »

recursive wrote: post #92
qwertyuiop924 wrote: post #45

Earlier quoted context omitted.

Part of the problem is that JSON and Sexprs aren't that they AREN'T serialization formats. They've been pressed into service as such, but they are actually notation for datastructures: In python, it may not be idiomatic to crawl dicts like this, but in JS, those aren't dicts, they're objects. If they've been de-serialized to some degree, they may even have their own methods. By the same token, in Lisp, Sexprs aren't…

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.

Re: Arguments against JSON-driven development

#177

Post by catnaroek »

dragonwriter wrote: post #172
catnaroek wrote: post #169

Earlier quoted context omitted.

> assigned to lvalues, which are locations. lvalues aren't values.

> lvalues aren't values. lvalues are values in the same way that object references (not objects themselves) are values; perhaps more precisely, lvalues are values the same way that pointer values are values.

An object reference is totally an rvalue: you can't mutate the object reference, only the object it refers to. AFAICT, lvalues are more akin to objects themselves, in that they can be mutated.

Re: Arguments against JSON-driven development

#178

Post by sidlls »

mattnewton wrote: post #62
sidlls wrote: post #51

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

With the added benefit that you can reuse these functions for new data shapes more often than I expected when switching to this style.

And better testability.

Re: Arguments against JSON-driven development

#179

Post by st3v3r »

clifanatic wrote: post #48
Cthulhu_ wrote: post #8

I disagree with the anemic object argument. 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. A large portion of back-end services are CRUD and data wrangling operations anyway - as in, convert data format A to data format B (which I guess could be a constructor or factory method if you're comfortable with having the conversion logic in a data cla…

> If an object is just there to store data and no behavior Then why do you have it at all?

... to store data?

Re: Arguments against JSON-driven development

#180

Post by catnaroek »

dragonwriter wrote: post #164
catnaroek wrote: post #141

Earlier quoted context omitted.

As things stand now, the main reason why Python can't do it is because it could potentially break programs.

> As things stand now, the main reason why Python can't do it is because it could potentially break programs. Since the documented behavior of Python is compatible with what is suggested as a change, any program that relies on the behavior not reflecting as described in the "change" is asking to be broken (and quite possibly already broken across different implementations -- including different versions of the same i…

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 abstractions, but if you know of a good reason to do otherwise, please tell me.

Post reply on HN