In my first 2 years working with ISVs who were early adopters of the .NET Framework I think the most common question I was asked in an initial meeting was "which programming language should we use?" So there are many "it depends" but I finally settled on the following reply:
First I point out this is not such an important question:
" It is important for you to understand that the 'smarts' are not in the language but in the .NET Framework and therefore the choice of language is far less important than in the past. The majority of the time spent will be learning the Framework and not learning a specific language syntax so this really is not as important a choice as it might sound but it is a choice that needs to be made. I need to know a lot more to give you the right answer but I can give you an answer that works for most companies."
And then the answer:
"If your developers today use VB or ASP then they should go VB.NET. For everything else go C#."
Now this is the right advice for many companies - but clearly is sometimes absolutely the wrong advice. So let me elaborate the thinking behind this.
- A C++ developer will "never" move to VB.NET. So that leaves managed C++ and C#.
- Managed C++ in 1.0 and 1.1 is clunky compared to C# for writing managed code. So go C#. (NB: Managed C++ in VS.NET 2005 is very clean)
- A Java developer could go J# - but will likely pick up C# very easily. C# IMHO gets far more focus than J# from the community and internally - so go C#.
- A Delphi developer will see VB as a catch up technology and not be keen to go "backwards" (No matter what the truth is). Therefore take them forwards to C# - the newest language on the block.
- A VB developer will have lots of VB code. VB.NET can migrate this code. They are used to VB hiding some "pain" and indeed VB.NET still hides some "pain"
- A developer using some other language should probably go for the cleanest/newest language - and go C#.
"What are we coding?"
- If the application requires low level api access, to work with many existing C++ libraries, is super time/performance sensitive or needs to manage its own memory very explicitly - then Managed C++ may well be the right choice
- If the application has lots of existing C++ then maybe managed C++ is the best route. Although C# will work well mixed with C++ (likely migrated using /clr to managed)
- If the application integrates closely with Office or uses other products through automation interfaces, then VB.NET does a much better job than C# of hiding away some of the "pain" (C# doesn't handle the optional parameters "magically" as VB.NET does)
- If the application is lots of Cobol, Fortran etc and developers have these skills then consider one of the 3rd party languages that target the .NET Framework
Not a complete list - but hopefully gives you an insight into how I arrived at such a short answer. FYI around 50% of my ISVs are now C#, 25% VB.NET, 23% Managed C++, 2% other. This is a small sample - and hence could be way off what is really going on!! But I like statistics 🙂
- A book I would recommend is C# & VB.NET Conversion Pocket Reference which is a nice small reference for moving back and forth between the languages with ease.
- And have some fun with http://www.ellkay.com/ConvertVB2CSharp.htm and http://www.kamalpatel.net/ConvertCSharp2VB.aspx 🙂
Thanks for reading