>As I've stated in other threads...it's coming...and before VFP goes off support.

I first have to see. My question is whether it is going to be MS technology at all. It might be some 3rd party vendor who will fill the GAP (ethnologica ??). 2015 is a long time to develop a new language. As mentioned in other posts up here, LINQ as it currently is in the pipeline (we are not even talking about a release yet), is not the magical silver bullet we are waiting for either.

Personally I've got a big axe to grind with any language that FORCES (not talking about optional) the use static typing JUST FOR THE SAKE OF KEEPING THE COMPILER HAPPY. That is not what I call progress. In a world where office integration is the norm, we don't want to program for a certain office version so we have to jump through hoops to support late binding to avoid versioning problems. BTW this applies to all kind of COM integration. Then we have some crowd that have been arguing about remote views being inflexible and slow and now are using typed datasets, which are very familiar to VFPs remote views. For dynamic SPT retrieved datasets, you again have to jump through hoops to get at your data, because the compiler does have to know what TYPE it is. Arrrrggghhh..

I've delt with such languages before and occasionally I still do (C/C++/PASCAL) and it is just plain silly in database applications. I'd expect a 'New technology' language to make my life easier not harder. Sure there are some things I'd like to see in VFP as well (Optional type compile checking with an analysis tool) but hey no platform is perfect.







>>Ironically, I would like MS to take a look at VFP and really understand what makes this product so special (See Randy's and John's reaction on recent events) and do something with the conclusion rather then jumping in a quick defence and offer something inferiour as an alternative.