Craig Andrea is complaining about a unsavory bug in EIF's high-speed trace service. This is a major problem, because, in my mind, the service is the key enabling feature of EIF. Previously for commercial products I used a proprietary NT Service-based library, Diamond Sierra's Paul Bunyan, to great effect.
The interesting news is that the Enterprise Framework will be replacing EIF, according to a commenter to Craig's post who is in the know.
I've been accused of language bigotry. I rather think I'm engaging in long range business planning in regards to my software assets.
Rather than compare language features and syntax (though you can do that here), I think someone in my position (enterprise technology architect) needs to look at things from a business and portfolio perspective. Here are some important factors from a planning perspective.
- C# is an international standard. While certainly not always a good thing (cf. XML Schema). An international standard whose innovation is efficiently managed by a for-profit entity (as I previously alluded) rather than a bloated bureaucracy is, indeed, a good thing.
- The Developer Tools Roadmap specifies that C# is intended for class library development and VB for RAD development.
- You are more statistically more likely to get high quality developers in the C# world than in the VB world. This is simply a corollary of the previous point. It is not a statement of what “should be” but of what “is”. Business decisions need to be based on pragmatic foresight and reality, not purist absolutes.
- C# has already been released on other platforms (Mono 1.0) and, therefore, has much greater potential for widespread adoption, not only by developers but also by platforms. For example the My namespace is Microsoft proprietary and does not have a great probability of being maintained outside of the MS VB team.
- C# has lead in the language extension arena. You don't see MSR or other research groups extending VB for new language ideas, for example. As mentioned in my previous post, the “Convergence” has already resulted in nullable types in C#; you don't see it in VB. Just look at the list of new features for VB 2005. Looks like a lot of catch-up to me. Again, this is a language/feature comparison, but rather a strategic long-range planning issue.
True, it all compiles down to MSIL, however, people don't code in MSIL and the longevity of the codebase is an important asset choice for a corporation. I think the issues presented above have bearing on the issue and point to a strong conclusion.