>>3. VB owns 80% of the rad tool's market. Somehow, 80% if the developers out
>> there are not casual users. This only goes to support point one above.
>
>That's an interesting point. I thought we couldn't use VB to do RAD. I used it at several occasions so far and I found it far from being a RAD tool. I searched for RAD product and couldn't found one either. It's true it might be difficult to do RAD as we do it in VFP as it is object based.


Actually, the exact words that Gaylen Michaels used at the Developer Session (the impetus of this thread) was: "When we're developing an in-house application at Microsoft, we prefer to use Visual Basic to create a prototype rapidly, often with full or near-full functionality. Once the prototype has been approved, we redo the application in Visual C++, to give us a smaller, faster executable."

I think it's interesting that even at Microsoft, Visual Basic isn't considered the best tool for most projects. Another developer said, and Gaylen concurred, that if you had to choose to learn only one tool from Visual Studio, choose Visual C++. If you can use multiple tools, use VB for the prototype and VC++ for the actual development.

Gaylen went on to say that the main reason that Microsoft is pushing VB rather than VC++ is that many developers (myself included) are intimidated by the complexity of VC++, and that Visual Basic is a much "friendlier," higher-level language.

OK, I'll grant him that. Of course, I'd also like to say that I think FoxPro is even easier to learn than VB, for two simple reasons:

1. The Command Window. Can you think of an easier way to debug a complex piece of code than to actually run it, bit by bit, at the command line? In addition, in the older vesions of FoxPro (I'm not sure if this still is the case in VFP6), choosing a command from the menu or from a dialog will echo the actual FoxPro command in the Command window.

2. Fully realized object-oriented design, complete with a visual class editor. Why do something that is almost object-oriented, and try to figure out what was left out, when you can have the real thing? Just as important, why try to represent a visual class in code when you can create it in your everyday form designer, save it as a class, and have it available immediately?

Prototyping in VFP is a breeze. Making low-level design changes is much simpler than in VB (I can't speak for VC++), and while VFP's executables may not be as small as VC++, for most desktop application needs, they're small enough.

Bill