Ken,

Nope, don't miss Philly at all... because I'm still here in Philly. :) Well, just outside of Philly, that is...

(I'm trying to understand "the other side" of this argument that's going on about VB.NET vs. C#, so please allow me to play devil's advocate with you - no attacks about your lang choice will come from me. Use what you like I say!)

I understand what you're saying about "pressure from the VFP team ... to push VB as the .NET language of choice." First, why would you question their motives about that? Don't you feel like there must be a good reason for it? Have you heard any reasons why Ken and others feel this way?

Okay, here's my take: I've heard public rumblings (ramblings? <g>) about how VB.NET and C# are supposed to "diverge" in the future... it was an article that came out (I don't have the source, sorry) while I was on the road presenting the .NET dev tour. The article speculated that, while today these langs are virtually equivalent, they would become different languages in the future. In other words, there would be features that C# would get to make it more "C-like" while VB.NET would get more RAD features. To me, this makes sense, because while both languages can use the framework and both can compile to IL, they can implement that in totally different ways if they want.

I'm learning VB.NET for two reasons: one, I find it to be more VFP like than C# is. You may disagree with me on this one for sure. Two, I feel that if the langs are going to get more diverse, I personally don't care about more "c-like" features, I care more about RAD features - at least for the majority of the work I do. In those cases where I might want more "c-like" features, I think I'm comfortable enough with C# to do it. And besides, I can learn the .NET framework in either language, so I'm not sweating my choice for any reason, whether it be technical, political, business, or whatever.

And I like how the VFPToolkit works under VB.NET better than C#, too. :)