Now in defining “best” one is not trying to ultimately define the best .NET development language there is, but more importantly is the intention to define the most appropriate and beneficial one for your use.
Speaking from personal experience as the guy that came from being a long and strong advocate of Visual Basic, when the advent of .Net and Microsoft Visual Studio first arrived it made for an easy and perhaps obvious transition for us to adopt Visual Basic .Net. And in truth, the path of least resistance is often seen as the most favourable. So naturally, I along with the rest of my company did just that.
So in beginning our journey with Microsoft Visual Basic .Net we quickly began developing new elements of our technology, whilst easily adapting to the new development environment and the minor semantics of the language. Now feeling marginally content that we had made the right technology choice and keeping pace with the age of emerging technology, we forged our way ahead. And on reflection at the time we were not alone in making this natural transition into .Net.
.Net development language- Keeping pace with change
After some time had passed on our journey into .Net (and some 50,000+ lines of code later), we soon started to see the emergence and popularity of other .Net languages beginning to form. Most notably that of C#. No longer was every website and code-snippet example proudly showing you the how-to solely in Visual Basic, now many were favouring C#.
The C# language had been something of a mystery to us leading up to this point and had been seen to be more technically challenging like that of C++. So in truth, it had been ignored and discarded as perhaps too “heavy-weight” for our needs? But over time C# soon became a common player in the technology space we live in, with every technical Blog post, code example and code snippet more commonly sporting C#.
Acknowledging the sea-change
Now by this time it was clear that C# was not just another .Net programming language, it was rapidly becoming the language of choice for the majority of .Net programmers. Visual Basic still had (and remains to have) a very strong following of programmers, but C# seemed to be leading the way for us to follow.
However as the owner of a technology company now deeply entrenched in Visual Basic .Net code, should we ignore this sea-change trend towards C# .net? Should we continue our path and investment in Visual Basic, or jump across into C#? Could/should we adopt both? Whatever the answer, the longer we deliberate this quandary the deeper we get.
Just getting the job done
Now its all too easy to long-term strategize about these kinds of decisions when often we also need to consider the here and now and simply getting the job done. Transitioning languages, re-training developers, re-developing existing investments, whilst maintaining existing technology all takes time, money and a huge lack of productivity. So often we don’t consider them because of the pressures of here and now. But will this decision come back to bite us later, maybe/maybe not?
What is perhaps a good strategy if you are just starting out, however (or even recently started) is to start the way you mean to carry on. Consider your options carefully and examine all the aspects you need both now and into the future (see Thoughts and Considerations below).
Make the change that’s right for you
So for us as a company, we came from being a development house largely entrenched in Visual Basic, then made the move to adopt Microsoft .Net with the use of Visual Basic .Net. Then Latterly transitioned our development from Visual Basic .Net to Visual C# .Net, and in turn have re-developed a large degree of our core technologies into C#.
- Am I/we happy with with transition? – Absolutely
- Was this the right move for us? – Unquestionably
- Is C# the right .Net Language for our business? – Yes, for ‘our business’ it most definitely is.
Thoughts and considerations
So here are just a few thoughts and considerations that might benefit you when considering the right .Net programming language and technology for your organisation or project?
Looking at the bigger picture
Here are a few questions you might want to consider?
- Availability of technical reference and resources in that language?
- Availability of technical personnel skilled in that language?
- Value of the IPR and resale invested in that technology?
- The future scope and longevity of that language/technology?
Mixing and matching languages
Now this article would not be fair and complete if the topic of mixing .Net languages was not given a mention. Technically it is possible within the .Net family of technologies to use different programming languages within the development of a single solution – by that I mean you can have some elements built in say Visual Basic, some in Java and some in C#.
Whilst to some this may be seen as beneficial, it can (IMO) lead to an increased overhead in maintenance and support of your solution, requiring your development staff to be multi-skilled.
.Net language disciplines
As mentioned above, we as a company and I as a developer/architect are now strong advocates for Microsoft C# .Net. But that’s not to say that other .Net programming languages are not of equal strength and capability.
However, one key element that I particularly like about the C# language is in the core disciplines it enforces. Unlike from what I recall of programming in Visual Basic (this may now have changed so I apologise for any miss representation here) where certain disciplines did not exist or were not enforced. Because this article is not intended to be deeply technical I will refrain from listing specifics. To read more specific comparisons of the two languages, see this Wikipedia article.
One such example that we identified early in our adoption of Microsoft Visual Basic .Net. was the way in which Visual Basic would permit interface programming techniques that were not universally accepted across all .Net languages – in turn leading to challenges in interoperability (e.g. other parties not able to adopt and utilise our technology).
The net result of enforcing such language disciplines results in the production of more structured and stable code.
In defence of Visual Basic.Net in this example, by not enforcing such language disciplines was a design element to allow for an easier adoption of Visual Basic by parties transitioning and upgrading their historic VB legacies.
Start as you mean to carry on…
…Without a crystal ball and the benefit of hindsight, it is extremely hard to know sometimes which is the right path for you? But making a considered decision and starting out on the right path will doubtlessly be beneficial.