Ken,

One of the things I see is that you are not offering substantive reasoning behind C# vs. VB .NET. Specifically, you are propping up C# over VB .NET in much the same way Kevin McNeish does in his marketing materials. Whether you realize it or not, you are parroting that same line of reasoning. Quite frankly, the reasoning is intellectually dishonest. i.e., it violates the same reasoning you demand in your day to day job. I would suspect that if somebody used that same line of reasoning on an issue that related to something you needed to accomplish, you would dismiss that person.

The sooner you look, and I mean really look at the issues and less at the marketing hyperbole you have been exposed to, the better off you and your company are going to be...




>I think that the VB.NET team is very interested in how VFP does its thing...
>
>I'm sure they are - I KNOW they are - and perhaps that's my point. If VFP team is getting tight with the VB .Net team - especially if that's where they're gonna land one day - then that would explain the bias I'm seeing
>
>I disagree. Namespaces are easier to deal with in VB.NET - the VFPToolkit demonstrates this well. And what about the tools that are provided <snip>
>
>Wow - I guess I'm having no problems with namespaces in C# - certainly no harder than a "set classlib to" in VFP.
>I just spent some time seeing quite a few things C# did that VB either didn't do or didn't do nearly as well - I would have to go back and look at notes to tell you all the details - but my point is that the "easier/better" thing probably works both ways.
>
>If you won't use it in a production app, don't you at least see it as useful in order to learn how to do things in .NET like string manipulation or accessing data? I think it's good sample code at the very least.
>
>Now this may be a good point! But, exactly why do you think it is easier to use in VB? What is difficult about using it in C#? It's just a set of classes, right?