Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
VFP imo
Message
From
25/01/2004 09:30:33
Hilmar Zonneveld
Independent Consultant
Cochabamba, Bolivia
 
 
To
25/01/2004 07:06:33
General information
Forum:
Visual FoxPro
Category:
Other
Title:
Miscellaneous
Thread ID:
00870360
Message ID:
00870380
Views:
18
Although I like VFP a lot, I should point out two disadvantages in addition to the ones mentioned in the summary which Al Doman mentioned.

One, and this is the most serious disadvantage IMO, is that VFP works only on Windows. This is becoming more serious by the day, now that entire countries are switching to Linux. Note that .NET has the same disadvantage, so frankly, I see no reason to switch to .NET: Invest a lot of time learning a language which I may not be able to use 5 years from now? I am currently investigating Java (I have to teach it at the Academy), and it looks like an interesting option. Unfortunately, the one-semester course doesn't delve into more sophisticated aspects, especially database development.

In the meantime, especially since I know VFP already, I think my time is better invested by learning to combine VFP with some other technologies. For instance, so far, I haven't taken the time to learn C/S.

Two, since it isn't really compiled, it may simply not be fast enough for some low-level development. This may usually not be relevant for writing database applications for the business. And I never saw a need for more speed. However, this can be a consideration in some cases.

>Hi Al,
>
>>Though it may be unlikely, I should point out that MS's support for VFP (currently "up to 2010") is entirely up to MS - they could change that at any time - preferably extended, but it COULD be shortened, and we'd have no recourse.
>
>Sure but for many of us even if that were to happen it would not spell the end of VFP development. I would easily be able to continue to develop vertical market, shrink wrap, and web based solutions for some time thereafter. The development tool would still work and be capable of producing decent products. But anyway, in the IT world 6-7 years is a long time and a lot can happen.
>
>
>>>VFP is probably not great if you are looking for a job in a large corporate IT department. Most large company IT departments are towing the MS party line. Whether this is right or wrong, smart or stupid, is irrelevant. "Nobody got fired for buying IBM" is the guiding principle for these corporate lifers.
>>
>>This has been pointed out pretty well in the "Mom and Pop" thread, but it's worth emphasizing the large difference in mindset between enterprise vs. mom&pop/shrink wrap markets. The former puts a lot of weight on the technology, but the latter not only usually doesn't care, they don't WANT to know. At most small firms I've dealt with, eyes glaze over very fast at any discussion of technology - they simply want something that does the job, and does it reliably.
>
>Fully agree.
>
>
>>>This means that developers looking at this avenue for earning a living need to enhance their skills with database server knowledge and/or .Net and/or Unix or its variations and/or Java and/or other open source options, etc. Which is probably a good idea anyway as increasing ones knowledge is just a good idea generally.
>>
>>Picking and choosing components can yield competitive advantages - e.g. Linux/Samba file server, open-source DB server, etc. even while still using a familiar VFP front end.
>
>Fully agree. Most of the systems we have developed are hybrid's incorporating various dev tools and components. I would imagine that is the norm and not the exception.
>
>
>
>>>One of the fairest advantages vs. disadvantages of VFP that I have read can be found at http://www.clearform.com/visual_foxpro.htm. It’s worth a read.
>>
>>I'd say it blows VFP's horn well, but hardly discusses alternatives with any depth.
>
>For a "one-pager" I think its reasonable without getting too involved. It touchs the main bases and clearly highlights several scenarios where SQL/Oracle would be the correct choice as opposed to DBF.
>
>
>>>The landscape is not clear and personally I wouldn’t want to forecast the IT world wrongly and then have to repeat the forecast ad nauseum hoping to eventually be right :)
>>
>>I think what drives a lot of these threads is angst over the community's love/hate relationship with Microsoft.
>>
>>VFP is written in C++. As a thought exercise, imagine that it had been written by an open-source community. We could fix bugs or extend the product as we saw fit. No individual or company could prevent that, ever - it couldn't "die". It might be ported to non-Windows environments (although a Java base might be easier or better for this). If it lost relevance, we would have only ourselves to blame.
>
>Fully agree.
>
>
>>But, all this is a classic moot point. My guess is the VFP code base is immense - maybe larger than any single open source effort, including the Linux kernel. It's desktop-oriented - and until recently, there's been basically zero market for open source on the desktop. There is no way a 4GL-5GL tool like this would have been built by an open source community (it hasn't, to the best of my knowledge). Unless a large company like MS, Borland, IBM etc. developed it, it simply wouldn't have happened. They put a huge amount of money and other resources into it up-front, and they have to get recompensed for that.
>>
>>So, we may not like the current situation with VFP, but we've got to understand it :-/
>
>Again I agree but I must be honest and say that all in all I am not actually unhappy with the VFP situation. MS continue to produce a decent product and I can continue to use it. It works for me and I can still spend time looking at other options.
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform