>>BTW, on the speed issue John mentioned, I once heard a story that a development team rewrote a VB middle-tier object that did lots of string manipulation in VFP and saw a 100-fold improvement in performance.
>
>
>A recent showdown at news.devx.com in the Offramp group showed VFP's speed advantage in string manipulation to be largely myth. It's true that handling large strings in memory in VFP is much faster than doing the same thing in VB, but as a VBer over there pointed out, that's just not the way you do it in VB. There were several VB/VFP challenges set forth in which programmers from each side put together routine to perform the same task: VB killed VFP in File I/O, string manipulation was very close.

Erik,

I didn't even see a VFP response for the file I/O. Besides, as I've said before, this particular part of the challenge is really weighted towards VB. VB can do the file read directly. VFP would have the additional overhead of converting of the values from character to double precision floating points. That, in and of itself, is a killer. This is not to say that in all areas VFP's file I/O is inferior, just in this particular instance. I think Craig had the idea to read in the entire contents of "War and Peace" and change "Anna" to something else. In something like that, my money would be on VFP.

I personally think that the "Challenge" is too broadly scoped to produce any really meaningful results.