Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
How does VFP 7 compares to Delphi 6?
Message
De
17/08/2001 18:36:19
Gerry Schmitz
GHS Automation Inc.
Calgary, Alberta, Canada
 
 
À
17/08/2001 08:23:52
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00544621
Message ID:
00545737
Vues:
15
This message has been marked as a message which has helped to the initial question of the thread.
>Thanks for replying Gerry!
>
>>"Delphi doesn't compete with VFP; it competes with VB (and VC)."
>
>Sorry, but I couldn't understand your statement, because I've in my mind that VFP competes with VB (then VFP competes with Delphi) and it's far better than it. We're saying that all the time, right!

IMO, VFP "competes" against PowerBuilder; PB is also a "specialty" language oriented towards "Database applications".

C++, VB and Delphi are all "general purpose languages" that include native compilers, strong typing, structures, unions, pointers, multi-dimensional arrays, custom "events", funtion pointers, call-backs, blah, blah.

To say that VFP competes with the above in ANYTHING other than "DB Programming" is a stretch, IMO. And when I say DB programming, any "advantage" that VFP might have is mainly in "local" data handling; as we get into more "exotic" configurations, the adcantages become smaller because then we start dealing with protocols and access methods that are not "native" to VFP.

So, if one wants to say VFP "competes", one has to be more specific in terms of the conditions under which VFP is "competive".

People ask me why I wrote a particular App in VFP (and not VB, etc); the answer is usually related to (a particular class of) "data management", and very little else.

>As you get deeper into VFP programming you start to work close to Windows APIs and have to have some more knowledge about Windows "internals/intrinsics" (like the Algol people call that kind of stuff) to understand and/or make some things, so I faced many problems that great folks here at UT (thanks to them!) helped me. Then I found that these folks don't work with plain VFP coding only, they also complement their toolbox with many many other tools, including C++ and Delphi.

The number of folks who use C++, etc. to extend VFP relative to the number of people who use VFP is very small. Anyone who had to make extensive use of C++, etc. to extend VFP wouldn't bother to start with; they would use C++, etc. for their project from the beginning. The lack of threads related to "FLL programming" seems to back that up.

>Also I could notice that many VFP people has Delphi as their second choice. Maybe whe should ask why, since that could help me in evaluating my positioning in relation to this tool.

Most people don't use Delphi because they worry that Borland might not be around. Other than that, Delphi (and it's "cousins" C++ Builder and Kylix) are superior to MS VB and VC in terms of "rapid application development" and elegance.

>Pardom me for the massive reply, but hope you understand that your (as to others) opinion is very important to me in deciding some actions I should make to help filling my toolbox.

The fact is I'm constantly (re)evaluating languages with each new release to see what they have to offer and their future direction; eg. VB did not have inheritance, now it does; Delphi could not subclass Forms, now it can; VFP doesn't have a native compiler, it still doesn't, etc.

I think the bottom line is, the toolbox changes and will keep changing, and probably should be changed every so often based on what's happening out there and what you plan to accomplish.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform