Hi, John.

>I partly agree with Kevin in that some people put too much emphasis on LINQ to SQL, which is full of constraints, by definition. I guess that maybe LINQ to Entities -if the Entity Framework gets widely adopted at some point- can do a better job in this space.
>
>Better job of what? What sort of constraints? I know of the need for intermediate management of m:m, but what else? If you mean Kevin's inefficient SQL "crisis", you can overcome that using a technique I already described to him. If you mean the "limited" database options, MS says that's temporary. Is there other stuff? I'm all ears! BTW, I think Linq to SQL is very, very quick. We shall see. ;-)

The type of costraints I'm referring to are implicit in any type of Relational to Objects mapping, and are better describes (in extremis, maybe) by Ted Neward in his infamous "The Vietnam of Computer Science" whitepaper (http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx).

More than anything, this approach still doesn't solve the problem of schema ownership, meaning that it still leaves DBAs owning the physical schema and developers owning the object one. In that sense -although there is a long road still ahead- the Entity Framework is promising, as it provides a common model which can be shared across the enterprise, allowing DBAs to fine tune the underlying relational model for performance, partitioning, et al, without having to touch the model (for that).

> As far as I know -and I may have skipped something, for sure- Alan always talked about the VFP team involvement in the LINQ project recently (not in the inception).
>
>Some years back and immediately after his promotion YAG commented on plans to improve NET's local processing ability, specifically referring to VFP's memory/disk spanning as one of the top items on his personal list for ADO.NET. Sure it doesn't translate into "Linq comes from VFP" but I've never seen anybody saying that, apart from the ROFL'ers trying to set somebody up. Anders then followed up with a treatise repeatedly referring to FP as a model for the sort of language SQL features he wants to include in NET. Again, that doesn't translate to "Linq comes from VFP" but nobody ever said that. What is for sure is that these are the precise issues raised by VFP'ers (and which had been scoffed at and ROFL'ed at by certain NET fans as being completely irrelevant to NET) which are coming true, with reputable MS people having referred to FP when they discuss it.

Of course everybody inside Microsoft is trying to contribute with their own visions and experience to the core technology. Many of the ideas about local caching and the likes permeated ADO.NET and SQL Server (mostly in the Compact Edition). Again, this is something coming from many different angles, although it definitively strikes a chord with us VFP people.

I'm sorry but I don't think Anders ever referred to FP as a "model" for anything. What I'm sure is he commented in FP having a form of integrated query into the language, but that just in a mix of other things.


>As for Linq based on LISP: I suppose the ROFL'ers will love it, but neither Yag nor Anders have made similar comments about Lisp as far as I know, so the comparison isn't valid at all.

Oh... This is because whatt your ears filter when Anders speaks is everything about data. This is part of our natural bias in the VFP community. I heard im speaking of LISP and functional programming a LOT more than FP, which he just mentioned ocassionally a couple times. Believe me, the LISP crowd are maybe more excited about the latest C# and LINQ, although for very different reasons... 8-)

Regards,