Dear All,

During my period of time here on the UT, and with the VFP community in general, I’ve attempted to live up to a simple credo, or set of rules. These are:

1. I tell people when I know the answer.
2. I tell them when I’m guessing,
3. When proven wrong, I'll admit my mistake and apologize.

I think that, over the last five years here, I’ve done a reasonable job of living up to that credo. Have I not at times? Perhaps so, but I am human, with my own set of foibles. I’m reminded here of a quote

“Every man is as heaven made him, and sometimes a good deal worse.” – Cervantes

I believe that, in general, I have lived up to the credo expressed above. Others may take issue with this.

The thing I believe about programming is that it is a combination of art and science. Art in the fact that by definition it’s the conscience use of skill or knowledge in the creation of something. Science, by the fact that it utilizes the theoretical in proper design, and demands that we prove any algorithm we create.

The latter is an important point, Basically, what it says is that we are scientists. As such, we should be required to adhere to the scientific method. I like to sum this up in a series of steps.

1. Realization – This is the point where we realize what the problem is that we have to solve, or realize that something doesn’t work as we thought it would. Here, we form the hypothesis as to why this occurred.
2. Confirmation – We determine, either through someone else or another application, whether or not the problem has been solve, or, in the case of a bug, still exits.
3. Explanation – We document why something works, or form a hypothesis as to why it doesn’t. In the latter case, this takes us back to step one.

I believe that the three most important words in science are, “I don’t know” since they are the starting point to acquiring new knowledge. A good scientist, however, must have an open mind and when multiple plausible and reasonable explanations exist will not take one over the other by calling one factual.

Recently, there has been much discussion on the subject of bugs. First, of course, we must define what a “bug” really is. Therefore, for purposes of definition, I will define it this was: A command or function that doesn’t work as anticipated. Now there are two plausible and reasonable explanations for a “bug”. It is unintentional or it is intentional and by design.

Regardless of the circumstances, every time such is encountered, as good scientists, we should have an open mind to the issue in order to properly determine whether or not it is, indeed, a bug. If a plausible and reasonable explanation exists, however, the best we can say is, “I don’t know”.

Let’s take a recent example. The behavior of VFP in regards to division by zero changed between versions 6.0 and 7.0. Some feel that this is a bug; others believe that it isn’t and may be by design. The situation arises because of checking for numeric overflow. For example, consider the following snippet:

CREATE CURSOR Foo (Foo N(2))
APPEND BLANK
REPLACE Foo.Foo WITH 100 && Numeric overflow occurs.
APPEND BLANK
REPLACE Foo.Foo WITH 1 / 0 && Numeric overflow occurs.

s A common check for numeric overflow is to compare the field value against division by zero. However, as the above shows, division by zero isn’t the only cause of numeric overflow.

Is there a reasonable and plausible explanation for this change in behavior? Certainly, but before getting to that consider that VFP is one of the few languages that doesn’t consider it to be an error. I began working with Fox in FoxBASE+ 2.10. When I initially started, I was surprised that division by zero didn’t throw an error. Based on my recollection, I don’t recall ever seeing an explanation of this. I may be wrong about this but that’s my recollection.

Now in checking for numeric overflow, it is a common practice to use an expression like: Alias.Fieldname = 1 / 0. However, strictly, this isn’t always true. For example, in the above snippet, the value in the first record clearly isn’t equal to the value in the second. While it may have been that in versions of FoxPro prior to 7.0 this would return true regardless of the cause of the overflow, 7.0 considers division by zero clearly differently than its predecessors.

Mathematically speaking, division by zero results in an unknown. In many ways, but not all it is very similar to a null. With a null the expression: .NULL. = .NULL. returns false because it cannot be evaluated. Similarly, 1 / 0 = 1 / 0 returns false in 7.0 (but true in previous versions). It makes sense that the preceding statement returns false for the exact same reason that comparing a null to itself returns false. The statement can’t be evaluated and therefore cannot be equal to anything.

Further, it should be considered that the printer drivers from both HP and Lexmark, contrary to DDK specifications, leave the state of the FPU in a way that they expect that the calling software handle exceptions. This led to problems with 6.0 prior to SP3 because of fault tolerance. While many of these errors have been resolved. There are still some cases where using the reports to either print to a preview mode or to the printer, cause errors.

Is it plausible and reasonable to think that this change in behavior was implemented to circumvent these problems? I believe so. Yet certain people believe it to be a bug simply because it hasn’t been documented. While I respect their right to their opinions, I must say that such opinions run contrary to the “open mindedness” that science requires. Is this a bug? The answer is simple: I don’t know.

What is of specific concern here is the fact that, as an MVP, I have a “hidden agenda”. That because I’ve been honored by Microsoft that I’m “in their pocket”, their “shill”, and as David Frankenbach put it, a “sycophant”. Fundamentally, this is an insult. It is an insult, because in trying to be helpful and point out that there may be a reason behind a problem other than simply a bug, we don’t concur with people who are predisposed to think otherwise. I won’t speak for David, but I’m sure that his experience is the same as mine. I have never once been told by Microsoft not to speak negatively about them.

I have said that I view shouting “bug” in the absence of conclusive evidence to the fact is like shouting “fire” in a crowded theatre. You have a right to do so, but any responsible person doesn’t. I think that, at this time, this is important.

Toledo is well on its way. People, in the past have complained about the marketing of VFP. The degree that Toledo is marketed depends on people upgrading to 7.0. The more upgrades, the more money that will be available for marketing. However, by shouting “bug” at every inconsistency, by refusing to admit that there may be another reasonable and plausible explanation for why something isn’t a bug, undermines the future. Someone who doesn’t know that 7.0 is the most stable version to date, may not upgrade because of this. To sum it up, we’re shooting ourselves in the foot with such.

If you’ve gotten to this point, my thanks for your attention and my apologies for being so long winded.