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

141–150 of 306 posts

Re: Arguments against JSON-driven development

#141

Post by catnaroek »

sevensor wrote: post #137
catnaroek wrote: post #113

Earlier quoted context omitted.

The runtime system's memory manager could automatically hash-cons equal compound values, reducing their memory footprint. It's like the flyweight pattern, except the runtime system gives it to you for free.

I agree that's nice for memory use. It's totally consistent with the immutability of tuples, too. I suppose Python has elected to take the memory hit to reduce complexity in the interpreter?

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

Re: Arguments against JSON-driven development

#142

Post by agentgt »

On the one hand I agree with OP on directly interacting with JSON is not really a good idea but on the other hand I completely disagree with that behavior should be shoved into data objects. Also I think part of the problem is Python doesn't have much typing (I know they recently added optional typing in python but I don't think many use it).

As more of an FP guy I'm firm believer of the separation behavior and data. Clojure's Hickey sort of has a valid point... its freaking data... stop making it complicated to access it.

Re: Arguments against JSON-driven development

#143

Post by scarface74 »

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…

It's a language/framework issue. C# supports first class properties with get/set semantics. In your method (actions) in the controller you would write something like this:

public List Get(SearchRequest request) { ..... return customers; }

Somewhere else in the (configurable) pipeline the framework can decide how to deserialize the SearchRequest and how to serialize the List based on the Accept-Header.

(CustomerModel/Request would not be business objects. They would only be used to on the API layer)

As far as validation. You could just put attributes on the properties of the Request like [Required] and they would automatically be validated before your Get method is called. Of course if the types don't match, the framework would send the appropriate error.

Re: Arguments against JSON-driven development

#144

Post by Roboprog »

milesvp wrote: post #110
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…

This. I've been programming this way for over a decade. Long before JSON was a thing. I find I rarely need anythng more than a list or a dict for most of the data manipulation I do. Being on the web has only strengthened my tendency for this, since everything ends up being stringly typed anyways. Nearly every function/API I write is: get some data from somewhere (hopefully serialized), manipulate the data, return dat…

I can't stand the development style that takes takes the associative array values from a web action (POST, JSON parameter...), creates a custom class code, dutifully copies stuff into it (with varying degrees of library support and manual make-work), then immediately passes it somewhere else to copy and immediately throws it away thereafter.

Such as waste of typing and perpetual reading.

The alternative deserves a "top level" comment...

Re: Arguments against JSON-driven development

#145

Post by dragonwriter »

catnaroek wrote: post #129
dragonwriter wrote: post #128

Earlier quoted context omitted.

> So you're saying that the behavior of the `is` operator is implementation-defined? No, the behavior has a standard definition: it reveals whether the operands refer to the same in-memory construct. Whether immutable values are stored in the same in-memory construct is, however, AIUI, implementation dependent.

> Whether immutable values are stored in the same in-memory construct is, however, AIUI, implementation dependent. If I can't bind it to a variable, it isn't a value. You can't bind the list [1,2,3] to a variable, because Python has no such thing as the list [1,2,3].

I don't know why we are talking about lists, here, since (implementation details aside) lists in Python aren't conceptually values; for one thing, they aren't even immutable.

If you meant not to change the subject from tuples, yes, its true that whether the tuple (1,2,3) -- which is logically a value -- has a unique in-memory representation is not guaranteed at the language level in Python (and, in fact, it does not in the most common implementation.)

Re: Arguments against JSON-driven development

#146

Post by catnaroek »

dragonwriter wrote: post #145
catnaroek wrote: post #129

Earlier quoted context omitted.

> Whether immutable values are stored in the same in-memory construct is, however, AIUI, implementation dependent. If I can't bind it to a variable, it isn't a value. You can't bind the list [1,2,3] to a variable, because Python has no such thing as the list [1,2,3].

I don't know why we are talking about lists, here, since (implementation details aside) lists in Python aren't conceptually values; for one thing, they aren't even immutable. If you meant not to change the subject from tuples, yes, its true that whether the tuple (1,2,3) -- which is logically a value -- has a unique in-memory representation is not guaranteed at the language level in Python (and, in fact, it does not…

