In praise of... text files and protocols
I must disagree here. Once you define complex enough text protocol, there are ways to mess it up, or be incompatible with. Say what you want about ASN.1 and similar formats, but if you have a correct parser, you know the values are exactly the ones you expect.Real-life example I kept running into was SIP implementation. (think someone knew only HTTP and decided to create internet telephony) First, you have line length when parsing - some implementations will limit it, some won't. If it's limited, some implementations will allow you to wrap the lines according to the protocol. But then others will say it's too complicated and unlimited line-length is the way to go. Then you have alternative names for sip uris: you can say "me" . Or just . Or number@ip. Or ;some_parameter. Or someone else decides to go with . Some parameters have associated values, some don't - guess how many implementations don't support both ways...Before you know it, there's 1000 conventions and everyone supports some minimal common core, but fails for at least one other specific implementation.So you say - there's always structured text - json/xml/... But look at the example in the blog post:    
      Bounds
      {{25.4278, 76.3008}, {104.75, 91.8751}}

So how long until someone comes up with implementation that doesn't use spaces between the numbers? What's the supported precision? What happens when one tuple is skipped? Do you have to parse exponential numbers correctly? How do you deal with duplicate keys in the dict?I see the appeal in text formats and then remember... no - it's not the right way. JSON is a bit less-wrong than XML here, because you know what's a number, what's a string, what's a list. You'd probably do {'Bounds': [[25.4278, 76.3008], [104.75, 91.8751]]}.Until someone comes out with a popular implementation that does case-insensitive matching for keys... and switches from 'Bounds' to 'bounds' in some version.