Future of Vb.Net vs C#

[samiullah478]

hi all
i am a vb and vb.net programmer.
i go in to a new software house and every body insist me to work in C Sharp.
people say that Vb.net will no longer available in future. and it is not good it will finish in future so u shud switch on Csharp. i want to know abt reallity that whts bad in vb.net that people prefer C#. i dont like that. and i dont wana switch over.

regards

[RobDog888]

Reality is that you are working in a C# house so if they request you write code in C# then thats what you have to do.

VB.NET is not going anywhere at all. Look at VB 6, its still hanging around. VB 6 will die way before VB.NET ever will. VB.NET is in VS 2008 which will have a 10 year run so dont fall into their hype.

[jmcilhinney]

That's a crock. There's no evidence that VB doesn't have a strong future. While the difference is markedly less than it used to be, VB is still the tool of choice for RAD. As someone who uses both I can agree with what I've read elsewhere that it usually takes less time to create the same application in VB than it does in C#. That said, C# does provide some features that make it a better choice in certain situations. The most obvious of those support for pointers. Basically C# and VB.NET are both powerful, easy-to-use languages and both will continue to be developed for the foreseeable future. That said, you may see that same bias you mentioned in the workplace, so it might be a good idea to learn C# purely from an employability perspective. When VB survives beyond this predicted imminent death, maybe that will change too.

[visualAd]

Why would VB.NET go out of fashion over C#.NET - you are using exactly the same framework and I doubt the framework will go out of fashion.

The company I work for use VB.NET in house. I do prefer C# but I like the framework and its flexibility and power.

[jmcilhinney]

The thinking from a lot of people is that C# and VB.NET are basically the same language but with different syntax, and why are both needed. That's faulty logic though. When the .NET platform was created the two were very similar, basically to get everything working on the common Framework. Now the two are starting to assert their different personalities, as they've had time to develop. There will never be as big a difference as there was between VB and C++, but VB will still be aimed at those who want the easiest possible road to development in the least time, while C# will be aimed at those who want more power. There will always be a lot of common ground but they are, and will get more, distinct from each other.

J# is gone now, which was really only something to keep Java developers interested until .NET was properly established. With the death of J#, do you think developers will turn to C# or Java? Microsoft's betting C# and I'm betting they're correct. VB for RAD, C# for power RAD, C++/CLI for more power, unmanaged C++ for more power still, and the new F# for functional programming. That's the way it will be for some time.

[timeshifter]

C# allows this funny little thing I just learned about called unsafe code. Using it, I got a graphic app of mine running about five times faster than the exact same app in VB. It took much less time to develop the VB app, but the C# was much faster in the end. I use VB now for my web development, as it's what my manager uses, and he likes it when we're all using the same language. I've begun using solely C# for my personal development because of its' power.

[RobDog888]

Yes, C# is better at graphics hands down. But its slower then what you can write in vb.net

As always, use the best tool for each and every job/project.

[wossname]

I personally don't think there's really any difference in coding time between C# and vb.net. If you are proficient at both that is.

[Max Peck]

hi all
i am a vb and vb.net programmer.
i go in to a new software house and every body insist me to work in C Sharp.
people say that Vb.net will no longer available in future. and it is not good it will finish in future so u shud switch on Csharp. i want to know abt reallity that whts bad in vb.net that people prefer C#. i dont like that. and i dont wana switch over.

regards

Relax. There is NO indication whatsoever that VB.Net is going to be abandoned in any way at all. The IDE support for VB is better (IMHO) than C# is to begin with. However, regardless of which of the two languages you prefer I think they are both going to be supported for the duration. Enjoy writing your code in which ever of the two you like.

-Max

[kleinma]

The biggest problem with the whole C# Vs VB thing is really something that fault lies with Microsoft on.

They have 2 teams. One is the VB team, another is the C# team.

They don't have to do the same things, they just both need to be compliant with the framework and how it all fits together. This is why you see certain features in VB you don't see in C# (like IDE background compiler) and vice versa (like unsafe code)

The other problem is the fact that most samples that come out of Microsoft on emerging technologies (which includes SDKs and subframeworks) are all in C#

Almost all SDK samples are in C# (that doesn't mean VB can't be used, it just means you don't get samples on how to do things like C# guys do), and things like XNA and Micro framework are C# only. (which means you can't use them from VB at all)

