Fog Creek Software
Discussion Board

A Hard Drill Makes an Easy Battle

1. The Larry Wall quote is derivative of Postel in RFC 791 Internet protocol specification where he says "In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior." Or more commonly paraphrased "Be conservative in what you send, and liberal in what you recv."

2. This advice is more applicable in the early life of a standard, when there is still a paucity of mature implementations.

Saturday, November 24, 2001

The point being?

Tony McConnell
Saturday, November 24, 2001

The point being that Joel may be using the Larry Wall quote in an inappropriate place, or at least that Joel is agreeing with Larry without noticing it.

<blockquote>Joel sez: <i>"I think that the evolution of HTML has proven that this isn't such a great idea. In fact, the stricter the API is about its input, the more likely the code is going to work in funny that you remember to bake in the code that adjusts for all these things. Then your application will be buff and strong and it will laugh in the face of wimpy problems like people who use commas instead of dots as the decimal. Ha. I eat commas for breakfast, your code will say, with a Russian accent."</i></blockquote>
Which is precisely the point!!  An application using the converse of the RFC 791 design advice, wherein an application is conservative in its recieving behavior, would fail when faced with, eg, commas instead of dots.  It's funny that Joel would argue with Wall/Postel in a forum, when the time comes to write code, he agrees.

Todd Gillespie
Monday, November 26, 2001

Right on! The whole GlobalSize problem was caused when the programmer was conservative in what he accepted (i.e. he designed his program to work only if it got one particular kind of value, instead of designining it to accept certain other possible values as well).

Then, the MS programmer decided to be liberal in what he emitted, and things broke.

Sounds to me like Larry Wall was right.

Also, what's with the Java dig? You say, "In reality, as Java programmers learned, code is just too fragile for [write once run anywhere] to work very well." That's quite a claim, since WORM is the entire point of Java. And how is this claim backed up? "Well, i once ran into a bug in Java, five years ago, when it was in its infancy. So therefore it can never work."

Mike Schiraldi
Monday, November 26, 2001

I have to agree that Joel was completely wrong on this point. This "Hard drill" stuff may be accurate when it comes to Sun Tzu (i.e. practise hard so that when time for battle comes, the training seems tougher than the real thing) but code is not a soldier. Seems to me that input flexibility is **always** a good thing, as is output strictness.

The thing is, output strictness is easy to do if it is being generated by a program. The only link in this whole chain that generates sloppy output is the user, and the whole point of programming is to make things easy for the user. So, in a blame game where a program cannot handle the sloppy code of another program, I always blame the "outputting" program. But if the "outputtting program" is the user, always blame the "inputting program".


Dileep Krishna
Saturday, December 01, 2001

*  Recent Topics

*  Fog Creek Home