Err, sorry, yes, pretend I said “the tuple (1,2,3)”.

Regarding in-memory representations, the whole point to using values is that you don't care about the representation. A value may be represented in a myriad different ways, but from within the language (as opposed to, say, using a memory debugger), you can't observe the difference. If you're allowed to probe differences between two representations of the same value, the value abstraction is leaky.

Re: Arguments against JSON-driven development

#147

Post by Roboprog »

Singletoned wrote: post #99

> Once you go dict, you won't go back. This style of development is too easy, since dictionaries are baked into Python, and there are many facilities for working effectively with them. How is this an argument against using dictionaries? After 10 years of Python development, I do find myself using dictionaries rather than objects, in just the way that the author proscribes, but I'm finding it to be a genuine pleasure.

REPENT!!! :-)

Yeah, get shit done, YAGNI, and all that.

If needs wrapper, make one for repeated access types. If needs one or more bonafide objects for passing around, updating, and general good behavior, the make them as needed. Otherwise, there are 15 other little jobs that need coding, and we gotta move on.

Re: Arguments against JSON-driven development

#148

Post by Roboprog »

smizell wrote: post #32

Coupling your code to the JSON you receive over the web can lead to some interesting problems. If the system on the other end decides to make some change you are not expecting, it can lead to errors. In JavaScript, a simple thing that helps is to use lodash.get and provide a path to the property you are wanting. lodash.get(someObject, 'path.to.a.property') If the path isn't there, the lodash.get returns undefined. Th…

Simple rule of thumb: Don't Repeat Yourself. If part of the data structure is accessed in multiple places, create a wrapper routine (or even an object/class) around it. Otherwise, if it's in one place, perhaps "You Aren't Gonna Need It".

Re: Arguments against JSON-driven development

#149

Post by mpweiher »

I actually saw this coding style way before JSON, for example at Apple. I even jokingly created DUKE: Developers United against Keyed Everything.

Another place I see this is in the eternal dynamic/typing debate. A lot of the criticism of dynamic typing will be with examples from JavaScript, Ruby, Python and maybe even PHP. Hardly ever from Smalltalk (or Objective-C), because Smalltalk code tends to not have the types of problems cited. This puzzled me for a while, because I also find these languages somewhat less "solid", yet couldn't quite put my finger on why.h

That is, until I realised that all of these languages use hashes as their basic object representation. Coincidence? I think not. So I coined the term "hash language" for these languages, both because they are hash-based and it appears to be easy to make a hash of things in them, possibly for precisely that reason.

That said, I think it's also a mistake to disregard the power this sort of very generic programming brings, especially once you consider objects composed of multiple facets that are interpreted in different contexts.

IMNSHO, the way to combat hash-programming is to provide powerful and convenient metaprogramming facilities for object representation, so dealing with objects generically is just as easy and obvious as dealing with dictionaries.

Not entirely surprisingly, my own language ( http://objective.st ) has some facilities for this, mostly by making identifiers into first class entities. More research needed ;-)

Re: Arguments against JSON-driven development

#150

Post by dpark »

catnaroek wrote: post #95
dragonwriter wrote: post #91

Earlier quoted context omitted.

Actually, OOP, particularly statically-typed OOP, seems to be a major domain in which the distinction between "value types" which contain "values" which do not evolve over time and "object types" which contain "objects" which may evolve over time is used frequently [0]. There are some OOP languages that take an "everything is an object" approach and provide no clear object/value distinction (this seems to be more the…

> Though in most such languages, the distinction between object and value involves more than just mutability, and is more deeply associated with indirection of storage Values, unlike objects, don't reside on memory, but rather in the semantics of the language. Of course, representations of values reside in memory. But that's an implementation detail. What matters is the abstraction the programmer is exposed to.

So your assertion is that objects are not an abstraction or defined by language semantics?
Post reply on HN