I personally don't like coding in C# unless I have to. I don't like that it isn't case sensitive, I don't like semi colons or curly braces.

Somewhere along the line, C people decided things like "End Sub" is "too much code". I personally look at it and say, "End Sub" means just that, just like "End If" means just that. What does } mean? its the end of something, but you usually have to look up and see what start bracket that end bracket is closing.

The other fact is that most C# developers come from C backgrounds, and have way more prior experience with working in a fully object oriented language. VB.NET devs coming from VB6 have a bigger learning curve because VB6 was only object based and did not support many standard OO features.

On that note, most non VB developers haven't (and won't) shake the notion that VB is a toy language not meant for "real world" applications, and it is only for quick stupid little apps. VB devs know this is not true, but its like trying to convert someone on a religion or political stance.

I can see VB going away at some point, but not for a long long time. While the general trend has been more in the C# devs favor, there is way too much out there in VB for it to go anywhere now.

Unfortunately, if it did come down to a choice between one or the other, I think C# would win. It may make sense for Microsoft at some point, to stop having "virtually" competing languages out there, which ties up money and resources to support 2 languages that do the same thing in the end.

The bottom line is if you are proficient in programming, then you should be able to move languages pretty easily. I stick with VB for the most part, but I still need to know Pascal, C#, HTML, Javascript, SQL, etc. While I don't know any of them nearly as well as VB, I can get what I need done, and lets face it, we never stop learning in this field of work.

One thing that keeps getting better no matter what tends to be the tools used to write applications, and the documentation used to reference.

[visualAd]

I am not sure C programmers have much OO experience; C++ is a different story though.

Working interchangeably between languages is easy once you have learnt some of the core concepts behind programming and once you have learn OOP - languages just become a tool. The rift between VB and C# then become irrelevant.

There is a good reason for using curly braces and semi-colons: you do not need to worry about white space. A semi colon terminates a statement and a curly brace starts or finishes a code block.

[kleinma]

There is a good reason for using curly braces and semi-colons: you do not need to worry about white space. A semi colon terminates a statement and a curly brace starts or finishes a code block.

You do not need to worry about white spaces = you do need to worry about semi-colons and curly braces

In the age of IDEs that pretty format and syntax correct on the fly, I don't need to worry about white spaces either.

My point is non VB programmers look at VB syntax and say its too verbose. I look at it and say its just verbose enough.

[penagate]

The differences are primarily syntactical, and syntax is subjective. Nothing I say could convince a die-hard VB coder that braces are more elegant than If...End If, and likewise nothing they could say could convince me otherwise. Why bother with such a trivial comparison, when they both do the same thing?

However, as John said, there are more differences than just syntax; this is where one can be more appropriate for a particular task than another—such as the graphics example above.


Career-wise, you will be most employable if you are proficient in both languages, personal preferences aside.

[timeshifter]

I toyed with VB6 for close to four years before I was hired as a VB.NET developer, and my biggest learning curve was wrapping my head around the OO concept. A CompSci class in college attempted to teach us Java, but came from the position of someone who had no programming experience whatsoever. Shifting from object-based to object-oriented with that kind of book was extremely difficult. Making the shift while being able to keep my syntax was much easier. From there, I've come to the conclusion that, as has been said before, the primary difference between VB.NET and C# is syntax. VS auto-indents very nicely for both languages, so they're both easy to read. With C#, Intellisense is, IMHO, generally much smarter. It pops up as soon as you start typing, so the case-sensitivity isn't as much of a problem as it would normally be. However, VB will always hold its' place as a radid-deployment language. No matter how much I prefer the layout of C# over VB, I simply can't deny that getting stuff done is faster with VB. More verbose, it may be, but it makes it incredibly easy to pump stuff out very quickly. C# takes more thought and attention to detail, but you end up with a generally faster application.

Use the right tool for the job, in any case. C# and VB.NET use the same framework, so code can be ported very directly from one to the other, and vice versa. The majority of tasks will operate within the framework, so unless you're playing with pointers, syntax is the ONLY prominent difference.

[kleinma]

With C#, Intellisense is, IMHO, generally much smarter. It pops up as soon as you start typing, so the case-sensitivity isn't as much of a problem as it would normally be.

