>>>> I was suggesting that M$ go the other way: incorporate VFP's functionality into it's .NET family of languages. <<
>>
>>What is in VFP that isn't already in .NET?
>Mike;
>
>1. Maturity.
>2. Reliability.
>3. Flexibility.
>4. A proven track record.
>5. Lack of "The Unknown".
>6. Deployment of mission critical applications.
>
>Just starters. :)

And an excellent start too, Tom.
I've been reading up on ASP.NET (decided to start there (and end there for the foreseeable future < s >)) and the book I'm using delves LIGHTLY into ADO.NET. They gloss over (i.e. "beyond the scope of this book") it but mention that all such data access is DISconnected, thus raising the possibility of update conflicts. They say this but nothing more.
It just seems to me that this simple fact is, in and of itself, material in changing design tactics from what is the more traditional approach.

I admire people who are jumping into .NET with abandon but quickly get very skeptical when they (some of them at least) proclaim (or at least state) that they can easily write any application using .NET facilities.
I find myself wondering how that can be when .NET itself is still actually at the womb stage of development (probably still doesn't yet have all of its arms/legs/fingers/toes) and also when it has taken me years, literally, to become proficient in any one of the languages that I have learned.

I wonder what acronym, like "FUD", can be applied to all of this .NET newspeak??? Maybe we should have a contest to come up with one.

cheers

>
>Tom