Arguments against JSON-driven development

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 case with dynamic OOP languages, and even there while there may be little ergonomic distinction beyond the lack of mutability, there often are immutable "objects" that are stored without indirection which are far all intents and purposes values. Though in some cases the distinction between these and simple immutable objects is obscured from the programmer.)

[0] 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, and its quite possible to have immutable objects which might be values from a technology-neutral conceptual perspective, but which are objects from an in-language implementation perspective.

Want to program in an OO way using JSON? Easy. Just build a factory to generate objects from JSON input. Put your validation and error handling right there. Now you can get a known valid object from the JSON, a class instance with all the encapsulation and business logic your heart desires. Need to share it with the outside world? Provide a JSON output method.

Translating data formats is at the heart of day-to-day programming. It ain't rocket surgery. Fix the problem, not the blame.

(And if you think JSON sucks, believe me, you never dealt with data file formats from the pre-XML days!)

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.

Whilst that's more possible with protocol buffers or pickling (or whatever your language calls it), I can't think of any languages offhand which can round-trip any data. It's generally not possible to serialize objects denoting external resources - such as open file handles or network sockets. It's also often not possible to serialize closures, weak references (without dereferencing them), and not necessarily possible to serialize self-referencing objects: e.g. a list which contains itself - pickle can handle it, but I don't believe protocol buffers can do it.

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.