I don't agree with that.

VB9 (aka VS 2008) intellisense comes up immediatly when you type now.


Another thing I like about VB intellisense versus C# is the way it handles showing me params. (which is true of 2005)

For example, lets say I have a VB project and type

Me.Windowstate = <- right here I get an intellsense popup with all 3 fully qualified enum values for windowstate

Now in C# I do

this.WindowState = <- right here I get general intellisense. While it DOES automatically go to the correct enum in intellisense for me to use, I have to hit tab, then period for C# to show me the actual enum values associated with the enum. This slows down productivity if you ask me.

[visualAd]

You do not need to worry about white spaces = you do need to worry about semi-colons and curly braces

In the age of IDEs that pretty format and syntax correct on the fly, I don't need to worry about white spaces either.

My point is non VB programmers look at VB syntax and say its too verbose. I look at it and say its just verbose enough.

The trade off of being more readable than C# is the verbosity of VB. I don't see a problem with that. VB looks more logical to anyone who hasn't seen code before and is a little easier to follow.

C# boasts:

• Easier use of pointers.
• Incrementation
• Cleaner expressions
  This is valid in C#:
  

  while ((y = function(x)) == 1) {
  }

• I should have said "not sensitive to new lines" instead of white space. In that
  

  x = 1; y =1;

  Is perfectly readable and totally valid and saves one line

Like I have already said - its not C# v's VB which should influence your decision but more - what is the most suitable tool for the task in hand. I don't think either are going anywhere for a long time.

[timeshifter]

I don't agree with that.

VB9 (aka VS 2008) intellisense comes up immediatly when you type now.

I haven't played with VS08, so I wasn't aware of this improvement.

Another thing I like about VB intellisense versus C# is the way it handles showing me params. (which is true of 2005)

For example, lets say I have a VB project and type

Me.Windowstate = <- right here I get an intellsense popup with all 3 fully qualified enum values for windowstate

Now in C# I do

this.WindowState = <- right here I get general intellisense. While it DOES automatically go to the correct enum in intellisense for me to use, I have to hit tab, then period for C# to show me the actual enum values associated with the enum. This slows down productivity if you ask me.

This is a very valid point, and is the primary thing I would like to see upgraded in VS 08. But the reality is, it's not much more than an inconvenience. Bugger that it may be, that's how it is.

[kleinma]

I agree its not a HUGE deal, but you said C# intellisense was better than VB so I had to at least give a "VB" side of that argument.

If they did infact change C# intellisense in 08 (I have not yet done anything in C# on 08) then the 2 languages may very well be on par with eachother now in terms of intellisense and productivity.

[Max Peck]

Some interesting points here. Personally I chose VB originally because it helped me move out of DOS development into Windows coding. (Back in the VB3 days). Prior to that I wrote mostly in C and Assembly - device drivers, memory-management and O/S code.

In the ensuing years I came to really like VB because it is "just right" for the way I like to code. I stress SIMPLICITY in my coding - not sophistication. Also - the creature features of the IDE are, IMHO, better (VS2005). In my particular work I stick with VB simply because I just like the syntax better and I don't have to do as much re-inventing as I used to have to do in C/C++. Of course the framework mitigates that to a large degree but I think you know what I mean.

I also like the fact that the VB dialect is consistent whether you're in VB6, VBA, VBScript or VB.Net. After writing terse C code and doing pointer math for many years it was very refreshing to let someone else do the dirty low-level stuff now and just work on the business-intelligence layer for a change. I am pretty conservative in the way I write code. The stuff I write is very fast because I don't use huge objects where a tiny class or primitive variable construct will do. I guess I developed that style when working in really limited memory environments like the PDP-11 many years ago.

For me VB (in either flavor) just plain rocks. Sure I can code C# - I inherited a project in it and have no problem working with it - but whenever I code something new it's in VB.Net or VB6 simply because this aging developer doesn't HAVE to do it any other way if he doesn't want to! I target Windows Desktop systems (no web stuff right now thank you). As long as VB6 will continue to run in the desktop environment I'll continue using it - and am gradually moving to VB.Net also though I only use that because our shop does; anything I write independently is strictly VB6.

Seldom do I ever get a client ask me what tool I used to make the program - they're more apt to say "Damn ... your program sure is simple to use and runs fast!".

