Hi Metin,

IMO, There is no point in moving VFP to .NET. VFP will lose many of its data centric features and other characteristics. What is the point anyways. If you want .NET features in VFP, then go to a .NET language like C# or VB.NET.

VFP is data centric. AFAIK none of the languages moving to .NET is really data centric. .NET is immature when you look at this area.

>Clipper didn't move Windows on time, so VFP don't move .NET on time. Did you read Ken Levy "VFP won't a 64 bit developer tool". Microsoft focused .NET and even Delphi moved .NET.

I did read this comment of Ken, yes. I'm not sure what to think of it. I'll ask Ken personally when I meet him in Amsterdam, later this month.

One possibility is that .NET will evolve into a data centric platform through time (see Kens statement about implementing features found in VFP into .NET), and is a viable alternative to VFP and Microsoft will stop development of VFP.

If this is true, then we have to jump to .NET or another tool eventually, yes. But IMO, the question is not *if* we have to jump ships, but more *when*. .NET in its current state is crude if you'd ask me. There is still a lot to be desired for ones that have been spoiled with VFP. There is a lot to happen on the .NET platform. Again look at the technical articles about AVALON, YUKON and LONGHORN. They will tell you that .NET is going to change the way we develop applications significantly.

Are you really willing to invest time into a tool that is going to change dramatically within the next few years ? will you ? If you can afford, just sit back and watch what is happening. See projects fail in .NET, learn why they failed, see the tool evolve, see how the support for the platform evolves, see how best practices are beeing developped. See how .NET is accepted by corporate companies.

If you've got a fair investment in VFP code, there is no rational in panic. The fact that the hype is doing .NET is not meaning it already is a viable tool for what you're doing now. Evaluate.

There is nothing wrong in keeping up to date in .NET technology, but it is IMO stupid to think we have to abondon the ship right now because Microsoft is pushing .NET, and fearing that VFP will be discontinued after VFP9. FUD, never is a good reason to base any rational decision on. We know that VFP has been upwards compatible for 9 years now (VFP 3 - 8) with very few problems, and I don't think this will be different for future versions. Can you name any other 4GL tool with such reputation ? Do you really think that current .NET applications are going to be upwards compatible into next generation of .NET ? We've had two .NET versions 1.0 and 1.1 that were not compatible (As far a my limited knowledge in this field goes), IOW, so far I'm not that confident.

And *if* VFP is beeing discontinued, your VFP skills might prove gold to you. It is well known that niche markets pay a hell lot of money to maintain their applications. So as a VFP consultant you might see golden times as the majority of VFP developers are moving into the imense pool of .NET developers and all those VFP applications still have to be maintained. Look at what cobol programmers earn a month.




Walter,













>VFPs problem is circular threaded with marketing and technical. :=(

Name the technical? The technical arguments in flavor of .NET do not convince me. They're about irrelevant when it comes to developping data centric applications.

Walter,