Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
FoxPro Job Market
Message
From
22/01/2004 09:55:14
Walter Meester
HoogkarspelNetherlands
 
 
To
22/01/2004 08:55:40
Jay Johengen
Altamahaw-Ossipee, North Carolina, United States
General information
Forum:
Visual FoxPro
Category:
Contracts, agreements and general business
Miscellaneous
Thread ID:
00869227
Message ID:
00869478
Views:
30
Hi Jay,

>I don't always see eye-to-eye with John, but to me it's as simple as doing a search for Foxpro positions in the US compared to other languages. I was out of work for over a year. It was definately a bad time for all of the IT market, but if I had had experience in VB I would have had offers. Because my background has been almost exclusively Foxpro I ended up doing home repair for that year. I'm not saying Foxpro is dead, but you can't argue with the practical facts faced when trying to find work.

FoxPro positions have always been harder to find than for example VB postions. From the introduction to now this has been the case, so indeed it would be easier to find VB positions than VFP positions in hard times.

However this does not have anything to do, with the so called death of VFP. Many VFP positions are fairly static position IMO as oposed to some other languages. Good VFP talent is hard to find, so your best bet is to be good, no better, to be an expert in VFP.

I'm continuely surprised how often I encounter VFP in various places. For example only yesterday I had a potiential client on the phone in Yale (US), asking about the programming language. I told them it was written in VFP8. They told me that they use VFP in their clinic.

You can look at it in several ways. On the average it takes less programming efforts to develop an application in VFP than in VB. From the technical POV you can create more complex applications in VFP in less programming hours. This would mean that if there would be an equal number of projects to be done in VFP and VB, you still need more VB programmers than VFP programmers.

An additional cause might be that maintenance at VB projects might be far more intensive than VFP projects as handling complex data mechanisms in VB is simply a nightmare (No local database engine) and you HAVE to use an external database (e.g. SQL server) to store your data. All aspects that don't exactly speed up development. VFP project have shown to be easy upgradable to newer versions (Versions 3 to 9) with only a few checkpoint before upgrading.

From experience I can tell that today VFP is used at several big institutions like financial buisinesses, medical and governmental just because of the data processing capabilities of VFP.

Personally I'm in a bit different postion than you are: I'm a software vendor, selling VFP products rather than beeing a contractor, so life is a bit easier when hard times strike. If you're only looking for work and don't care about the tool then go ahead, choose the tool you think that will get you the most amount of money (probably some legacy language like COBOL). If you're looking for a tool that enables you to write a complex database application efficiently then VFP is not a bad choice at all.

Walter,
Previous
Reply
Map
View

Click here to load this message in the networking platform