-Max

[techgnome]

x = 1; y =1;

Is perfectly readable and totally valid and saves one line

What? Is you pinkie broken?

x = 1: y =1

Is perfectly readable and totally valid and saves one line and one keystroke (no ; on the end)

Like I have already said - its not C# v's VB which should influence your decision but more - what is the most suitable tool for the task in hand. I don't think either are going anywhere for a long time.

hear! hear!

-tg

[timeshifter]

x = 1: y =1

Is perfectly readable and totally valid and saves one line and one keystroke (no ; on the end)

Ah, but not. You need to [Shift] the ; to get the :, therefore balancing the keystroke count

[techgnome]

RATS! Foiled again....
Jsut goes to prove that both are just as efficient....

-tg

[timeshifter]

Once you hit compile, C# is faster. In VB, every event handler already exists, you just have to create the methods. That ends up with a lot of handlers with no methods to them. In C#, there are no methods OR event handlers when you create an app. You create both as you go, meaning only the events needed will ever be handled.

[visualAd]

I can't believe that -an un-handled - handled event handler.

[kleinma]

Once you hit compile, C# is faster. In VB, every event handler already exists, you just have to create the methods. That ends up with a lot of handlers with no methods to them. In C#, there are no methods OR event handlers when you create an app. You create both as you go, meaning only the events needed will ever be handled.

what do you mean every event handler exists?

An event handler in VB only exists if you use addhandler or if a subroutine has a handles clause on it.

How is that every event handler?

[RobDog888]

Maybe hes thinking of how you can pull down events in the code behind? That has no effect in a vb project as like you say, if its not used in your code then its not handled.

[timeshifter]

That's how it seems to me, at any rate. With VB, you can pull down that drop list and pick any of the events tied to whatever object you're in right now. To me, that suggests that all the handlers for those events have already been created internally. With C#, nothing appears in that drop down unless you create the handler and the method yourself.

[Shaggy Hiker]

That's how it seems to me, at any rate. With VB, you can pull down that drop list and pick any of the events tied to whatever object you're in right now. To me, that suggests that all the handlers for those events have already been created internally. With C#, nothing appears in that drop down unless you create the handler and the method yourself.

100% of the code you don't execute is not run.

So there's an internal list of events, and whenever one is not used it does....nothing. It certainly seems like this is an advantage of VB over C#, as you make it sound like VB is easier to use, which, when it comes to the whole delegate issue, it IS. The whole event model is the same under the covers, but in VB it is easier to remember, and easier to use.

[kleinma]

That's how it seems to me, at any rate. With VB, you can pull down that drop list and pick any of the events tied to whatever object you're in right now. To me, that suggests that all the handlers for those events have already been created internally. With C#, nothing appears in that drop down unless you create the handler and the method yourself.

That is not correct. That list is simply populated via reflection on the object. Once you select an event to write code for, VB automatically inserts the signature skeleton and attaches a handles clause to the end. C# does not have a handles clause, the just allow you to assign a method to the event name

like

this.Load += new System.EventHandler(this.Form1_Load);

instead of

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

    End Sub

Either way you look at it, its still just the IDE wiring up code for you, in either language.

The way C# does it (IMO) makes things way less discoverable in the IDE.

[jmcilhinney]

Like so many debates about this vs that, you can go on about nit-picky features as much as you like and no-one is really convinced. If it's a matter of saving a key stroke here or there then God help us all. If the small execution speed advantage that C# has over VB.NET in some cases turns you on stop coding in C# and start using unmanaged C++ like you should. VB's not going anywhere soon, it's syntax is different to C#, use the one you like most or give yourself the best chance of employment and learn both.

[visualAd]

We should all write in machine code. That will save any debates.

[Phill64]

A .NET coder should be (at least) familiar with both, is my view. </end 2 cents>

[wossname]

The single major thing that annoys me about C# is its lack of preprocessor macros. I make heavy use of macros in C/C++ and I think they are a terrific aid to consistency and stability (not to mention maintainability) if not readability.

I can't think of a good reason why MS didn't implement preprocessor macros in C#, they gave a brief nod to it with #error and #define (which doesn't live up to its name in any case) but I'd love to see that in a future release. Managed C++ projects do support macros so I doubt it would conflict with intellisense. Who knows, maybe MS decided that it would simply make people go straight to C++ instead.

