Rick,

Not to argue your points, and how could I, they are all true.

The main reason I and many others are looking for a VFP replacement right now is our worry about the legacy code. MS has generally been very good about backward compatibility, almost to a fault at time (witness the Vista disaster, partially caused by backward compatibility maintenance issues), but when they announce the end of support for VFP by 2015 (if not earlier), a reasonable software business owner starts looking pretty hard at his/her options. One is to rewrite the many existing applications in some totally different language, another is to transfer them to a language that is as similar as possible to the current language, i.e. VFP. If VFP users consisted of a few thousand developers in all, it probably wouldn't make much sense to try to re-create VFP in, say, .NET. But given that there are somewhere between 150,000 to 500,000 VFP users (depending on who you ask and how you count), it is a different story. Rather than pushing all of these people over the edge and telling them to swim to the next boat, why not give them a lifeboat for a controlled transition?

Most VFP users out there don't have the luxury of learning new languages overnight, or even over a long period of time, because they have a business to run and existing apps and clients to take care of. But if they can be eased into a new platform (e.g., .NET) while being able to maintain and evolve their legacy code, now that would be paradisical (like living on Maui) :-)


Pertti



>Fred,
>
>I agree.
>
>But again if you look at your existing investment of code that code isn't dead. It can continue to run and it can be accessed externally.
>
>Also remember that 'developer value' doesn't go away at all. Your skill set with Visual FoxPro and the business knowledge will serve you very well with anything else you might try your hand at.
>
>And if it really comes down to leveraging existing FoxPro code - you can also still do that via COM. Just about from anywhere is your FoxPro code accessible if you really can't live without it although I'll be the first to admit that this is suboptimal...
>
>+++ Rick ---
>
>>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.