Forgot your password?
typodupeerror
Programming

FortKnox's Journal: C# vs VB.Net? 18

Journal by FortKnox
I've got a question for you .net'ers (lookin at your, goober) ;-)
What's the difference between using VB.Net and C#? If I can do the same thing, and create the same objects (CLR, remember), which means the same efficiency, then why should I waste the extra typing C# has when I can just whip it up in half the time in VB.Net? Even if C# is slightly more powerful, you just write the complex objects in C#, but use them in VB.Net (like how you used to use assembly for complex graphics, but the rest of the code in C/C++)...

I guess my question boils down to, is C# nothing more than a platform to convert Java developers into .Net, then, eventually, switching them over to VB.Net?
This discussion has been archived. No new comments can be posted.

C# vs VB.Net?

Comments Filter:
  • by JMZero (449047)
    If you like the syntax of VB.net, then use it. If the glories of C# aren't making your coding life better, then there's no reason to endure. It's generating the same slow wacky crap at the other end. I find I spend a lot more time fiddling with syntax and typing when I'm using C#.

    I use VB.net for some side projects (like the level editor for my coming-soon game) and it has given me no headaches whatsoever (although I still don't know how to create an invert pen). Maybe next year they'll give us back magical debugging (like VB6).

    Also, I really can't stress enough how performance poor my .NET apps have been. On one screen, my game creates a random layout for a puzzle. It was fairly complex code, so I decided to prototype it in VB.net before I wrote it in game script (which, uncompiled, is fairly basic-ish). I was a little worried, as the performance under VB.net was dreadful - it took 5 or 6 seconds to come up with a layout. When I moved it to game script (which is bytecode interpreted manually by my C++ exe), time was down to under a second. Neither my script compiler or interpreter have even been kind of optimized yet. The instruction handler is a non-nested list of "if"s.
    • by glh (14273)
      Also, I really can't stress enough how performance poor my .NET apps have been. On one screen, my game creates a random layout for a puzzle. It was fairly complex code, so I decided to prototype it in VB.net before I wrote it in game script (which, uncompiled, is fairly basic-ish). I was a little worried, as the performance under VB.net was dreadful - it took 5 or 6 seconds to come up with a layout. When I moved it to game script (which is bytecode interpreted manually by my C++ exe), time was down to under a second. Neither my script compiler or interpreter have even been kind of optimized yet. The instruction handler is a non-nested list of "if"s.


      This doesn't sound like an apples to apples comparison. C++ is still going to be faster especially if you are doing math ops and interfacing the memory directly. Try doing the same thing with C# and using pointers. I bet you'll get much better performance. Even in VB.NET here is probably a better way of doing it. Care to post any sample code? Also, it sounds like you C++ exe is optimized to read bytecode for this particular type of app.

      • by JMZero (449047)
        This doesn't sound like an apples to apples comparison

        I'm comparing how long it takes to execute pretty much the same instructions in VB.net and in my crap-laden scripting language. How is that not apples to apples? Now, of course I understand that the CLR does lots of stuff that my cheesy script interpreter is not doing - but right now we're just talking about performance.

        C++ is still going to be faster especially if you are doing math ops and interfacing the memory directly

        Neither the CLR or my script language is doing math operations directly. That's why their both significantly slower than C++.

        Care to post any sample code?

        Not really, no.

        It's simple stuff - most of the time is spent looping through an array on the stack and counting things. I'm sure with some dedication I could get the VB.net version to run faster, but likely that would mean coming up with a better algorithm - and then we'd be comparing different things.

        Also, it sounds like you C++ exe is optimized to read bytecode for this particular type of app.

        Well, the script interpreter is fairly general purpose and I certainly wouldn't call it optimized. But it certainly does have smaller scope and many fewer instructions. My only purpose in bringing it up was to say "Here is a slow way of doing something - and the CLR is much slower again". My script interpreter is likely 10-20 times slower than native C++ for this kind of work - but there's reasons why I use it, just like there's reasons people use .NET.

        Anywho, I wasn't saying "VB.NET sucks" or "MS screwed up the performance". I use VB.net for some things, and I appreciate why it performs slow on some things - it's doing a lot of stuff. All I'm saying is that for a certain class of problems (ones which focus on many iterations of simple instructions), the CLR is adding a significant burden.
        • by glh (14273)
          Well, the script interpreter is fairly general purpose and I certainly wouldn't call it optimized. But it certainly does have smaller scope and many fewer instructions. My only purpose in bringing it up was to say "Here is a slow way of doing something - and the CLR is much slower again". My script interpreter is likely 10-20 times slower than native C++ for this kind of work - but there's reasons why I use it, just like there's reasons people use .NET.

          Anywho, I wasn't saying "VB.NET sucks" or "MS screwed up the performance". I use VB.net for some things, and I appreciate why it performs slow on some things - it's doing a lot of stuff. All I'm saying is that for a certain class of problems (ones which focus on many iterations of simple instructions), the CLR is adding a significant burden.

          Definitely a good point. The CLR does add quite a bit of overhead. However, I'd also like to point out that you can do quite a bit to get around some of its inefficiencies with overloading. But if you have to go to that level, it may be better and cleaner to do it in a non-clr language that may be "more appropriate" for what you're doing.. as always, choose the right tool for the task.
  • There's no diff- its just what you want to code in.

    If I know java and need to develop .NET framework stuff, I'd use C#.

    If I knew VB, I'd use VB.NET

    Its like asking "Should I use perl or awk?"

    Of course you should use awk first- its damn simple. ;)
  • C# vs VB.NET (Score:4, Interesting)

    by glh (14273) on Thursday January 23, 2003 @02:19PM (#5144515) Homepage Journal
    Hey, one of my favorite topics and glad you asked! :) I think this can be a difficult question to answer, it is somewhat subjective and depends on your background. Here are some general comments on the argument (heck, this is almost a religious war now-a-days)

    1. C# is slightly more powerful because you can write pointers, in VB.NET you can't. This is probably something that most people won't ever need to really do so it's no big loss.

    2. C# has a compiler option to generate XML documentation if you use a certain XML syntax for commenting your code. This is almost a moot point.. But I thought I'd bring it up. Basically, if you bother to comment at all (which most coders don't), this is a worthwhile option. You can do similar stuff with VB.NET but you still have to use a ' mark to comment each line, which I find annoying.

    3. Syntax differences. C# is very verbose, but the keywords tend to make more sense. For example, when declaring classes/functions/etc. you use keywords like "sub" (sub meaning a void), "Shared", "Friend" as opposed to abstract, sealed, void, etc. I would say that VB.NET is definitely more "user friendly" when it comes to understanding what the code is doing, but that's only if you read code with a VB mindset.

    4. Which brings me to my next point. If you are used to Java, C# varies LITTLE. You will be up and writing code in no time. On the other hand, if you already know VB, you will have a hard time learning both VB.NET and C#, although the former will look more familiar. The main reason it will be more difficult to learn is because VB until the .NET version was not entirely object oriented. Whichever language you learn, the majority of what you need to learn after the object oriented principles are down is the OO framework-- which is the other 90% of what's new. So either way, you've got a 90% learning curve to look at. If you know VB.NET you can easily learn C# (most could make the switch in a day easily, needing only a reference as far as what "translates" to the C# term)

    Ok, I also noticed you thought it would be quicker to write something in VB.NET than in C#. That is simply not true. VB.NET would take the same time (if not longer) to write. The reason I say that is because VB.NET code tends to be bigger since it is more verbose. "End If" instead of a } for instance.

    So in summary, there is very little you can't do in VB.NET that you can do in C#. The only exception being directly interfacing memory via pointers. All the base classes (such as System.Net, System.IO, System.Whatever) are available to ALL .NET languages. Almost exactly the same syntax is used when invoking these objects. An example of a difference is when you are working with arrays and indexers.. ie:

    DataTable.Rows(1).Item("COL_1")

    - This is how you access the first row and column named "COL_1" in a datatatable object (which is in the System.Data base class) with VB.NEt

    DataTable.Rows[0]["COL_1"] is how you do it with C#...

    The main difference is no "Item" keyword and you use square brackets. That is but a simple example of the difference in C# and VB.NET...

    Also- one more point. MS is not trying to convert C# developers to VB.NET. I honestly think, if anything, it's the other way around. Mainly because most of the applications MS is cranking out nowdays are written in C# (including a large portion of Visual Studio.NET). Much of the help files on the web and in books are in C# as well. VB.NET still has the stigma of being a "dumbed down" language, and MS themselves have suggested that C# will be further diverging in terms of power in future versions, although I haven't heard of any differences in Everet (which is the next version of .NET due out very soon and is mainly bug fixes).

    Hope that helps. Let me know if you have any more questions...
    • Hey, I comment my code!

      Anyway, I was reading a discussion in a mailing list yesterday and it was talking about using braces or not within your C# code. Basically, the following two are the same:

      if(this.Value != 0) DoSomethingNeat();

      if(this.Value != 0) { DoSomething(); }

      Evidently, the braces (as well as end of line semi-colons) in C# speed up compilation. The execution speed should still be the same b/c it's all IL by then. The braces and semi-colon help the compiler pull tokens faster.

      Kind of a side point, but one I thought was interesting (and obvious after thinking about it).
      • Glad to hear its positive.

        I, actually, cannot write a one-line if without braces. Four professors and two bosses constantly scolding me about it makes it impossible for me to do it.
        Funny thing, is that its not dangerous in Java, only C (macros) and C++ (inline functions).
        Does C# allow inlines or macros? If so, no oneliners without braces!
  • C# nothing more than a platform to convert Java developers into .Net, then, eventually, switching them over to VB.Net?

    Microsoft (and I say this as someone who is a bit closer to the company than most people) ported VB to .NET only because of their huge developer base. They'd be happier than a clam if everyone switched to C# tomorrow.

    C# is the darling language of .NET right now and for the forseeable future, while VB.NET is essentially a hacked hack that MS had to hack because they had no choice. If you think about it in terms of lowering your development costs if you only have one runtime and one IDE to maintain, you begin to see the reason why VB even made it to .NET when it wasn't even really necessary to port it at all. Even Microsoft can't afford to maintain two enormous coding groups that are essentially (in their view) aiming for the same thing - software development tools.

    • I agree that C# is the "darling language" right now, but I think VB.NEt will definitely be around for quite some time. Especially when you have people like Don Box promoting in ("Yes, you can do that in VB.NET!"). The truth of the matter is, many MANY people in the .NET community are very serious about VB.NET. Like it or not, MS is always going to be swayed by the development community and the supporters of it. Many of the ASP Elite for instance lean very heavily to VB.NET simply because it is the easy way to get things done. I think the C# /VB.NET rift will become bigger, and VB.NET will once again become a "second class language" but that wont stop the majority of businesses from keeping it as the defacto standard. Basically C# is the new C++...
      I think C++ will continue to hang around, but it won't be used in the typical database/web/etc. application shops anymore-- only in the hardcore networking/graphics/math/etc. type shops where performance is absolutely the most important factor.
      • I think the C# /VB.NET rift will become bigger, and VB.NET will once again become a "second class language" but that wont stop the majority of businesses from keeping it as the defacto standard. Basically C# is the new C++...

        You have posted this sentiment several times in this discussion... so I have to ask: Why, with the existence of the CLR, would keeping VB.NET up to par with C# require anything more than the introduction of a few new kinds of syntax or a few new keywords?

        I thought the goal of the CLR was to allow any OO language to be converted relatively easily into IL code.

        Right now, VB can be converted into C# by a simple syntax transformation. Pointers in C# are not a recommended "feature".

        I would actually expect Microsoft to move toward eliminating things such as pointers from C# down the road as they have seemed to do by placing increased security restrictions on C# code that uses pointers.

        • You have posted this sentiment several times in this discussion... so I have to ask: Why, with the existence of the CLR, would keeping VB.NET up to par with C# require anything more than the introduction of a few new kinds of syntax or a few new keywords?

          It is mostly hearsay and rumor at this point. There was buzz about the possible divergence a lot in late 2001. However, I had to dig in the google cache to dig up some of them, so I'm not sure what the latest plan is. As far as I know, MS has not officially announced any specifics on whether the languages WILL diverge. Anyway, here are some URL's:

          ASP alliance [aspalliance.com]
          ASP tutorial [asptutorial.net]
          Google Cache #1 [216.239.57.100]
          Google cache #2 [216.239.57.100]

          I think I will post a message to a list I'm on and see what the latest buzz is on that.
          • Does C# do the DirectX thing?
            Something similar to the STL?

            I'd be interested in trying DirectX in C# (if I can find an IDE and compiler in one tool).
            • It's definitely possible to program to DirectX API's with C#. One of the first code demo's that I ran in VB.NET was called "Donkey .NET" which I believe used DirectX. I don't believe there is a .NET version of DirectX yet, so you're going to be using some sort of COM engine in order to do it.

              I did some googling, some good stuff out there!!

              Here is a link on a game that was written in C# with directX:

              http://www.c-sharpcorner.com/Code/2002/April/Space BreakOutMJ.asp [c-sharpcorner.com]

              This is supposed to be a book on it:

              DirectShow [wordware.com]

              Asteroids [216.239.39.100] written in C# (but w/o directX), cool example source.

              Good C# link w/ directX 9:

              Managed DirectX [freeserve.com]

          • Interesting stuff. I hope the two don't diverge... it would seem to defeat the purpose of the CLR. However, maybe Microsoft is finding areas where they will be able to market C# as a language uniquely able to integrate with optimized pieces of c/c++ code in order to meet certain performance goals or to compete against benchmarks set by competing platforms.

            Overall, I think the philosophy behind the .NET framework and the CLR is a good one. I'm glad that folks are working on Mono, too. C#/VB.NET are much easier to learn than c/c++ and with the .NET classes it is very powerful. The next step is creating an open source alternative and making it cross-platform.

  • by Keith Russell (4440) <keith.russell@noSpam.gmail.com> on Thursday January 23, 2003 @03:07PM (#5144919) Journal

    Disclaimer: I'm speaking from mostly Visual Basic experience. I know enough C++ and Java to be dangerous, but the vast majority of my production-caliber code has been VB and PL/SQL. My .Net experience has come from personal tinkering with the VS.net betas and the final version of VC# Standard.

    I'd say C# now has Most Favored Language status at Microsoft. C# fits perfectly with the CLR and the Framework. VB7 has to make too many concessions to legacy code.

    Unfortunately, the changes from VB6 are so profound, legacy code is still a pain. Here at work, we've pulled VB projects up from versions 3 to 6. The transition from VB3 VBXs to VB4 ActiveX controls was the biggest change we had to make. Fortunately, most VBX vendors were keeping their ActiveX interfaces backward compatible with the old VBXs, so the project references were usually the only changes needed. VB6 to 7 is a whole 'nother story. So many things have changed in the fundamental language that a migration wizard is necessary. Some functions have changed so much, they're either implemented in a compatibility library in the Framework, or they're not converted at all.

    And VB7 tries too hard to be BASIC. Like C#, VB's "intrinsic" datatypes are nothing more than keyword aliases for Framework types. (i.e. C# int == VB Integer == System.Int32) But there's no keyword(s) for unsigned types, since the old VB only had signed intrinsic types. You have to use, for example, System.UInt32 to get what could be declared in C# as uint. But my personal favorite VB dumb-down has to be in the scope modifier keywords. Instead of C#'s abstract and sealed, VB uses MustInherit (on classes), MustOverride (on methods), and NotInheritable. Oy! I know they "look" like BASIC, but I sometimes wonder if they didn't make the names more verbose to keep them from looking too much like C#.

    I think, if you're building something new, C# is the way to go. If you have a lot of number crunching to do, and you can componentize your performance-critical code, put it in raw C/C++, and access it through a Managed C++ facade. In fact, Microsoft recommends Managed facades for just about any advanced C++ concept (multiple inheritance, templates, etc.). I would only recommend VB7 to someone with either a lot of old code or an aversion to C-style syntax.

  • In the latest edition of Crosstalk [af.mil] there's an excellent article about the evolution of programming languages, including some insight as to advantages of the CLR and JVM (and disadvantages.) Unfortunately, the current issue isn't online yet.
    The subscription is free and the February issue discussing languages has a great pull-out map of language development.
    If the story was online, I'd link to it. Since it's free, you could consider subscribing if you don't mind the occasional discussion about Ada [adahome.com]. Plus, you'd get the nifty, cool pull-out map!
  • by cyranoVR (518628) <cyranoVRNO@SPAMgmail.com> on Saturday January 25, 2003 @12:44AM (#5155313) Homepage Journal
    I have this book called Visual C++ for Visual Basic Developers by this guy Bill Locke. In the introduction he gives this whole history of VB and the conclusiong he finally reaches is this:

    I think that many people that make the move from Visual Basic to .NET technologies will move right to C#. Why? Because there is no real advantage in remaining with Visual Basic any longer. The class syntax in C# is easier and more logical than VB.NET, and some things are possible in C# that just aren't possible in Visual Basic.NET. (p.19)

    That said, it seems to me that the main motivation for creating a VB.NET is to keep all your VB6 customers from flipping out (and from what I understand, there are a VERY large number of MIS apps out there written in VB). Imagine if Microsoft told all its customers that they would have to convert all their VB6 code to C#.NET. Full scale rebellion.

    In fact, a while back there was an article [slashdot.org] posted here on /. analyzing .NET CLR. IIRC after a lot of technical analysis [arstechnica.com], the end conclusion was something like "the only significant difference between C# and VB.NET is the syntax."

    Anyway, I decided not to bother learning VB.NET because of this. It's all Java and C# from here on out.

A consultant is a person who borrows your watch, tells you what time it is, pockets the watch, and sends you a bill for it.

Working...