>Ahh.. thanks, I did not know that...
>
>Walter, your best course of action is to stop posting on the topic and start working with it.

I don't have the luxury to learn a language that I'd probably won't use. Why would I? I've got a few year of VFP programming ahead and will have to make a decision somewhere down the road what to do next. The spectrum of suitable RAD programming tools probably would look more diverse than it was looking a few years ago and probably even today.

Also I do have a problem with the "You should just starting working with it" attitude. In that sense you should start programming in all even remotely suitable languages, learn all of them in depth and then make a decision. We all know that no-one is serious about that.

I jumped in on the statement "I only hear VFP developper make this statement". It was not restricted or specifically aimed at any other language. Only about that statement. You can read my reply to gary to see where I'm coming from.

Second, I made a statement about static versus dynamic typed languages and that both are technically capable to do code and compile time checking... Again not specific statement about .NET at all. I made the statement about code time type checking without knowing it was implemented in VS 2005. Great, to know... but not so great to find that it only is restricted to a few languages. I guess it will take some time before other languages will come with this feature.

Of course, .NET-ers will jump on the statement because of feeling attacked, irregardless of what it really reads. Reading the message still seems to be a problem on the forum here.

>You still continue to believe (and it is a belief) that LINQ changes .NET developers' views on how much processing should be done on the server, and you (and others) still want to exaggerate the 'attribution' of VFP to the entire thing.

Do I ?? I stand behind the statement Anders made.

>LINQ is far more about giving developers better (and more uniform) capabilities to query existing objects that they're already bring back from the server (or creating manually)...be it datasets, XML, arrays, objects, etc. Not many people that I talk to are planning to use LINQ to increase the amount of data they bring back from the server.

You've lost me here. LINQ is about being able to access data in a relational manner, indeed whether it comes from a SQL server or another data source.


>Those who continue to believe in strong parallels between LINQ and VFP are less likely to 'get it'.

I know the things are 'different' in terms of implementation and even application, and I don't think it perfect, however it is the only thing in .NET (that I know off) that handles data from a higher (4GL) abstration level. IOW, more specifying what you want, rather than how. It is one of the things that I will heavily use in any new language, because I'm heavily relying on data, whether it is normal or meta-data.

>(That is not to say that LINQ has zero influence from VFP - but to listen to some VFP people, you'd think it was the model for LINQ.)

I know it was not, since its model is way and way different, but so is ADO.Net. I do regard them inferiour to the VFP implementation of VFP cursors and the local database engine, but at least .NET is beginning to offer something that at least smells like something I could use in the future.

Walter,