In all other respects I think C# is superb. Personally I think VB.net is too woolly and vague for me (case insensitivity and so on).

However the single greatest improvement from VB6 to VB.net is the fact that it now handles arrays in the right way (ie. mandatory indexing from zero). VB6's leniency with arrays is just unforgivably terrible, especially when you have to port a huge legacy app to .net.

[Merrion]

Re: Case sensitivity

In what circumstance would it be good programming practice to have two different variables whose only name difference was in the case - Surely that just leads to bugs Bugs BUgs BUGS and BuGs

[kleinma]

I agree, I absolutely hate the syntax of

Socket socket = new Socket();

It just seems silly...

[MMock]

My first language that I liked coding in and was able to use professionally was C. I learned it in school and the company I was working for (an insurance company) had some job openings using it and were also using AIX (IBM's flavor of UNIX). The was a refreshing change over COBOL, TSO, VTAM - the whole mainframe environment.

I was also using DOS, then OS/2 came around. Then I went to another company (unrelated to OS/2 having come around ). I was still using C and then Windows. Then I learned VB for a new project. VB seemed to be in demand everywhere and made me more marketable. Then I did some Java and Internet stuff. I never quite "got" or liked C++, even coming from C. The flavor of VB I had been using (something pre-6) wasn't object oriented.

I took seven years off to raise my family and didn't know why I couldn't get a job just because this thing called .NET had been introduced in the meantime. My first project back in the workforce was VB using VS 2003, but was Windows not .NET. Now I am getting into Internet programming. My experience with C has helped me greately with javascript - things like { and } and ;. And also if (i == 0) instead of if (i = 0), even though I got burned a couple times before I remembered to remember that! My experience with C and VB have helped me greatly with C#.

I miss C because I miss low-level programming where you're close to the hardware, but those days seem gone forever (I only interviewed for two C jobs on my way back in to the workforce, and many, many VB.NET jobs).

We use C# occasionally here, but we don't develop in it by choice. I remember looking at jobs on Monster and Dice and having no idea what C# was! But I like it, because it's like C. I guess I haven't used it enough to know how it's better/worse than VB.

Anyway, is anybody besides me wondering what happened to this thread starter??? He hasn't piped in at all. And how do you interview and get a job and not until you start that job find out it's C# when your background is in VB???

[misterheadache]

Since this thread has already diverged into a love/hate session of various languages, I'll add my own two cents in SUPPORT of VB.NET:

My current project is a map editor for first person shooters that will support multiple game platforms. It started out as an experiment with MDX a couple of years ago, but I've kept plugging away at it and it's now almost 30,000 lines of code, uses multithreading, dynamic .dll plug-ins, custom dockable windows, and a host of other goodies. Graphic rendering and other performance is equivalent to other map editors written in C/C++. As a novice programmer (i.e. one who doesn't do it for a paycheck), there is no way I could have done so much so well so fast in any langauge other than VB.NET

'nuff said for me......

[techgnome]

I agree, I absolutely hate the syntax of

Socket socket = new Socket();

It just seems silly...

It seems silly because of your VB background... it goes against the natural VB order of things.... but to some one with C/C++ background it makes perfect sense.....where

Dim sokMySocket As Socket
Set sokMySocket = New Socket

or

Dim mySocket as New Socket()

May seem silly to them.....It's all perspective....

If I see socket.openConnection, I know I'm using an instance of the Socket class.... if I see Socket.openConnection, I know that it's using a shared method of the Socket class.

Suffice it to say, C/C++/C# developers tend to be a different breed from VB Developers. And it's not just syntax or language differences, but also personality and attitude differences too.

-tg

[wossname]

Re: Case sensitivity

In what circumstance would it be good programming practice to have two different variables whose only name difference was in the case

No idea, I never suggested that doing such a thing would be a good way to write code.

What I mean is that things like case-sensitivity, type strictness and so on are ways to ensure clarity and consistency throughout a project.

[kleinma]

If I see socket.openConnection, I know I'm using an instance of the Socket class.... if I see Socket.openConnection, I know that it's using a shared method of the Socket class.



-tg

Except this is valid as well

Socket Socket = new Socket();