>>
>You can take up VFP, and if your marketplace stays focused on the types of apps that VFP is centered on, it's not a bad choice.
><
>
>I would disagree as it would be too limiting.

I'd qualify it to WRT people starting new in the programming environment. I don't agree where the person already knows some xBASE, and has existing code that is not going to get rewritten as a result of whatever new development is started. VFP leverages some part of their existing knowledge, and will let them continue working with their legacy app during the product lifecycle. This was a major reason for my remaining in VFP at Weatherhill; I rewrote their FPDOS app into VFP over the course of several years, was able to operate in parallel with live data in both the new and legacy systems, and was able to gradually shift them to a Windows paradigm.

I learned VFP longer before I started on VB or SQL Server; I learned about design and analysis long before I ever saw xBASE for the first time, and the basic skills outside the syntax and lexical perspective of the app design are basically identical across platforms. Syntax is an obvious issue; it's a generally mechanical process moving a snippet from one language to another, where the languages offer equivalent functionality. Lexical perspective is a bigger issue; VFP developers tend to be more hierarchically data-centric in their approach to planning apps, to the point that they miss the issue that the app may not be primarily built around an xBASE data repository. VFP addresses data-centric, file and record focused problems in a decidedly superior fashion, but is not broadening it's focus. Othet tools like VB don't have VFP's power where VFP holds sway, but it offers a broader range of serviceability. In conjunction with ADO, VB competes well with VFP at the fringes of VFP's territory, and the number of VB-literate workers is increasing - Office users with VBA, sys admins with VBScript, web developers using ASP. There's no corresponding pool of VFP-innoculated workers building in the workplace.

The telling issue in my mind will be the acceptance of .Net in 2-3 years; if COM remains the dominant interface and the CLR camp falters, and the VB community revolts and refuses to embrace VB.Net, VFP7 is positioned well as a developer tool, but it still lacks the penetration that VB will get through scripting and automation. On the enterprise level, whether VB or VFP is in use, SQL Server will be the large-scale, server-based platform for data access; the difference between VFP's 2GB file size limit and MSDE's 1GB limit doesn't present that broad a realm of cusinesses that can use VFP but not MSDE, and with WANs becoming a far larger concern, database-server based deployment rather than file-server based deployment will increase in importance,with security, client-datasource bandwidth is inevitably an issue regardless of the winner, .NET or .NYET, as long as Windows is the dominant platform. VFP may creep up a bit if VFP7 is a better prospect than VB.Net. After a very brief play with the Whistler beta from the January MSDN, I don't think it'll be a compelling product without .NET as a key technology driving it's adoption; that's based on less than an hour of playing with it on a 320MB PIII 550 with a fast SCSI drive after installing it.

>And, the following statement by you also is good reasoning as to why anybody new to development would be wasting his/her time learning VFP:
>
><
>OTOH, an investment in both VB and SQL pays off not only in their own environments, but across the board - VB translates to VBScript, VBA and related areas, SQL ( particularly T-SQL in conjunction with ADO) will apply to almost any data-centric application, regardless of language, and the concepts apply uniformly across platforms and to some extent across products.
><
>

John, I agree wholeheartedly; a new developer should invest in VB and SQL Server and Win2K now, unless they've a compelling reason to invest in C++ or Java and DB2 or Oracle like someone willing to pay once I'm up to speed for a couple of years. C++ is the language of choice if you're ab;e to think that way; if you can write C++, you can find a job as a codemonkey two years from Monday regardless of what happens with .Net, Windows, Linux, etc.

>The evolution is this:
>
>- Learn the syntax
>- Learn to program
>- Learn to analyize and design
>- Learn to develop
>
>Learning how to program is so far down the food chain when it comes to developing applications. I know many folks who could quote you verbatim lines of syntax. Yet many of these people have never developed an application.
>
>What is the point...??
>
>The point is that the devil is in the details. When your learning is at that level, you need to make a choice. You can only learn one at a time. Anybody who tells you differently is a liar and is full of crap. Therefore, if you have time to learn one language, my choice would be VB - for the opportunities you describe. And of course, there is also the overhead of having to learn database concepts if you don't have that already.
>
>
>>
>IOW, even if VB or SQL Server do not become your poredominant development environment, the knowledge you gain will apply to other language platforms and areas of the MS world; VFP is not applicable as widely, and is going tgo offer few benefits outside VFP itself compared to VB.
>>
>
>Again, you are making the case why VFP is a not too wise investment for people joining the developer ranks....
>
>>
>If the target is an income in the next 6-12 months is the specific issue, well, you're dead on about .NET not being the way to go, since we're looking at a year or so before a live deployment goes, and having seen the MSDN distribution of the Whistler Beta at last, probably a good deal longer before the whole thing ready to serve to the general public.
>>
>
>I am not even going to waste my time installing the thing. I have done enough R and D for MS on my own time.....It is somebody elses turn. And FWIW, while I buy into some of the tactical aspects of .Net, I don't buy into the overall strategy...
>
>
>< JVP >