>>1. It assumes that new/advanced technology is not available.
>
>Avalon and longhorn are not avialable.

True, but you seem to lump .NET in this category...



>>2. It assumes there is an absolute definition of "mature". One can credibily argue that .NET is mature. It has been out for several years now.
>
>Mature means that there are no fundemental changes in the loop as that gives you a total different viewpoint on development with this tool.
>

Cite your authority? Or are you just stating your opinion?


>>3. When technology becomes mature, it by definition, is no longer new - although it may still be advanced.
>
>True, so what is the point?

That your premise is logically flawed. You stated earlier that new/advanced tecnology should only be used when it is mature... One necessarily eliminates the other. i.e., something can't be new and mature at the same time...


>>4. When VFP 3 came out, it was both new and advanced. And...in spite of this, it was advocated quite heavily.
>
>
Thats why I never released any products on VFP3 because of performance and resource problems. I got in on VFP5. There is also another difference.
>

OK then...there should be no issue since .NET has undergone a rev since it was first released...

>
There was not much of an alternative when doing desktop applications at that time. And seriously, when having to choose from upgrading my existing application from VFP 6,7 and 8, there is no way I´m going to upgrade them to a development tool like .NET unless I have no other choice. It takes too much time. I´m not sure about you, but I´ve got more things to do, than just spend thousands of hours in doing webforms, while eventually I want them into Avalon...
>

So the real issue with .NET is not that it is not mature - but rather, because it takes too much time.

Also, you state you are waiting for Avalon. Yet, if you apply the same logic then as you are today, you will say that Avalon is not mature...


>
Also, .NET is immature on a number of aspects, which are debatable but many have agreed upon inferiour data binding, resource consumption, the absense of local database engine, RAD application provisions. So what do I gain ??? Nothing. I loose.
>

The issue with data-binding is really an issue of implementation - which is a problem that has been solved in a variety of ways. Personally, I think way too much is made over the issue - again becuase it has been solved.