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

191–200 of 306 posts

Re: Arguments against JSON-driven development

#191

Post by tantalor »

jbattle wrote: post #161
tantalor wrote: post #21

Earlier quoted context omitted.

Especially true if your business objects are generated code, e.g., protocol buffers. Combining business logic with business objects is a mistake. That's a textbook example of tight coupling.

> Combining business logic with business objects is a mistake. That's a textbook example of tight coupling. Isn't that a textbook example of object oriented programming? Whether OOP is a mistake in and of itself is another question ...

Textbook examples of object oriented programming are notoriously bad. Stuff like,

  Dog dog = new Dog("Spot");
  dog.bark();
These are toy examples meant to quickly introduce the mechanics of objects, not teach good software engineering patterns.

Re: Arguments against JSON-driven development

#192

Post by kazinator »

ohyes wrote: post #173
kazinator wrote: post #107

Earlier quoted context omitted.

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…

> mathematical notation isn't math it's just text

That is correct. It's just text which talks about concepts that don't have text, like transcendental numbers, infinities, infinitesimals and so on.

There are functions in mathematics that can't be written down in symbols at all, like the integrals of certain functions (which themselves can be written down).

Math text has some useful properties in that certain transformations you can think of as typographical (manipulations of the text) actually preserve semantic properties in a useful way. So for instance addition commutes, semantically; and in the text, this lets us swap the left piece of text for the right one, around the plus sign.

There can be a very close correspondence between typography and semantics (like in Douglas Hofstadter's "TNT": typographical number theory, which he uses to explain Gödel's incompleteness theorem).

> This leads to the alternate conclusion that maybe the s-expression is the underlying set of objects in the interpreter/compiler.

I assure you that it isn't; not in any main-stream Lisp interpreter or compiler.

(Where by "main-stream Lisp interpreter or compiler", I intend to rule out cute hacks like this:

https://news.ycombinator.com/item?id=7956246 )

Re: Arguments against JSON-driven development

#193

Post by tantalor »

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…

Required fields are bad; don't use them.

You should be very careful about marking fields as required. If at some point you wish to stop writing or sending a required field, it will be problematic to change the field to an optional field – old readers will consider messages without this field to be incomplete and may reject or drop them unintentionally. You should consider writing application-specific custom validation routines for your buffers instead.

https://developers.google.com/protocol-buffers/docs/proto#sp...

Re: Arguments against JSON-driven development

#194

Post by lmm »

tantalor wrote: post #193
aeruder wrote: post #22

Earlier quoted context omitted.

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…

Required fields are bad; don't use them. You should be very careful about marking fields as required. If at some point you wish to stop writing or sending a required field, it will be problematic to change the field to an optional field – old readers will consider messages without this field to be incomplete and may reject or drop them unintentionally. You should consider writing application-specific custom validatio…

They're a tradeoff. Sometimes you really are confident enough that this attribute will be required forever that the saving of not having to write custom validation is worth it.

Re: Arguments against JSON-driven development

#195

Post by dasmoth »

michaelfeathers wrote: post #25

This is space that the Clojure community has already visited.

And, somewhat, tamed using tools like get-in and update-in.

Clojure.spec is looking promising as a route for making this general style more robust without losing the ease and flexibility.

Re: Arguments against JSON-driven development

#196

Post by qwertyuiop924 »

catnaroek wrote: post #168
qwertyuiop924 wrote: post #166

Earlier quoted context omitted.

"Close," not "is."

There's very little in common, beyond the notions of mathematical variable and value. Syntactically, a functional program is an expression, but a logic program is a proposition. Operationally, functional programs run already constructed proofs, but logic programs search for proofs. Pragmatically, transcribing a logic program into a functional language or vice versa is difficult without effectively writing an interpre…

Don't mock me. And yes, I did mean the notion of mathematical value and variable. That's one of the core tenets of both.

Re: Arguments against JSON-driven development

#197

Post by unlogic »

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.

It's funny how catnaroek was completely vendetta-downvoted in this thread for speaking valid things. For those who don't understand the difference between objects and values, this video may be of help: https://www.youtube.com/watch?v=-6BsiVyC1kM

Re: Arguments against JSON-driven development

#198

Post by sevensor »

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.

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 discussion; this sort of thing is why I come to HN.

Re: Arguments against JSON-driven development

#199

Post by catnaroek »

qwertyuiop924 wrote: post #196
catnaroek wrote: post #168

Earlier quoted context omitted.

There's very little in common, beyond the notions of mathematical variable and value. Syntactically, a functional program is an expression, but a logic program is a proposition. Operationally, functional programs run already constructed proofs, but logic programs search for proofs. Pragmatically, transcribing a logic program into a functional language or vice versa is difficult without effectively writing an interpre…

Don't mock me. And yes, I did mean the notion of mathematical value and variable. That's one of the core tenets of both.

> I did mean the notion of mathematical value and variable. That's one of the core tenets of both.

Maybe from a big distance this is enough similarity to lump functional and logic programming together. But on closer inspection, functional and logic programs are still very different.

> Don't mock me.

I wasn't mocking you. You clearly must not understand functional and logic programming very well, if you think they are in some way “close”.

Re: Arguments against JSON-driven development

#200

Post by qwertyuiop924 »

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.

...And here you are, completely demonstrating my point: Your defintion of "value" is not the same as the one in common usage: if you're going to go around using strange definitions of words we all know, at least tell us beforehand.
Post reply on HN