Arguments for dict/list driven development: NOTE: This isn't JSON driven-development, JSON just mimics base types like dict, list, string, numeric etc of all l

Arguments for dict/list driven development: NOTE: This isn't JSON driven-development, JSON just mimics base types like dict, list, string, numeric etc of all languages and a big reason it is so common especially in Python/Javascript. - Large unknown lists/dictionaries data structures can be deserialized into dicts/lists for any language without issue. Sometimes keys/data are unknown such as large attribute data sets that may always have new keys. In that case strong typing to an OO object will always be broken. Example: a facebook attribute set, keys/data that aren't set will not appear, new ones are added all the time, which would create a cat/mouse serialization/deserialization game. Same problem a binary structure has (offsets) when you really need a flexible keyed structure. One missing key doesn't break your whole serialization/deserialization system built with strongly typed OO. Validation can be done on accept and if necessary convert into an OO system. - If needed, classes that are backed/extended/inherited by a dict/list or set (or composition) that can load in the JSON/dict/lists and only expose the needed values after validation are useful. i.e. a class that inherits from or composes to Dictionary<string,object> for instance in C# would only fill keys that are necessary for the view data, not a bunch of extra null fields because it might not have that key/property. It also has the ability to deserialize objects that may have new keys. Not everything is a perfect world where data structures are known before-hand. - It reduces complexity many times, no need for an OO serialize/deserialize layer when you are passing back as basic dict/list or JSON. Why add complexity to something simple? - Unless you control the server and the client, real-world data structures aren't a perfect map of keys/values to OO properties. Assuming that is a system ready to break in the real-world many times. Someone adds a field to the DB object then all clients that use it can't serialize/deserialize. Real world serialization/deserialization has to accept in basic types dict/list, validate and then use as needed (some go to OO objects behind scenes). I see too many systems where people just have an EF object and expose that over a web api and just expect it to work, that is a bad example of poor encapsulation. Some fields don't need to be serialized to public apis. In Microsoft land MVVM was created to help stop this practice but still creates two sets of OO objects and breaks on any new keys/data (though breaking here may be desired for strong typing). - Dict/list data structures can be easily setup to have cleaner naming and keys without tons of attribute/helpers i.e. first-name key instead of first_name, FirstName, or firstName. This is more friendly to web/url naming that is common. - Noted in the article, less memory used in many cases and highly optimized time in basic lists/dicts. There are many more reasons... Dicts, lists and basic string, numeric types are the base of all languages and computer science types. The reason this is common is it is simple to work with these types without added cruft of OO when needed. OO does add complexity and if it isn't necessary you are just upping complexity for no reason (and memory). It is similar to the complaints of C coders to C++, basic structs and sets are sometimes less complex than C++ OO objects. Same thing with dict/list of some monstrosity of an OO serialization/deserialization system that breaks on every new key or field and you have to update the server and client rather than just increment a version and validation. The longer you code the more you see this. OO objects should not be used all the time just like dict/lists shouldn't be used all the time.