The “native” .NET language?

In the comments on my post on language choice, Patrick asked “isn’t C# the language that’s most ‘native’ to the .NET environment?” Christopher then follows up with a related question as to whether developers should use functions in the System namespace instead of ones in the Microsoft.VisualBasic namespace because the former might be faster. We see these kinds of questions fairly often, so it’s worth discussing them a little bit.

Before going any further, I’d recommend that people who have questions like this take a look at an article that Derek Hatchard and Scott Swigart wrote for MSDN entitled “Visual Basic .NET Internals”. It looks at a bunch of these issues in detail and is an excellent place to start on this question.

The bottom line, though, is that there is no language that is ‘native’ to the .NET environment. While it’s certainly true that there was no language called ‘C#’ that existed before .NET came into being, one of the major selling points of C# is that it is an amalgm of the syntax and features found in C, C++, Java and VB, adapted for the .NET platform. In that sense, it is exactly like Visual Basic on .NET – an adaptation of a previously existing language (just as C++ and Java were, in turn, adaptations of C, which was, itself, an adaptation of prior languages). Both C# and VB were designed to work well with .NET, and developers can choose either language without any concern about access to the fundamental capabilities of the .NET platform, because they both compile down to IL in the end. The only differences you’re going to see between the IL the two languages generate is when one language does something more for you than the other language does (or we have a bug, in which case, let us know about it).

The question of the Microsoft.VisualBasic namespace is similarly straightforward. The base class libraries (i.e. the System namespace) provide a huge amount of functionality which both C# and VB give you full access to. The functions in the Microsoft.VisualBasic namespace are built directly on top of the System namespace and provide functionality that goes above and beyond the functionality that the System namespace provides. As such, there is no real reason not to use the functions there because they provide you “all the features of the class libraries and more.” (And we’re going to go even further in VB 2005.) Having said that, there may be situations in which you may want to sacrifice some of the extra functionality for a little more performance. This is the same kind of tradeoffs that you have to make with the System namespace, and so if performance is critical, it’s always important to understand the functions that you’re calling (the paper linked to above talks a lot about this).

The problem with blanket pronouncements like “always use CLR functions instead of VB functions“ is that you can easily shoot yourself in the foot without knowing it. One suggestion I’ve seen in more than one place is to use the functions exposed by the Convert class (a CLR class) instead of the intrinsic conversion operators (CInt, CStr, CLng, etc.) exposed by the VB language. This is supposedly because the CLR functions are going to perform better than the VB “functions.” The problem with this is that the conversion operators are true operators that compile down to IL instructions while the Convert functions are still just functions. This means you’ll get significantly worse performance by calling Convert.ToInt32 instead of using CInt. So it’s always very important to know what you’re doing when you start tackling issues like performance.

