In the latest edition of Joel On Software, Joel pulls out a Larry Wall quote:

People understand instinctively that the best way for computer programs to communicate with each other is for each of the them to be strict in what they emit, and liberal in what they accept.

Joel makes it pretty clear that he thinks this is a stupid idea. Frankly, so do I.

Why is Design By Contract considered such a good idea? Because a very explicit contract exists between the client and the server: I, as the server, tell you, the client, exactly what you're allowed to give me and and I promise that, in return, I will do X. (If you're interested in this with Perl, try Class::Contract by Damian Conway).

Some people would argue that this violates the spirit of TIMTOWTDI. No, it doesn't. Nothing in the contract makes any guarantees how I implement my solution. Nothing in the contract specifies how you have do what you want to do. It merely ensures that when different portions of a program interact, they do so on a very, very predictable basis. Imagine working on a huge system where you have many virtually identical object methods that take a scalar, or an array, or an array ref, or a hash_ref using named parameters but won't accept a hash, etc. What interface do you use? And what if the data structure returned seems to be arbitrary? I've worked on systems that do that and they are Not Fun.

One of the best examples of this problem is the Web browser. Netscape won't render tables that leave off a closing table tag. This is a Good Thing. Internet Explorer has once again tossed standards out the Window (hah!) and decided that you, the developer, don't know how to send a correct Content-Type. Instead, IE examines the beginning of your entity body and it decides how to render it. Have you ever wanted to send HTML as plain text? That's a non-trivial task if you're using IE. More than once, I've sent an "image/gif" that was actually a jpeg and tried to figure out why IE rendered the image and Netscape didn't. IE tries to hold the programmer's hand and, as a result, takes away fine-grained control -- though it's still one of the best browsers on the market.

How could these problems have been avoided? W3C standards are, in effect, a variant of Design by Contract. You know what you have to send and, in return, you know exactly what to expect. I've heard so many Perl programmers moan and groan that standards aren't being adhered to, but fail to appreciate that what products like IE are trying to do is be liberal in what they accept.

So, I think Larry is right in the sense that being liberal in what to expect is a worthwhile idea. Very few people can get it right, though, which is why I think Larry is wrong.

Cheers,
Ovid

Update:: I think my point was not as clear as I thought. As I said below in a reply to tye, it's "not that we should be so rigid that we break with the slightest gust of wind. My point is that we shouldn't be so flexible that we fall over." It's that middle ground that most fail to find, so I'd rather they err on the side of caution :)

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.