by Michael S. Kaplan, published on 2007/03/01 11:42 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/03/01/1779988.aspx
In most cases, Raymond is right when he says If you have to ask, you're probably doing something wrong.
The one time when you might not be doing something wrong is when you are testing.
Because then you want to verify that the limit works, and the limit minusplus one does not.
In many such cases (where the maximum is driven by resource constraints), the attempt is more misguided than wrong.
But when it is questions like the maximum size of e keyboard layout name, it is wrong if you are not a tester but otherwise it is okay (even though it can be annoying if you are the developer who has to fix the bugs that the tester finds!).
I haven't decided how I feel yet about people who are not the actual internal test owners of an area at Microsoft and are not beta testing. I mean, there is no earthly reason for them to be testing some of these limits, it has nothing to do with their product/application really. Maybe I just figure we should interview them or something. :-)
ReallyEvilCanine on 2 Mar 2007 1:00 PM:
Sorry, Michael, but I disagree. Just as one of the posters in Raymond's blog, I too cut my teeth on the 6502 and back then you really had to pay attention and know where limits were. You had to code both efficiently and creatively.
<i>I mean, there is no earthly reason for them to be testing some of these limits</i>
The way you and Raymond and Redmond see it, perhaps, but others out there code differently. I learned a couple decades ago that I could save a lot of space, memory, steps and time by looping a bunch of POPs rather than following "standard practice", or using multiple indirect indexes based on expected memory values rather than wasting a bunch of space building arrays and using direct calls. How do you write relocatable 6502 code when a BNE can only JMP forward 127 or backwards 128 bytes? It's a limit, but knowing it you can work around it.
There's always going to be some hotshot out there who comes up with a novel and more efficient method and in doing so he may well run into some limit. Why shouldn't he know where that wall is? Why shouldn't he be able to write the most efficient code possible?
In some ways I really miss pre-1986 coding. Everyone seems to be caught up with their expectations of continued increases in processor speed and memory capacity to cover for their sloppy programming and so never give any thought to efficiency.