C# vs. VB.NET
I often get asked this question: how do we decide between C# and Visual Basic .NET? (Not “Should we use C# or Visual Basic .NET?”)
I generally make the points that the languages are pretty much on par, feature-wise; that I usually see organizations with a VB legacy shifting to VB.NET; that organizations with a C++ or Java legacy usually move to C#; that the big learning curve for VB developers is OO and the framework, not the syntax change; and that an organization should stick to one language within some sensible boundary – an application, a team, a development group.
A new argument came to me when visiting a customer yesterday. When I said “you should stick to one language for a given group”, they said “what about components that are shared across the enterprise?” They were concerned that a group that’s using, say, VB.NET, wants to edit a shared component in, say, C#. First off, I made the point that a VB.NET developer is going to be able to read C# - the framework is the common language – so debugging shouldn’t be a problem. More interesting, though, is the point that components that are shared this way better need precious little editing by groups around the organization – they’d better be tested, tested, tested, and have a well-defined process for submitting change requests. Some of my larger customers are beginning to undertake efforts to build repositories of shared assets, and a strict process of ownership and control for those assets is a critical element for success. (Open source comes to the enterprise.)
