>
I think you're downplaying the similarities to Java and C++ that C#. Pick up books on UML, nTier, Design Patterns, and AOP; what languages are they based on?
>

But you cannot take the framework with you. I think you are over-valuing the langauge similarities.


>
Being familiar with the ECMA standard C# will be much more benificial than familiarity with VB.NET.
<

Perhaps, but I question the relevancy. When I go about solving a problem, I don't think in terms of whether what I am doing conforms with a world wide standard that has little or nothing to do with the issue. You are going to have to back this up with some concrete advantages. Supposed advantages in the air are worthless. On a day to day basis, what does it do for me. And, if the RAD aspects of VB outpace C#, would I eschew those because VB does not conform with ECMA? I don't think so..

<
That doesn't mean you can't use both (which I think you and I are in agreement on) but this whole "you don't need C#, the black art language" or whatever you're on is poor advice.
<

I did not say you don't need C#. I am countering the argument that people should not look at and useVB. I think people should learn both and use them when appropriate. The prejudiced view of C# vs VB, IMO, has been a real disservice. And yes, I do contend that some would love to keep the realm of development as a black art. On a variety of fronts, it presents more opportunity for some if folks undertook C#. I say, why not leverage what you know to learn dotNET today. Why is it wrong or how is a developer materially disadvantaged by adopting VB .NET as their first dotNET language?