On Tue, May 3, 2011 at 7:13 AM, Alberto G. Corona
E1610With the exception of heavy serialization usage, for example, in very optimized RPC applications (and even there SOAP shows that this is not ever the case), text serialization is better. The unwritten rules of good design says that data representation and compression must be orthogonal. The binary formats were designed for performing both functionalities in the times when memory were measured in Kbytes.
Actually, I'm using binary because it seems simpler. If it were text, I'd have to come up with some text format. I'd either have to invent some ad-hoc new language or figure out how to fit it into some generic format like JSON. There would be parsing, an intermediate format, conversion, typechecking, blah blah. All this complexity for what exactly? So people could edit the serialized output with a text editor? Why don't they edit it with my program, which is designed for that? At least just import the deserialize module and edit the typed data structure in the REPL. And say people do start editing it with text editors... now the format is inching toward public, and I can't change it without breaking someone's text editor habits. In fact, if I serialize the same data with Data.Serialize and with 'show', the binary version is slightly larger! I imagine it's because zeros in text format can fit in a few bytes, while in binary they always take the full 32 or 64 bits (or 128 for the default Double serialization!). So for me at least, it has nothing to do with compression.