>
As one who has long advocated VFP as a tool of choice, last weekend I attended a meeting where our company decided to standardise on dotNET in the medium to long term. This overturns pressure from funders to demonstrate a Java version of our core product.
>

>In the short term we will rapidly convert existing VFP functions to SOAP-style interfaces properly configured for consumption by whatever.
>
>Medium term we are looking closely at CLR languages to decide if and when we should translate. So far the answer is "look but don't leap".
>


Very interesting.... I wish you and your company the best of luck..

Looking and evaluating - but not leaping - that is a prudent strategy.


>With ADO.NET, for the first time I think it might possibly be as profitable to develop stuff we need as it would be using VFP. We could be boring and argue again about RVs etc (please no!) but overall I'm satisfied we can make the same $. So we're thinking about it.
>

It must be a cost-justiable venture before proceeding. Yet again, we agree!!


>You seem concerned that some people will become "hermits" by refusing to respond to the dotNET Microsoft path you describe accurately.
>

I am not sure concerned is the right word. I look at my efforts as helping to make sure VFP'ers get an opportunity to sit at the table and get their fair share. Some feel that the fact that VFP can create web services is the end of the story. There is no question that VFP being able to create and consume web services is a valuable feature. However, it should also be said that if you want to play in the VS .Net sandbox, you need to get into .Net. The myth must be dispelled that just because VFP can create/consume web services, it does not mean that magically, where VFP was rejected, it will all of a sudden, be embraced by companies that will go down the VS .Net path.

For a 5 year period, MS as a company, did not promote VFP. If not for the community, this product would have died a long time ago. The fact that VFP is web-service enabled will not reverse the damage that has been done. I sense a bit of optimism - perhaps over-optimism. The fact that VFP is web-service enabled means one thing - people that use VFP may continue to do so in conjunction with their .Net efforts such as ASP .Net. Companies that do not use VFP today will not - all of a sudden - start using VFP because it is web-service enabled. I guess I am trying to temper some of the enthusiasm with a little reality. At the same time, I am trying to do what I can - as a MVP - to help "bridge the gap". Show VFP developers how VS .Net works - from a VFP developer's perspective. I am not advocating that people ditch VFP in favor of VS .net. Rather, I am advocating that people learn VS .Net and in turn, learn how VFP can work with VS .Net. And, if it happens to be the case that the VFP developer is prepared to take advantage of non-VFP alternatives - so be the case. In that instance, the developer is the big winner.

>
Well, there are some happy FP2.5 hermits out there and there will be some happy VFP Fat Client who keep using local tables forever. We need them. Sometimes Hermits are useful for a "sanity check" when the world goes mad and we forget what really matters. They might even be right.
>

I respectfully disagree. What you need are people that embrace new technology in light of reality. People who keep their heads in the sand are not a good reference points. I want to hear from the guy who checks out and evaluates new technology from a rational basis. I don't care about the opinons of the luddite - the guy who is a hermit - the guy who continually eschews new technology. At the same time, I don't care to hear about the kool-aid drinkers - the people that blindly follow - the lemmings.

I am a centrist - not a lemming or a luddite. One foot grounded in today/reality and the other foot mindful of the future. The centrist view is the one that is usually most pallatable...

>FWIW, Microsoft is completely supportive of our company strategy including the VFP part.
>

You are contemplating the move to VS .Net of course MS will be supportive < g >


>Not everybody agrees about dotNET- see http://www.vnunet.com/News/1127410 - but I've looked at this carefuly and feel satisfied.
>

I read the article you cite. I disagree with his assertion about how there will not be a desktop in the enterprise. That is the key to his argument. If the desktop in the enterprise is relevant - his entire argument falls apart.

As a counter, I would talk about the whole .net architecture, that in many ways - it either alleviates or will alleviate distribution problems. Distribution is by far - the big problem with "fat-client" applications. The paradox of course is that "fat-client" apps have richer interfaces and make it easier for the developer to control the environment. This is why I think windows forms are one of the real compelling stories in VS .Net.


>As for CLR languages; IMHO that damned ; is a step backward towards arcane Z80 Assembly Language, in 2001 we should be able to express what ; means a little more obviously. No I don't want to argue about that!
>

I won't argue that either. I agree with you 110%