Journal FortKnox's Journal: C# vs VB.Net? 18
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?
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
Meh. (Score:2)
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
Re:Meh. (Score:2)
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.
Muh? (Score:2)
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
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.
Re:Muh? (Score:2)
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.
You hit it right there... (Score:2)
If I know java and need to develop
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)
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
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
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
Hope that helps. Let me know if you have any more questions...
Re:C# vs VB.NET (Score:2)
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).
Re:C# vs VB.NET (Score:2)
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!
Au contraire (Score:2)
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.
Re:Au contraire (Score:2)
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.
Re:Au contraire (Score:2)
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.
Re:Au contraire (Score:2)
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.
Re:Au contraire (Score:2)
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).
Re:Au contraire (Score:2)
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/Spac
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]
Re:Au contraire (Score:2)
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.
VB's the middle child now (Score:3, Interesting)
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.
Great article on Languages (Score:1)
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!
C++ for VB Developers (Score:3, Insightful)
I think that many people that make the move from Visual Basic to
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
Anyway, I decided not to bother learning VB.NET because of this. It's all Java and C# from here on out.