Hi Martin,

>>>Anders Hejlsberg : I think interestingly that there's sort of a resurgence of interest in dynamic languages.
>>>
>>>Interesting atricle:
>>>http://www.microsoft-watch.com/article2/0,2180,1837434,00.asp
>>
>>I must admit that the fact that VFP's approach was named specifically made me feel somewhat validated.
>>
>>It doesn't matter how they reach it and whether they use some hifalutin names and justify the approach with some "new" research; as long as they end up with a .NET language that's tightly bound to data, in which you can embed SQL SELECT statements and also do macros like we can in VFP they will have a winner.
>
>Read carefully what he says: "I'd be completely adverse, for example, to a language extension that tied us —(one) that said, we're going to do data integration and it's going to be SQL with SQL Servers and that's what we're going to jam into the middle. Well, that would be the kiss of death for C#. Because then, it's no longer a general-purpose programming language."
>
>Yes, you'll get much of the power you want at some point, but I won't expect to have it in a familiar way. This would be a quite different approach. Personally, I really hope they would stay away from SQL. SQL has poor semantics and an inflexible structure for a programming language. I guess they could do it far better than that.

I'm not sure what you mean by this. SQL has been critisized by both CODD and DATE as a poor implementation of the relational model. However, it is the only broadly accepted 'relational calcalus' available. To come up with something better they have to do an about impossible job: create a perfect relational calcalus + a perfect record based DML. Staying away from SQL does not seem wise to me. As a .Net programmer you'll have to master SQL anyways, so why invent something else ?? And no, solutions in XML won't do. XML has not a very good reputation in the database arena. It is mainly ment as a standardized structured data carrier, not as database engine components.

OTOH, I can see the chalenges where the data integration has to fit the OO model of .NET. I really wonder how they will come out of this as relational data does not go along with OO very particulary well. In the late 90-ties there were many object-relational experiments which never really made it.

Some other problem they have to solve is the static typing issue, because with a SELECT * FROM Table, you simply do not know what to expect. It seems to me that something better than reflection has to be used to bypass compile-time checking for those cases, where you simply don't know the types at forehand (late binding com objects as well). They well may have to add some runtime type checking for instances where it simply does make more sense than compile time type checking.

Personally I don't really care about how the solutions looks like, but how it works ?? Is it as easy and powerfull as the VFP SQL/xBase dml ?? I guess time will tell, and I anxious to see how they are going to solve the obvious problems.

Walter,