Fred,

Exactly! I am thinking of the hundreds of thousands, maybe millions of VFP applications out there, running small and midsize businesses day in and day out. If they need to press the reboot -button and start re-writing their applications form the scratch, it will be one heck of a job. This is the primary reason for a VFP compatible offering right now, and it is only after this that the language comparisons come to play.

To cover some of the arguments presented here over the many days and how I think a .NET VFP compiler can answer them:

1. VFP will be around for a long, long time
- Maybe. Depends on what happens with future Windows version upgrades after 2009 (or maybe 2015). However, it is hard to build a business long term on "maybe". It is much better to build a business on "95-99% future compatibility" with existing business.

2. Other languages can do many things much better than VFP
-Yes. And VFP can do many things better than other languages. "Anything you can do I can do better", as the song goes.

3. You should move along with the times
- Yes. As Darwin would say: "Adapt or die." But ideally you'd do it in an organized way, "slow adaptation". The dinosaurs didn't have a chance due to an ecological catastrophe they couldn't cope with. But luckily we foxpro dinosaurs have plenty of time to adapt, and the best way to do that IMO is a slow drift from what we know to what we should know, using what we know, and expanding it from there. IF VFP .NET can lead us to the .NET promised land, more power to us (and less disruption to our business)

4. You can't hold Microsoft responsible for discontinuing a product
- No, you can't. At least in a strict business sense you can't. Social responsibility is a different issue, which would be NICE (as in a company sending their people to volunteer rebuild the Big Easy after the hurricane), and it DOES earn a company plenty of PR and goodwill points, many of which are redeemable for dollars. But we don't and can't EXPECT big companies to be responsible: they are, after all, guided by the infamous Invisible Hand of Market Forces.

5. People new to programming will not choose what they perceive to be a dinosaur language, they go "sexy with Java, man!"
- Probably so. But if there WAS a dinosaur language that morphed into a modern, super-flexible, datacrunching, interpreted, backward-compatible but forward-looking language named, oh, say, "Espresso", maybe they wouldn't notice that the underpinnings on this puppy are actually your Dad's Oldsmobile.

6. Programmers in developing countries now have a lot of open source systems to choose from, so VFP is not needed there either
- Wrong. There are SO many people using VFP in South America and Eastern Europe that it is not even funny (by this I don't mean to imply that ALL South American or Eastern European countries could be categorized as "developing'). And while open source offerings are a good thing, VFP is definitely much more approachable than most, because it is an easy language to learn, it has a super fast database, and a very helpful and jazzed up developer community all in one.


Pertti






>The point here is not that new code could be written in whatever language with only minor syntactical differences, the real attempt here is to not lose the entire value of the millions of lines of existing code. This is something that Microsoft seems to "forget" at every level when a new version of their products are brought out. Ever have Excel or Word macros that broke between versions? And how about even their versions of the C compiler and MASM? VFP has been very good maintaining a pretty solid "backwards compatibility" considering the very different philosophy of Windows programming vs. DOS programming. Is 100% of the code transportable? Of course not, but it all wasn't disposable, either.
>
>
>>I hate to be a naysayer here, but 'what's the point?'
>>
>>Assume for a minute you could indeed duplicate the full language and make it more or less work the same as VFP. What do you gain?
>>
>>The real key and really the only feature that VFP has that .NET lacks is native data access language to run dynamic inline SQL and Data commands and access local cursors. Nearly all of the rest is just minor syntax (with the exception of evaluation and dynamic execution which likely wouldn't work without runtimes either).
>>
>>No matter what you do you are likely to loose that functionality with any compiler's/tricks/workarounds. Without that what do you really have? Just another language (JAL) in .NET that isn't any better suited to deal with everyday programming tasks than is C#/VB etc.
>>
>>Whether I use a function like your Between or overloaded versions written in C# code (which would be more code but not much) what does that buy me? Very little.
>>
>>To do this right a lot of work would need to be done along the lines of IronPython (dynamic language support for .NET) to provide the untyped/duck typing approach that VFP uses and more importantly it would require a local data engine and full SQL language parser to get the DDL stuff to run along with a local cursor engine.
>>
>>The latter is no trivial task as Microsoft is now finding out as they are building LINQ and DLINQ and trying to shoehorn a dynamic syntax into a static language. There are many, many gotchas and tweaks required to make this work and that is really the key feature that .NET has been missing IMHO.
>>
>>All the rest is negliable... VFP is a nice all around language but the only unique feature (to xBase) is the sql data language and local cursor engine. Take that away and you have an average environment that is not anything special over other tools and getting up to speed is a matter of syntax.
>>
>>VFP is a great tool - if you want to use it, continue to use it. It's not going to die out over night with official support way off in the future.