Ok, but like it or not, I think the general consensus is . . . the iPhone interface was radically better (and now people are copying it and in some ways leapfrogging it).

I'd like to see a survey of VFP developers who've worked with ADO and other data access techniques in other languages and see how much support you get for your "their methods were neither inferior nor superior to what we were doing with VFP" statement. Frankly, I'm surprised you make a statement like that. You did use VFP, right? <g>

Obviously, we need to be open to change. I've been using a MacBook Pro since December. I use VMWare Fusion to run a Win7 VM on top of Snow Leopard. Having been a Mac fan from way back - but not really able to program for the Mac due to market share realities - I expected to love it. I don't. One reason is that Windows has gotten so much better. It was easy to see how the Mac beat DOS and early Window versions. These days the differences are more subtle. But there's also the issue of the Mac doing things that aren't as intuitive or as integrated as the Mac fanboys like to proclaim. I've found a number of frustrating issues that aren't about just being set in my Window ways. So despite trying to be open and going into it with a positive view of the Mac OS, I've found it to not be all it's cracked up to be (not that I hate it completely). Likewise with .NET . . . just because someone doesn't like .NET data handling doesn't mean they are just wanting it the old way. They might be very open to it and still feel that it is harder than it needs to be. Why does something have to be difficult to make people feel it's powerful and sophisticated?


>I disagree with your statement that everything before the iPhone had an inferior interface. I also disagree that .NET is inferior at data handling. It is different. It is not what we've been accustomed to for many years. It is hard to change how we think, but that's exactly what it takes to move from VFP to .NET.
>
>One of the problems I see with VFP devs moving to .NET is they want to do things the way they did for years. In know...I was one of them. I see it all the time in forum posts. VB6 developers were able to manipulate data. Delphi developers were able to manipulate data. Other developers were able to manipulate data. Their methods were neither inferior nor superior to what we were doing with VFP. They were different. They did data manipulation on the back-end server. VFP devs want to do it all local, like they always had before.
>
>I just started reading the book "Apprenticeship Patterns". In the preface, Ward Cunningham tells a story of he and Kent Beck talking about how to change the way people write programs. Ward said, "Never mind reality". In other words, you need to think differently to make big changes.
>
>>Yes, he is looking at it from a VFP perspective. That's to be expected, of course. We have to look at the reality of a situation and not how it could/should be (except for efforts to submit suggestions and encourage new and better features). However, is your post saying "just get over that ease of use stuff and accept less?" Is it like telling the iPhone user (before the more capable competitors arrived) to just change their perspective and accept the inferior interface of a different cell phone? Granted, you might respond by saying there are more sophisticated data-handling capabilites in .NET in some ways, yet where is the ease of use? We've done sophisticated data-handling in VFP for quite some time and have not had to struggle to the extent you do in .NET. Wouldn't you say that VFP developers all go through this and feel like they've stepped back in time - they feel like their data handling capabilities have been hobbled? Isn't it frustrating when you know how it can be and others in the industry - those who've never used VFP - just seem to accept it and never expect more?