>The VB team and the C# team have different goals and focuses in some areas. C# focuses more on the pureness of the language and avoiding language bloat (fewer commands, more object based syntax, etc.). Most C# developers prefer writing their own source code to things rather than using libraries or higher level language commands that do things for them. The VB team is focused more in productivity, ease of use, ease of discovery, and higher level language features. VB 2005 has My dot making access to many .NET Framework and common features very easy and fast to use/discover, etc., plus many more code snippets for common actions/functions. The VB team likes the idea of query language embedded into VB to be more like what developers already know in SQL Server (SQL language, VFP, etc), while C# views it more like an object syntax into an API and lower level. There are some XML related features being planned for future VB that are much like TEXT MERGE in VB, and this is something that may
>not be in C# for example. The goal of the C# and VB teams are not to match feature for feature nor to match syntax, but instead to focus on their core audience of developers which has some divergence.
>
>In some cases, it may be that a C# developer uses VB for some components (maybe data querying for example) and simply embeds the various components into one solution (meaning, some written in VB and some in C#). Some of the VFP team developers including Calvin Hsia and Aleksey Tsingauz (Aleksey wrote the CursorAdapter, XMLAdapter, SQL language enhancments to VFP 9.0, new data-types in the VFP engine, etc.) are helping the VB team with the future data-centric programming features like referencing the VFP 9.0 C++ code base for LINQ query functions, SQL language implementation, etc. as well as making the IntelliSense in VB with data a first class experience. Many of the Sedna components (the ones that use .NET via interop) will be written in VB (mostly code name VB 9.0, the version after VB 2005) with the new data/LINQ features. Alan Griver and I have been talking about these .NET language divergence issues for over 3 years now, and only until recently have the differences been more
>noticeable (ie, data-programming differential).

I definitely feel more affinity to the VB approach than the C# approach on the LINK issue and in general. Maybe its just my age, but these days I strive for clarity above all. One reason I like VFP is that it reads like a sentence which helps me think more clearly.

Ken, you may mention something to the VB team that has turned me off since a long time ago: the need to use property GET and property SET routines to access and change properties. The VFP object.property_access() and object.property_assign() approach is much more practical because you only need to create them in exceptional situations. Looking at the VS.NET 2003 help I see that property gets and sets still exist, but I don't know if they are only optional now. I am sure the VB team can make them optional if they think that is important. Bill Clinton's campaign manager might have said "It's developer productivity, stupid".

Keep up the good work. I think you are adding real value to VS.NET and Microsoft.

Alex