>The participants should have put together a more comparable A/B test, where the requirements include pseudocode to perform a series of simple tasks that leave little room for interpretation by the developer. Suggestion:

Actually, Erik, the VB side was responding to a flat statement that VFP is much faster at File I/O and string handling. The problems to solve were defined, and the only rule was that you couldn't use a tool that doesn't ship with the product.

Also, there have been "pure" VB examples posted.

So far, VB is kicking VFP's ass with File I/O (we haven't even come up with a response to the matrix problem) and with string handling, too.

Now, I'm participating cuz it's interesting, but I'd never have bothered to make the original statement, cuz that's not what I see as VFP's strength.

>Defining a broad goal and letting the developer interpret whichever means to the end (or whichever end) is like trying to test running speed and allowing the runners to ride bicycles.

Yep. You're starting to understand the off.ramp < bg>.