Of all those improvements on which we spend our newly gained processor power and memory bandwidth each year, textual formats are probably one of the most effici

Of all those improvements on which we spend our newly gained processor power and memory bandwidth each year, textual formats are probably one of the most efficient priorities. The window where binary formats are absolutely required has shrunk down to the most low levels. With data formats we're basically where we've been with "scripting" languages for years: we can afford to start with the highest possible level and trickle down towards compiled code only where necessary. Further, whenever I've ever had to create a binary format I've written a translator first. The translator is a program that can read the binary format and write the same information out in editable text form, and that can also parse the text and write out the equivalent binary. Then I only work and debug using the text format and just convert to binary when needed. Usually this approach implies defining an API that you can use to construct the text or binary message. The API becomes automatically tested when I start by working with the text representation and when I finally move on to writing natively binary only (for performance reasons, obviously), I can trust that it works as well as during development. And I can use the API to generate text, too, so I can easily compare and see what's going on.