Wil Shipley has explored this approach: <a href="http://blog.wilshipley.com/2009/08/pimp-my-code-part-16-heuristics-and.html" rel="nofollow">http://blog.wilshipley.com/2009/08/pimp-my-code-part-16-heur...</a><p>I also swear I remember reading another example of this on his blog, but I'm unable to find it, so I'll paraphrase from memory (which is somewhat murky, so caveat lector):<p>One of the features of Delicious Library is that you can use your computer's built-in webcam to scan barcodes as a way of adding items to your library.<p>The traditional, mathematically-inspired computer science approach to implement this is to frame the problem as: "Given an image with a barcode somewhere in it, find the barcode, and then read it." The problem is that a general algorithm that accepts entire set of images with barcodes in them is prohibitively slow, because you have to deal with skew, perspective, lighting, focus, etc.<p>The approach they ended up using was inspired by biology: it's OK to fail some of the time as long as there's feedback. They went with a much simpler algorithm that takes a fraction of a second to succeed or fail. They run it continuously against new frames, and indicate to the user whether it has succeeded. Since the user is standing there with the barcode in front of the camera, they'll reposition, try different angles, etc, until there's success.
<i>If you pass around numbers as strings (or JSON, or XML) even though they can be more compactly encoded in binary, you’re doing sloppy programming. If you then parse those back into a native int at some later point and assume it won’t overflow, you’re really doing sloppy programming.</i><p>I find this to be a terrible example of what's sloppy. Formatting as text is more portable, it's one of the tenets of the UNIX Philosophy.<p>If you encode numbers in binary, you also need to somehow communicate the endianness of the encoding (maybe this is standardized, and you always use htonl, but something still needs to know that you're using "network order"), and you need to store how many bytes the number represents (because the int size on the target may be different a different size) , and you need to provide some way to easily convert back to a readable format for debugging.<p>By the OP's logic, SMTP and HTTP are "sloppy" because they are readable and easily debugable; admittedly, they are sloppy for other reasons, but not because they don't encode things in binary.