So, in the end, there is no “native” language on the CLR and performance is something you’re going to have to think about no matter what language you choose. (In fact, I think I should add a rule #0 to my “Ten Rules of Performance:” When it comes to performance, beware rules.) There are certainly lots of other factors to think about when choosing between VB and C#, but I don’t think these are two of them.

43 thoughts on “The “native” .NET language?

  1. Pingback: VS Data Team's WebLog

  2. Pingback: help.net

  3. Maxim V. Karpov

    I say, Russian is Native Language for CLR ;). Well, I am sick and tired of people looking into what lanaguge is better. I know that most folks convert to C# simple because it pays better! Well, then of course you have to claim that it is supurior theb VB.NET. You can developer with C# and be a shitty coder.

    Anyway, great post and to add about convert function I want to point to my post from awhile back, where I compare all of the options for VB.NET developer to convert data types http://ipattern.com/simpleblog/PermLink.aspx?entryid=7

    Maxim

    [www.ipattern.com do you?]

    Reply
  4. Pingback: Code/Tea/Etc...

  5. Louis Parks

    I wonder what it means to be a "true operator". Isn’t an operator, in the end, just a function with some syntactic sugar (just like a property is)?

    Reply
  6. karl

    In The Mythical Man-Month, Brooks says that "conceptual integrity is the most important consideration in a system design". It seems to me that C#’s integrity to the .Net framework is [?slightly?] more refined.

    A recent example that I ran into was with case-sensitivity. While it’s easy to pronouce that VB.Net’s case-insensitive nature is great, it doesn’t take very long at all to get back into the case-sensitve frame of mind. However, most things in the .Net framework itself are case-sensitive. This can lead to errors when in a case-insensitive mode. The specific example was that I had a namespace in a number of places, but in a single instance I accidently put the first letter in lower-case. It turns out that VB.Net’s behaviour is to make all matching namespaces lower-case. This in turn broke my calls using System.Activator. I find myself falling in this pitfal each time I run into something case-sensitive in the .Net framework (XML attributes, configuration files and so on).

    Karl

    Reply
  7. Robert

    The upcomming namespace ‘My’ sounds really exciting. But is it really just for VB.net? Will we have to start choosing our language based on which API we want, not just which syntax we prefer? That would be disappointing.

    If My is made part of the Ms.Vb.dll assembly, is there any downside to, or legal restriction from, referencing it from c#, et al?

    I just tried calling the VB "Left" function from MC++ with no problem….. just another dll to load.

    Reply
  8. Louis Parks

    Karl, as I understand it, the CLR itself is case insensitive, so you should have no problems in code, I’d think. Whether written in C# or VB, the IL shouldn’t care about case. Perhaps someone can correct me on this?

    In the case of XML, I understood that XML is case sensitive, though not all parsers care about that.

    Reply
  9. Bill

    C# has the "using" statement while VB.NET doesn’t. It’s damn too important for multithread apps and server systems.

    Reply
  10. Anand

    Robert, AFAIK, you can reference the Dll and use the My namespace from any language. Paul has a prev entry on some things that may not be avbl in C# as quite a few things in the My namespace are dynamically loaded based on the Project type etc.

    Reply
  11. Jim Arnold

    "The problem with this is that the conversion operators are true operators that compile down to IL instructions while the Convert functions are still just functions. This means you’ll get significantly worse performance by calling Convert.ToInt32 instead of using CInt"

    Come on, that’s a blanket statement in itself (and arguably bogus). It depends entirely on what types you are trying to convert to/from. Sure, converting, say, a Long to an Integer will use conv.i4, but so does Convert.ToInt32(Int64)! Doing CInt("123") will use Convert, Double.Parse() etc anyway. And if you’re using weak typing, there’s the overhead of trying to figure out what type you’re trying to convert.

    What do you think these "functions" compile down to anyway? Martian?

    Reply
  12. Karl

    Isn’t a major benefit to use the Convert.ToXXX functions that you have more control over culture, namely the 2nd parameter…not sure what the behaviour of the cxxx is.

    Reply
  13. Pingback: Pretty stupid for a smart guy...

  14. Daniel Jin

    only problem I have with VB.NET is that it’s so damn wordy. ever seen generics and nullable types in action in VB.NET? my god it’s a mess. how do you write clean, readable code in such a language?

    Reply
  15. paulvick

    Indeed, when converting strings there is not necessarily an advantage in using the conversion functions over the Convert class because they both are functions (with different semantics, though). My point was mainly concerned with things like doing Integer to Long conversions. There operators are better than functions because the operator compiles down to a single IL instruction and the Convert function compiles down to a method call which is bigger and has greater overhead.

    It may be possible that the JIT inliner will inline the call to the Convert method, but since the whole point of the discussion was that people were avoiding CInt because it was "less native," it seems like an ironic argument to make. As a rule of thumb, too, I try to avoid relying on inliners as much as possible because their behavior can be, well, pretty arbitrary. But that’s just me.

    Reply
  16. Sriram Krishnan

    I’m a big VB guy myself. But it is easy to see why this myth is perpetuated. Check out Microsoft itself. Of all the teams using managed code, how many teams are using VB.NET for development? During the "Lap around Longhorn" during the PDC, I seem to remember a lot of C#….

    If you want more people to take Vb seriously, Microsoft has to show that they trust it enough to use with their own products

    Reply
  17. yag

    Sriram – you bring up an interesting point. One thing to note, however, is that our product developers used C++ before, so moving to C# makes sense. Our in-house developers used VB6, and many of our in-house IT applications are written in VB.NET. We’re just doing what we tell our customers. <g>

    Reply
  18. Schneider

    VB does a lot of things I don’t want to, and C# can’t seem to figure out:

    get/set, adds End If, Next

    Adds "()" after methods.

    Context help is much better In my op.

    Most of these seem to be a feauture of the IDE though..

    Case sensative is a wast of time, seen lots of bugs due to this. Most C#/C++ like it, they make thie private members lower case an public Upper case, I just use m_ .

    I like the syntax in VB better, End If, Next t, End NameSpace, are much more descriptive than:

    }}}}}}}

    If I lose my ";" key I can still code.

    Some things in C# are better though:

    Notifies developer when a function does not return a value.

    Some things MS should have just made the same between the Languages, Keywords, IDE functionality.

    IDE features different:

    Events builder

    Project properties

    Error messages (get to know them in one, then you know them in all)

    these are just a few I could think of…

    I use both C# and VB at work. I still like VB better.

    Schneider

    Reply
  19. Pingback: Frankie Fresh's Blog

  20. Eric Mutta

    Paul:> As a rule of thumb, too, I try to avoid relying on inliners as much as possible because their behavior can be, well, pretty arbitrary. But that’s just me.

    You are not alone! I’ve noticed that inlining seems to be done when the body of say a function, only consists of a Return statement. However there are several times where that isn’t possible and I so wish we could manually request inlining.

    Paul, have you ever given that a thought? Any chance it will ever show up in VB.NET?

    Reply
  21. Eric Mutta

    Schneider :> If I lose my ";" key I can still code.

    LOL, good one Schneider! And if you ever lose it you can have more fun with the ALT+(0 5 9) key combo which will happily reproduce it – works wonders for productivity <g>

    Reply
  22. paulvick

    Eric: The CLR currently exposes no way to control inlining, so not at the moment. I know the C++ folks had some interesting experiences with inline control (which is why they had to introduce __forceinline and __noreallyinlinethis and __inlinethisnowdammit), so I don’t know whether the CLR will introduce it or not…

    Reply
  23. Mike McIntyre

    This advice is sometimes given on web sites:

    "The first thing a VB.NET programmer should do is remove the Micrsoft.VisualBasic namespace from any project they start."

    My understanding has always been along the same lines of the advice given in the Visual Basic.NET Internals article referenced in Paul’s blog entry above. It says there are are some reasons to occasionally go direct to the .NET Framework (e.g. using the Frameworks String methods instead of using the VisualBasic namespace Replace as explained in the article) – but in general the syntax in the VisualBasic namespace is good and useable.

    Paul, is there any sitution where you would recommend a VB.NET programmer remove the VisualBasic namespace and program Visual Basic.NET applications without it?

    Anyone else have an opinion about this?

    Reply
  24. Karl

    Mike

    I remember an article I saw on slashdot which compared the performance of 15 or so languages, C# and VB.Net were amongst them. For a slashdot-worthy article the results painted C# and the .net framework in a pretty good light. VB.Net however didn’t do very well. Long story short, the author of the code had written the file access for vb.net using the Microsoft.VisualBasic classes as opposed to System.IO (which was done for C#).

    Reply
  25. paulvick

    As far as I’m concerned, there’s no really good reason to not make use of the VB namespace. There’s nice functionality in there, and as long as you’re mindful of what you’re doing, there’s going to be no harm done. I do think we need to have good guidelines as to when to use certain things (such as the file handling methods, which contain a lot of backwards compatibility code), but overall I think just turning off the namespace is overkill.

    Reply
  26. Mike McIntrye

    Paul, thanks for the answer.

    I decided last night to write an in-depth article on getting the best performance for VB.NET applications. It will be very technically accurate. It will expand on what the VB Internals article covered and include the research we (my development company) has done on VB performance these past 2.5 years.

    Karl, I am going to do research at slashdot. Do you recall anything about the article that will help me find the exact article you mentioned?

    Reply
  27. yag

    If I recall correctly, Karl – that article compiled the VB code with optimization turned off, C# with it turned on.

    Reply
  28. Slobodan Filipovic

    input :

    Dim a As Integer

    Dim b As Double

    Dim c As Object

    Dim s As String = "123"

    b= 123.56

    c = b

    a = CInt(b)

    a = CInt(c)

    a = CInt(s)

    output with help of reflector

    string text1 = "123";

    double num2 = 123.56f;

    object obj1 = num2;

    ‘CInt(double)

    int num1 = ((int) Math.Round(num2));

    ‘CInt(object)

    num1 = IntegerType.FromObject(obj1);

    ‘Cint(string)

    num1 = IntegerType.FromString(text1);

    so VB.Net compiler translate CInt

    in call to static method

    so this is false:

    "with this is that the conversion operators are true operators that compile down to IL instructions while the Convert functions are still just functions"

    Reply
  29. Eric Mutta

    Paul:>The CLR currently exposes no way to control inlining, so not at the moment.

    But can’t you do it "statically" when you are generating the IL at compile time so it has the same effect as hand-inlining?

    Reply
  30. Eric Mutta

    Mike:>Anyone else have an opinion about [removing the reference to Microsoft.VisualBasic]?

    I have been working on writing a compiler in VB.NET and since performance is critical, in many cases I have had to go straight to the framework (where the VB routines were just wrappers and I didn’t need the extra functionality such as 1-based character indexing in strings) and in some cases I even had to rewrite the functionality in the framework (a recent example is the StringBuilder class).

    My take is that the VB routines should be viewed like any other productivity API you can write ontop of the framework. Some people seem to be hung up over the "legacy" feel of the routines since they existed in VB6 and are therefore "old" and implicitly "bad". Old APIs do get superceded and should be deprecated where needed but only if the new APIs add significant value (eg Substring() is not significantly, if at all, more useful than Mid()).

    Going back to the old "premature optimisation is evil" mantra, I would say use the Microsoft.VisualBasic and be productive, then profile the code and go direct to the framework when the wrappers slow you down in places where speed is critical.

    Following that philosophy has meant the lexical analyser in my compiler can scan 2.5 million lines of code in under 10 minutes, all while I listen to music, browse the web and have about 10 applications open (on an Intel P3, 997MHz, 256MB machine).

    Reply
  31. paulvick

    Eric: Yup, we could do inlining at the compiler level, but we generally have not had the extra resources to put into this kind of IL optimization work. What would be ideal would be a common backend IL optimizer for all the compilers, and it’s something we talk about seriously, although we won’t have one in VS 2005.

    Reply
  32. Pingback: VS Data Team's WebLog

  33. Pingback: VS Data Team's WebLog

  34. Pingback: Somasegar's WebLog

  35. Guoqi

    Although everyone from microsoft told me that you can choose either VB.NET or C#, there is no much difference, but I already decided to switch to C#.

    The reason is very simple, there are more C# programmers than VB.NET programmers. There are more C# open source code on the net and easier to get a help from newsgroup.

    I wish one day, there is only one programming language in this world, G#, that will save tons of learning/developing hours.

    Reply
  36. Rex

    VB has always had the readability edge. I remember any number of attempts to kill COBOL, which didn’t even have an "END IF" construct. Pascal, PL/1, Fortran77, etc., none of them took hold despite their many structural advantages. COBOL was significantly more readable.

    Here, too, CInt is great shorthand for Convert.ToInt32 etc.

    But the big advantage is the use of english instead of punctuation as another noted. How many times have you chased an obscure punctuation error in C?

    Reply
  37. Pingback: Anonymous

Leave a Reply

Your email address will not be published. Required fields are marked *