<story><title>Arguments against JSON-driven development</title><url>http://okigiveup.net/arguments-against-json-driven-development/</url></story><parent_chain><item><author>wtbob</author><text>&amp;gt; The fundamental advice on Unicode is decode and encode on system boundaries. That is, you should never be working on non-unicode strings within your business logic. The same should apply to JSON. Decode it into business logic objects on entry into system, rejecting invalid data. Instead of relying on key errors and membership lookups, leave the orthogonal business of type validity to object instantiation.&lt;p&gt;This right here is the correct approach.  Serialisation formats should be serialisation formats, whether they be JSON, S-expressions, protobufs, XML, Thrift or what-have-you; application data should be application data.  There are cases where it makes sense to operate on the serialised data directly, for performance or because it makes sense in context, but in the general case operate on typed application values.</text></item></parent_chain><comment><author>qwertyuiop924</author><text>Part of the problem is that JSON and Sexprs aren&amp;#x27;t that they AREN&amp;#x27;T serialization formats. They&amp;#x27;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&amp;#x27;t dicts, they&amp;#x27;re objects. If they&amp;#x27;ve been de-serialized to some degree, they may even have their own methods.&lt;p&gt;By the same token, in Lisp, Sexprs aren&amp;#x27;t a serialization format. They&amp;#x27;re a notation for the linked cons cells that Lisp data is made of. In Lisp, that Sexpr will be crawled for data, or maybe even executed.&lt;p&gt;So while in Python, both may &lt;i&gt;seem&lt;/i&gt; to be serialization formats, they aren&amp;#x27;t.&lt;p&gt;Either way, if the application programmer has any sense, they&amp;#x27;ll abstract away the format of their data. In a lisp app, you won&amp;#x27;t be cdring down a sexpr, you&amp;#x27;ll be calling a function to grab the necessary data for you, usually from a set of functions that abstract away the underlying sexpr implementation, and treat whatever it is as a separate datatype.&lt;p&gt;Of course, the sexpr might have been fed to an object constructor. Heck, it might &lt;i&gt;be&lt;/i&gt; an object constructor, or a struct constructor. All of those types typically provide O(1) access, and autogenerated access functions, so it&amp;#x27;s the same story.</text></comment>
<story><title>Arguments against JSON-driven development</title><url>http://okigiveup.net/arguments-against-json-driven-development/</url></story><parent_chain><item><author>wtbob</author><text>&amp;gt; The fundamental advice on Unicode is decode and encode on system boundaries. That is, you should never be working on non-unicode strings within your business logic. The same should apply to JSON. Decode it into business logic objects on entry into system, rejecting invalid data. Instead of relying on key errors and membership lookups, leave the orthogonal business of type validity to object instantiation.&lt;p&gt;This right here is the correct approach.  Serialisation formats should be serialisation formats, whether they be JSON, S-expressions, protobufs, XML, Thrift or what-have-you; application data should be application data.  There are cases where it makes sense to operate on the serialised data directly, for performance or because it makes sense in context, but in the general case operate on typed application values.</text></item></parent_chain><comment><author>VikingCoder</author><text>...unless your application is doing an in-place edit.&lt;p&gt;For instance, if your image compression application throws out my EXIF data that it doesn&amp;#x27;t understand, I&amp;#x27;m going to be pissed. (Unless you give me an option to preserve it.)</text></comment>