logo
vbRad Home
Source Code
Book Reviews
Forum
Links
About Us
Contribute

Compare Databases with SQL Effects Clarity
 
 Top 10 reasons VB.NET is better than C#

Posted on
8/23/2004
Author:
Robert Gelb
Email:
Not Shown
Applies To OS:
All
Product:
N/A



Related Articles
Top 10 reasons C# is better than VB.NET

Very few programmers have the luxury of toiling on their code for a really long time - we are expected to churn apps out in a quick manner. Which means that to be productive, we must use tools that enable us to be that. So let's get practical, religion aside, with an eye on programmer productivity, here are the top 10 reasons why VB.NET is better than C#, in no particular order

  1. The amount of data casts and conversions in C# is gigantic. There are probably 10 casts per 50 lines of code. Most of the time these casts are totally unnecessary, like in this common example. I normally save the state of the form either to Ini file, Registry or XML file. So on application startup, I restore Form's state:
    //get the form state from Ini File
    			
    //following line fails
    FormWindowState eState = oIni.GetValue("FormState");
    	
    //must use cast (FormWindowState)
    FormWindowState eState = (FormWindowState) oIni.GetValue("FormState");
    			
    //even this does not work
    FormWindowState eState = 1;
    
    //you have to use a cast even on simple numbers
    FormWindowState eState = (FormWindowState) 1;
    			
    //finally set the value
    this.WindowState = eState;
    So here we have a case where Form.WindowState should accept value such as 1, but refuses to. IMO, the compiler should be able to convert on the fly. I don't mind strong typing. I do mind stupid typing. In VB.NET all the lines below work.
    me.WindowState = 1
    me.WindowState = val(oIni.GetValue("FormState"))


  2. The Intellisense in VB.NET is smarter than the one in C#. The most maddening example involves enums. Consider these screenshots:
    C#VB.NET
    Note that in C#, you had to type out the enum type (FormWindowState), before Intellisense appeared. Which means you had to remember what it was. While in VB, the intellisense appeared right after the = sign, sparing you the having to remember the enum type belonging to the WindowState property.

    Intellisense in vb.net goes beyond this. Let's say you declare your variables in mixed/Hungarian notation, and then type my code later all in lower case. VB.NET autocorrects the case. It is a quick visual confirmation that your syntax and variable names so far are correct. Thanks to Jai Lue for this insight.

  3. Optional Parameters. Even though it is syntactical sugar, it helps you code faster. 'Nuff said.


  4. With..End With construct. Does anything else need to be said? Really?


  5. Handles keyword. Currently in C# you have to setup the signature for the event handler and and then provide the function elsewhere. This is like C for god's sake. Where as in VB, you provide the description of what the function handles right in the function via the Handles keyword. The word is that C# will eventually provide anonymous methods (i.e. providing event code at signature). Will reevaluate this when we get there.

  6. In C#, you do a LOT more typing. The common consensus is that C# is much less verbose than VB.NET, That's a total misconception. Consider the following pieces of code and then count the bytes:
    VB.NETC#
    'instantiate a textbox
    Dim a As New TextBox()
    
    'Update some class
    With MyClassName
    	.ThisProperty = "sss"
    	.ThatProperty = "sss"
    	.ID = 4
    	.Name = "Frank"
    End With
    				
    
    //instantiate a textbox - Word 'TextBox' had to be written twice
    TextBox a = new TextBox();
    
    //Update some class - count how many times MyClassName had to be typed???
    MyClassName.ThisProperty = "sss"
    MyClassName.ThatProperty = "sss"
    MyClassName.ID = 4
    MyClassName.Name = "Frank"
    



  7. Events. Extremely easy to both declare and raise in VB.NET. In C# you have to be a delegate expert. Consider the following code:
    Class Example
    	Public Event SomethingOccured()
    	Public Sub Method1()
    		RaiseEvent SomethingOccured
    	End Sub
    	End Sub
    End Class
    Class Papa
    	Private WithEvents oExample as new Example()
    	Private Sub SomethingChanged() Handles oExample.SomethingOccured
    		...
    	End Sub
    	
    	'or use AddHandler function
    	AddHandler oExample.SomethingOccured, AddressOf x
    	Private Sub SomethingChanged()
    		...
    	End Sub	
    End Class
    		
    As you can see extremely easy and no need to much with delegates which are a lot more code-intensive. Now, mind you, VB.NET still fully supports the delegates, but for 99% of the time standard events do the trick.

  8. More refined Error Handling using the Catch ... When block. See below
    Do
      Dim attempt As Integer
      Try
        ' something that might cause an error.
      Catch ex As IO.FileLoadException When attempt < 3
        If MsgBox("do again?", MsgBoxStyle.YesNo) = MsgBoxResult.No Then
          Exit Do
        End If
      Catch ex As Exception
        ' if any other error type occurs or the attempts are too many, do the following.
        MsgBox(ex.Message)
        Exit Do
      End Try
      ' increment the attempt counter.
      attempt += 1
    Loop
    Thanks to German Voronin for this.

  9. Another reason is the Switch Block(Select case) syntax. For very large state machines this comes in very handy. Reuse of a single case statement for multiple items and no break statement required.
    c#
     
    case 1
    case 2
    case 3
        (...) // Do Action
        break;
    case 4
        break;
     
    vb.net
     
    case 1,2,3
        (...) ' Do Action
    case 4	
    
    Thanks to Brian Yule and Vashon Kirkman for this piece.

  10. Ah, I am still working on this...





Add Your Comment  

Name: Email Address: all fields optional
Notify me via email when someone responds to this message (valid email required).

Enter the word:
 



Comments
#1. By VBGOD. Posted on 3/2/2006 6:40:41 PM
Good stuff! The biggest different would definitely have to be the Intellisense.

#2. By Anonymous. Posted on 3/3/2006 5:03:04 PM
Reason 3 and reason 6 are pretty much the same.

#3. By Anonymous. Posted on 3/5/2006 5:23:46 PM
Great stuff!

#4. By Michael Sync. Posted on 3/16/2006 12:51:25 PM
>>>Reason 3 and reason 6 are pretty much the same

I dont think so.. Its' quite different.
Why do you think reason 3 and 6 are the same??

I have emailed you about NO 10.. Please take a loot.. :-)

#5. By Robert Bouillon. Posted on 3/16/2006 3:58:06 PM
I'd like to provide some opposing points, not meant to be argumentative.

1) VB uses 'implicit' casting, meaning the developer doesn't need to be aware of the cast, even though it is occurring. For veteran developers, this is VERY bad. Too often developers don't realize the performance hit their code incurs. A simple Example:

For Int i = 1 to 100
Response.Write(i + ") This is number " + i)
Next

i is cast to a string twice per line. It's a simple example, but the developer _should_ always be aware of the type they're using/casting to avoid unnecessary casts, and to assist in debugging.

Also, the _actual_ c# version of your above code is:

me.WindowState = (FormWindowState) 1;
me.WindowState = (FormWindowState) oIni.GetValue("FormState");

It's not that much more code to show what work the runtime has to perform. In fact, C# tends to be less code with its use of brackets over full words for scope definition, as well as declarative, single-line if statements.

Also of note: val is a VERY expensive VB operation when compared to a direct cast. You should be using Int32.Parse or direct-casting.


2) That was an annoyance to me in VB. Most of the time I was comparing against a variable, not a constant. (i.e. me.WindowState = myVariable). VS 2005 fixes this anyway in both languages.

3) "Optional" parameters actually violate CLS compliance because not all languages explicitly support optional parameters, and although there is a workaround, the proper way to provide optional parameters is through overrides. Allowing "nullable" optional parameters actually makes coding more difficult because a developer can't be sure what combination of empty or filled parameters will break the code (as is often the case).

4) This would be a nice addition to C#, but unnecessary with Intellisense. Try CTRL+Space :)

5) The handles keyword abstracts the object model. Handle re-wires the event behind the scenes. The problem with this is that you when you have multiple methods attached to an event, you can't determine in which order they fire.

6) There's arguably LESS typing in C#. The WITH statement is something that isn't used as often as the scope definition that makes c# less typing. Consider this:

If Not (Session["User"] Is Nothing) Then
If ((txtUsername.Text.Length<1) Then
Return
End If
If Not ValidateUser() Then
Return
End If
End If
============================
if(Session["User"]!=null)
{
if(txtUserName.Text.Length<1)
return;
if(!ValidateUser())
return;
}

7) It's just as easy to create an event in C#, and you don't need to use custom delegates. In fact, performance is better because the AddressOf statement creates a custom delegate, even if one is not needed. Again, the C# version has less code.

class Example
{
public event EventHandler SomethingOccured();
public void Method1()
{
if(SomethingOccurred!=null)
SomethingOccurred();
}
}

class Papa
{
Example oExample = new Example();
protected Papa()
{
oExample.SomethingOccurred+=new EventHandler(this.oExample_SomethingChanged());
}
private void oExample_SomethingChanged()
{
...
}
}


8) Exceptions are, BY FAR, THE MOST, and I repeat, THE MOST expensive native operation to perform in .NET and should NEVER be used to encapsulate functionality. This is a perfect example of what NOT to do in production code. Exception handling should be used to handle exceptions, and nothing else.

9) No argument.

#6. By Sysadmin. Posted on 3/17/2006 5:09:55 AM
>> I have emailed you about NO 10.. Please take a loot.. :-)

I don't think I got it (or at least I cannot locate it), can you resend.

#7. By Robert Bouillon. Posted on 3/17/2006 2:18:23 PM
Some would say #10 is that VB.NET is not case-sensitive.

#8. By Anonymous. Posted on 3/18/2006 1:43:15 AM
>> I'd like to provide some opposing points, not meant to be argumentative by Robert Bouillon.

Are you done now? Well, allow me to retort. (Sam Jackson in Pulp Fiction).


>> 1) VB uses 'implicit' casting, developer not aware. For veteran developers, this is VERY bad.

I agree that implicit casting is bad in principal because you don't know what is happening. But you also don't know what is happening when code "int i = 5" is executed. The OS may place the value into a register, or memory and the chip may cache it or now.

I disagree that it is bad for veteran developers, becuase they do know what is happening. It may not be good for newbies, but hugely convinient in getting started programming.

>>
3) "Optional" parameters actually violate CLS compliance because not all languages explicitly support optional parameters, and although there is a workaround, the proper way to provide optional parameters is through overrides. Allowing "nullable" optional parameters actually makes coding more difficult because a developer can't be sure what combination of empty or filled parameters will break the code (as is often the case).
<<

So what, if used properly, it's a huge boost to productivity.

>> 4) This would be a nice addition to C#, but unnecessary with Intellisense. Try CTRL+Space :)

Are you kidding me? Look at point 6 in the article to see what I mean.

>>5) The handles keyword abstracts the object model. Handle re-wires the event behind the scenes. The problem with this is that you when you have multiple methods attached to an event, you can't determine in which order they fire.<<

If this is important to you than use the delegate method and you'll know.



>>
6) There's arguably LESS typing in C#. The WITH statement is something that isn't used as often as the scope definition that makes c# less typing.
<<

I code c# all day long for a living. But when I do something for myself, I typically use vb 2005. When I think about it, With...End With construct is the only thing I miss from VB. It is HUGE when working with a lot of objects.

>>
8) Exceptions are, BY FAR, THE MOST, and I repeat, THE MOST expensive native operation to perform in .NET and should NEVER be used to encapsulate functionality. This is a perfect example of what NOT to do in production code. Exception handling should be used to handle exceptions, and nothing else.
<<

You are assuming that you know all the situations you'll run into coding wise. The example provided may not show the best practice, but just having it is good for when you need it.

Regards

#9. By Anonymous. Posted on 3/22/2006 9:26:20 PM
VB.NET is "easier". But it is a newbie language good for people just learning to program. Certainly one wouldn't want to actually create commercial products with it. I certainly wouldn't write an article claiming it to superior to C# :P

#10. By Stephen. Posted on 3/31/2006 12:05:37 PM
Ha ha ha,

This is really funny, I couldn't help laughing whilst reading this! Someone who obviously hasn't the brain power to handle a professional and enterprise language trying desperatly to defend this substandard 'basic'. I think you will find that the majority of the points you raise as being a 'benefit' of VB over C# is actually very bad coding practise.

I find it difficult to think of VB as a professional language, due to the poor syntax it presents to developers, ie.

C# VB
----- -----
this me
null nothing
abstract MustInherit

I mean come on, do you not understand what abstract means, or null. It is such a 'noddy' language. My advice to the author would be to hang up your coding gloves, and go and find another job. Or better still, carry on, people like you will keep me in contracts for the rest of my life!

Cheers,
Stephen.

#11. By VBISASIN. Posted on 3/31/2006 12:53:10 PM
My argument is

1. Casting: You don't understand the performance, maintenance and readability benefits of a 'Strongly Typed' language like C#. If your code is strongly typed enough then there should be few cases where casts are necessary anyway.

2. intellisense: An extreme over reliance on intellisense to justify a language is not an advantage. VS2005 now does this anyway but didn't miss it before.

3. Optional Parameters: Bad, Bad, Bad. Always use method overloads. Any idiot knows that.

4. With..End With. Never use it. Bad, Bad coding practice. Makes code harder to read just because the coder was Lazy.

5. Handles. Not so familiar with this. Sounds like a bodged up even model.

6. Less code in VB. Bollocks, bollocks bollocks.

7. Events. Obviously you don't get delegates. .NET 2.0 now has anonymous blocks for this, but I really don't see the point in it. It's far cleaner to have a separate method handle the event.

8. Error Handling. What the is this all about. Don't handle errors unless they need to be handled and NEVER handle events under a condition. What bollocks.

9. Switch Case statements. If your using switch statements then chances are there's something wrong with your code. Learn design patterns. You should rarely need to use switch blocks and if you are then try to refactor to a design pattern which removes the need for it.

10. Don't use VB.NET. Its nasty stuff.

#12. By Author of the Article. Posted on 3/31/2006 6:27:59 PM
Answer to #10. By Stephen
FYI. I code enterprise systems in c# all day long. See the related article up at the top.

Answer to #11. By VBISASIN
1. Yes I do.
2. Why are you using vs2005 then. Use notepad, it's faster.
3. Maybe, but it was part of VB6 and it is really convinient for small projects.
4. So you are knocking something you never used. To quote Jeff Atwood: "You have to respect a man who isn't about to let mere ignorance keep him from having an opinion." It does not make code harder to read - quite the opposite, particularly when you have several layers of objects.
5. Same as 4.
6. Same as 4.
7. I code c# for a living all day long. You don't seem to understand how the VB team simplified event creation. It has nothing to do with anonymous delegates.
8. Agree, but the capability is there in that rare case when you may need it. I hope you don't have the pomposity to foresee every possible situation.
9. You are living in the cloud and should probably get a job. Contrary to what you say, switch case statements are needed and won't get rid of them by sing design patterns.

#13. By Stephen. Posted on 4/3/2006 10:06:59 AM
Robert,

Thanks for the response to my arguments. Just a quick note about point 6, you say that you have to type more in C# than VB. I can't really see this as a positive or negative point. The size of the code has little to do with the language and more to do with the ability of the developer. You could write a mass of code that would perfrom some function, in either VB or C#. It could be written differently in a fraction of the code, both methods could be garbage.

Writing great code is not about how little code you can write, but about designing flexible software that is easy to maintain. In the words of Kent Beck, 'Anyone can write code that a computer can understand, great developers write code that a human can understand.'

Following on from your point, you could argue that a 'Mr Men' book is better than Lord of the Rings as it is shorter! Quality of code is not measured in its length, but content.

#14. By GavCost. Posted on 4/3/2006 11:26:41 AM
In reply to #9 it is exactly because it is 'easier' that I would rather use VB.Net (although my present employers insist on C#). The main challenge in development is not writing your own code but maintaining someone elses. I find the better intellisense makes understanding other people objects a lot easier, and case insensitivity is a lot better (I have taken over code that has both CSVFileConverter and CsvFileComparer, and am forever having to remember which one is which). But the number one thing is the immediate feedback of the error lines. I cannot count how much of my time is wasted in C# by pressing compile just to have errors reported back. I never have to wait in VB.

Having said that as a user of both languages I will disagree with a few of the points
4. With is OK in certain cirumstances, but I find overuse makes code hard to read.
5. Handles can sometimes not be easy to find (especially if a sub handles multiple events). Although slightly more code I would recommend adding and removing handers explictly.
7. Events may be easier in .Net but until I did them in C# I never really understood them, I was only copying what is in the books.

To finish with the analogy from #13. I have read Lord of the Rings four or five times and if someone asked me to look through it an fix spelling mistakes it would take me years and I would probably 'fix' things that are not broken (this actually happened in some editions). I've never read the Mr Men books but I guess I could fix their mistakes a lot easier. Most programs should be like 100s of Mr Men books (simple language, easy to understand, doing one thing only) than Lord of the Rings (complicated with a language of its own, jumping about between various story threads, and requires years of study to understand fully)

#15. By VBISASIN. Posted on 4/3/2006 1:00:55 PM
Answer to #11. By VBISASIN
1. Yes I do.

Why are you making the point then. You obviously don't

2. Why are you using vs2005 then. Use notepad, it's faster.

But I don't over rely on intellsense to write all my code for me.

3. Maybe, but it was part of VB6 and it is really convinient for small projects.

VB is convinient for small projects only!

4. So you are knocking something you never used. To quote Jeff Atwood: "You have to respect a man who isn't about to let mere ignorance keep him from having an opinion." It does not make code harder to read - quite the opposite, particularly when you have several layers of objects.

I used to use Delphi which has a very similar construct. I used it in my early days until I matured as a devloper and realized its bad practice. You'll get there eventually.

5. Same as 4.

6. Same as 4.

VB is actually much harder to read due to its stupid syntax. C# is much cleaner to read and understand. I even know VB6 developers who prefere c# examples because VB.NET examples are harder to follow.

7. I code c# for a living all day long. You don't seem to understand how the VB team simplified event creation. It has nothing to do with anonymous delegates.

Events have nothing to do with delegetes? Humm. I suggest you go back to basics.

8. Agree, but the capability is there in that rare case when you may need it. I hope you don't have the pomposity to foresee every possible situation.

Throw exceptions for a given condition not catch exceptions for a given condition.

9. You are living in the cloud and should probably get a job. Contrary to what you say, switch case statements are needed and won't get rid of them by sing design patterns.

I have been writing programmes for 25 years and have been a professional contract developer for 10 years, so I certainly have had many jobs and currently contract for a leading bank. I suggest you have a look at Head First Design Patterns. It puts things simply. That should help you. You will also find plently of examples where DP's eliminate switch..case blocks. Also, a basic understanding of OO helps, but coming from a VB background you probably have difficulty with that.

#16. By Stephen. Posted on 4/3/2006 2:45:39 PM
Good reply GavCost, I like the points you raise...

The one thing that case-sensitivity does give you, is that the case of the code does look the same no matter who develops it - it enforces a standard way of doing it. Without this, developers could capitalise keywords, etc... not a big deal I know, but it is something you just get used to.

You say, 'With is OK in certain cirumstances, but I find overuse makes code hard to read.'
Yes, I totally agree with this. I think if used in a small 4 or 5 line block of code, fine. But I have seen nested With statements in methods that are many pages long, and you totally lose track of which object the properties are referrring to.

'I have read Lord of the Rings four or five times'
Well done for getting through it. I love fantasy fiction, but I have never managed to get through this book - to be honest I find it over-rated, and tedious in places. Great analogy, I too would prefer to maintain a Mr. Man book rather than Lord of the Rings, and yes, code should be like this, short, 1 'story', and simple.

By the way, if you like Tolkien, you will love David Gemmell, who is a phenominal fantasy author, but this is a different website althogether!

Stephen

#17. By Author of the Article. Posted on 4/4/2006 8:42:03 AM
In response to comment #13 by Stephen.

>>Just a quick note about point 6, you say that you have to type more in C# than VB. I can't really see this as a positive or negative point. The size of the code has little to do with the language and more to do with the ability of the developer<<

I don't even know where to start. The amount of code you have to write does have a lot to do with the language. Why aren't using C++ or assembly language to perform the same trick then - they certainly give you more control? Secondly what is the point of refactoring, Code Rush and other products that shorten your development time by cutting down the number of characters you have to write. What is the point of efforts like the new Boo language, that tries to accomplish the same task?


>>Writing great code is not about how little code you can write, but about designing flexible software that is easy to maintain. In the words of Kent Beck, 'Anyone can write code that a computer can understand, great developers write code that a human can understand.'<<

Agreed. I submit to you that the VB way in point 6 is much cleaner than C# (not to mention much less painful). Particularly when you have an object hierarchy.

With thisObject.thatObject.ChildOfThat(index)
.ID = m_ID
.Name = m_Name
end with

is much cleaner than
thisObject.thatObject.ChildOfThat[index].ID = m_ID
thisObject.thatObject.ChildOfThat[index].Name = m_Name

#18. By Author of the Article. Posted on 4/4/2006 8:53:47 AM
In answer to comment #15 by VBISASIN

>>
1. Yes I do.
Why are you making the point then. You obviously don't
<<

You said and I quote: "You don't understand the performance, maintenance and readability benefits of a 'Strongly Typed' language like C#". All I said is that I do. Being an architect on a major project (being written in c#) is kind of a pre-requisite for that.

>>
2. Why are you using vs2005 then. Use notepad, it's faster.
But I don't over rely on intellsense to write all my code for me.
<<

Intellisense is a tool, it doesn't write code for you. Likewise vs2005 is a tool. You are rejecting one, but using another one? Makes no sense.


>>
4. So you are knocking something you never used. To quote Jeff Atwood: "You have to respect a man who isn't about to let mere ignorance keep him from having an opinion." It does not make code harder to read - quite the opposite, particularly when you have several layers of objects.

I used to use Delphi which has a very similar construct. I used it in my early days until I matured as a devloper and realized its bad practice. You'll get there eventually.
<<

Insults, last vestige of uninformed. Make sure and mention Hitler next, will you.

>>
VB is actually much harder to read due to its stupid syntax. C# is much cleaner to read and understand. I even know VB6 developers who prefere c# examples because VB.NET examples are harder to follow.
<<

I am a former vb6 developer, and I actually prefer c# over vb2005, but for completely different reasons. Both languages are equally easy for me to read.

>>
7. I code c# for a living all day long. You don't seem to understand how the VB team simplified event creation. It has nothing to do with anonymous delegates.

Events have nothing to do with delegetes? Humm. I suggest you go back to basics.
<<

Please re-read the statement. The way VB team simplified event creation has nothing to do with anonymous delegates. The simplification appeared in vb2002, way before the anonymous delegates. Why don't you actually fire up a vb project and actually see how events work there without making ignorant statements.

#19. By Stephen. Posted on 4/4/2006 12:35:07 PM
In response to comment #17 by the Author,

You say, '..I don't even know where to start. The amount of code you have to write does have a lot to do with the language. Why aren't using C++ or assembly language to perform the same trick then - they certainly give you more control?..'

My point exactly, if you want to write less code then by all means do use assembler, and take out all the spaces, but for me, the length of a piece of code does not have any bearing on the quality of it, which is I gather the point of this discussion, 'Which is the best language in terms of quality?'. This point is re-affirmed when it comes to 'With' clauses, the keyword does not make the code any more O-O, it doesn't make it more flexible, or extensive, the only reason to use it, is so that you don't have to type the object to which you are referring to. And if you look at your example, you have transformed 2 lines of code into 4, with no real benefit. I don't think either are difficult to understand, but I don't have a big issue with 'with' clauses over 4 or 5 lines, it is embedded, nested 'with' that is my bug-bear.


>> Secondly what is the point of refactoring,
Refactoring has nothing to do with cutting down the number of characters you have to write, Refactoring is concerned with , 'Improving the design of existing code'. So it could in fact add lines of code, if it makes it more readable and clear.


>> Code Rush and other products that shorten your development time by cutting down the number of characters you have to write. What is the point of efforts like the new Boo language, that tries to accomplish the same task?
To answer your question, what is the point? Not much point to be honest. The real goal and difficulty of software development is creating a flexible, and easily maintainable solution, the typing is secondary, and doesn't cause me any problems.

Stephen.

#20. By Andrew Vos. Posted on 4/12/2006 6:06:39 PM
Nice job Robert!
It's amazing how people try to defend how "powerful" their language is, even if they clearly don't know much at all. Basically they believe themselves to be geniuses because they managed to learn the "harder" language.

Had a good laugh at some of the comments on here.

Like this one for example...

7. I code c# for a living all day long. You don't seem to understand how the VB team simplified event creation. It has nothing to do with anonymous delegates.

Events have nothing to do with delegetes? Humm. I suggest you go back to basics.

#21. By Tom. Posted on 4/14/2006 3:09:31 AM
I have to say that half of these make me cringe. What you call more convenient and easier, I see bad programming techniques and practices -- case in point, the optional parameters. God, that's just hideous and lazy, and makes code more confusing to read.

As for intellisense support -- yep, some of that is true. As for the verbos-ity, you're relying on implicit casts and that's a no-no. But regardless, to me the verbose part isn't about more or less lines of code (I don't care about that) I care about the syntax and readibility. I find VB's verboseness just irritating (that's a personal opinion). For example, "dim a as New Textbox" -- AAARRGG! That's bad for a few reasons. And if you don't like "Textbox a = new Textbox();" then you'll be able to do something like "var a = new Textbox();" in C# (as a compiler shortcut) ...

#22. By Anonymous. Posted on 4/14/2006 5:06:22 PM
Tom (#21). As far as conviniences go, I agree, some of them are bad practices. But those conviniences are huge when you are trying out something new in a throwaway project. They let you explore faster. As a rule, if something is too time consuming and difficult - people won't try it out.

As far as the implicit casts go, c# has them too.

ArrayList aList = new ArrayList();
aList.Add("this");
aList.Add("that");
aList.Add("and a bag of chips");

foreach (string s in aList)
...

There is an implicit conversion of an object to string in the foreach, so c# is not immune from this sort of thing.

#23. By Tom. Posted on 4/14/2006 6:18:19 PM
Reply to #22:

Good point about the casts, and while that example is true, I'd argue that that the example itself is flawed and should use a strongly typed collection (ie, generics) to avoid the boxing/unboxing and provide type safety. (You can do that in VB, too, I realize.) Generally speaking, C# is much more strict about this sort of thing.

About prototyping and "testing it out" code -- what you said is true, but as one who develops both, to be honest, I can develop faster or at least just as fast using C# than I can in VB.NET. (I'm not claiming that the language is doing that for me, perhaps I just have more affinity with the language.) However, my main problem with VB.NET, technical reasons aside, is what I call the "code suck percentage."

I've worked for a lot of different companies and on many different solutions. Maybe it's just my microcosmic view, but VB and VB.NET code has the largest percentage of "sucky code" ... it's code that is engineered wrong (by someone who never really learned the appropriate way), code that's completely unoptimized or more difficult to read, or code that's been upconverted since VB3. It's code that people said, "Hey, we don't need no 'option strict' or 'option explicit'."

Is it possible in VB.NET to write code as good as C#? Absolutely. Is it possible for C# code to suck more than VB.NET written code? Absolutely. But unfortunately, of all the projects I've inherited in the last 12+ years, VB-based projects have, by far, given me the most headaches. C# isn't immune to it, but the percentage is lower. At least that's been my experience.

I have my own theories as to why, but it doesn't really matter. The reason why I've babbled about this is becaues the number one reason I hear when questioning a design is, "Well, that was prototype code and we never expected it to be used in production, certainly not for this long." Or, someone cut their teeth on VBA and it's grown into some monstrosity.

#24. By Anonymous. Posted on 4/15/2006 9:17:40 PM
Reply to Tom, post #23:

>>
I'd argue that that the example itself is flawed and should use a strongly typed collection (ie, generics) to avoid the boxing/unboxing and provide type safety. (You can do that in VB, too, I realize.)
<<

We are not arguing about the validity of the example (e.g. generics here are the way to go), but that the construct is available in c# and allows the code to be borked, just like in vb.net.

I agree 100% with the rest of your comments about inherited vb projects being a lot of yucky goo. That's just the way it goes. VB certainly has years of baggage while c# could selectively bring forth features of c/c++/java that they wanted. I have projects that I started in VB2, then VB3->VB4->VB5->VB6 - they certainly still have a ton of code that's in modules instead of classes. In addition, in corporate environments some business person starts the person in VBA, then it is passed on to IT to deal with it. That's where
we come in and have to deal with the crap code.

#25. By AnyMouse. Posted on 4/22/2006 6:22:52 AM
For me the most important factor is time to market, then maintainability.
If you are unable to locate the required number of appropriately skilled resources for your chosen language, you had better switch languages.

-VB.net beats C# hands down on strict typing....in vb its just an option you can enable or disable depending on your requirments.
-Speed & Optimization are not factors. If you need fast optimized code it will be the experience of the designer & developer which will be the biggest factor.
Poor design will be inefficent in any language. Plus it is cheaper to throw hardware at a problem than developers.
-90% of good code does not need to be optimized for speed (unrolled loops anyone?). I would rather have the time spent on making a more stable application than a faster one.
-"With" generally sucks...It used to be much much faster to execute...probably still is. Bad programming habits exist reguardless of the language.
-Personally if I have a few minutes to quickly glance over 1000 lines of code. I find vb.net much easier to read "SomethingOccurred+=new EventHandler"...confuses addition operators you have to know additional information to determine if it is a string being concat, number added, event attached, etc... should be more intuitive read easier "SomethingOccurred.AddEventHandler(SomeEventHandler)"
-VB in most cases requires less comments and reads more intuitively.


That being said.. we live in a world where most project have a short deadline and a limited budget.
I have never had enough time, nor enough skilled developers for a project.
I am often stuck w/ a bunch of cheaper lesser experienced programmers...If I let them loose in C# (which is IMHO a better language) we would never meet the deadline, budget or code quality.

Try to sell your C#.net project vs vb.net to a manager...in the end the bottom line is someone makes the decision by looking at a few numbers on a piece of paper..can you get it to market on day X for Y dollars.

#26. By Tom. Posted on 4/24/2006 6:07:03 AM
AndyMouse...

"-VB.net beats C# hands down on strict typing....in vb its just an option you can enable or disable depending on your requirments."

This makes me want to break down and go postal on any developer who does this. Seriously. You should N E V E R require or think it's a good idea to do this. Back in the pre .NET days, I had worked on projects where the previous devs thought it was ok to disable option explicit. It caused so many problems. I think I'm going to just flat out refuse to work on any project where this has been done.

So in my mind, C# wins hands down simply because this isn't an option. I agree with some of your other comments, but I think readibility is a personal taste. I find C# reads easier ... but that's just my opinion.

#27. By Stephan. Posted on 5/13/2006 12:10:27 AM
Come now boys and girls.

They are both great languages. If any one of them were not, then many business out there would be wasting ther time and money developing applications.

VB has made business and desktop applications for the masses a reality waaaaaay back. It had its issues, runnig against a runtime and so forth, but it got the job done.

With .net and Visual Studio, traditional C++ and Delphi developers now had a language that made it just as easy, with the syntax and rules they were used to. And now they are also executing against a runtime.......sort of.

This conversation will go on forever, but when it comes down to it, good programming skills makes you a better developer in .net, not the programming language.

Now go out and code, and stop whining.

#28. By uhhhclem. Posted on 6/1/2006 8:32:13 PM
Re #22: That's what generics are for. That C# does run-time casting under some circumstances sure as hell doesn't make it a good thing.

As for With/End With, in C# I typically do something like

Potrezebie p = foo.bar.bat.potrezebie;
p.prop1=value1;
p.prop2=value2;
p.prop3=value3;

Not entirely equivalent to With/End With, as creating local references isn't free, but it's good enough for most cases. And not that it matters, but it's fewer lines of code.

#29. By Chris Simmons. Posted on 6/2/2006 11:50:39 PM
99% of VB code is case insensitive, C# is soo annoying now i have to worry about case sensitivity, it's hard enough to find a programmer that can actually spell let alone worry about case.

#30. By James. Posted on 6/3/2006 12:57:30 AM
I think most of the flaws in your anti-C# arguments have been pointed out already, but one I'm surprised nobody mentioned....

VB.NET has the "With... End With" statements... they were a bad idea in 6.0 (exceptions failed to decrease the reference counters, leaving memory leaks), but I'm not sure how well they work in .NET. I don't like to use them for clarity's sake, but that's a personal preference.

Along similar lines, C# has the "Using" block, such as:
using (ClassBlah bing = new Blah()) {
... do stuff with bing
}

The using block ensures that objects implementing IDisposable are properly disposed when the code exits the using block. Whereas the With block in VB requires an instantiated variable, the using block in C# instantiates and disposes an object in one fell swoop. Very nice!

I have to agree with Robert... cases insensitivity alone makes me long for VB :`( That should be number 10! Either that or the apostrophe comment... so much cleaner than //, /*, or ///

#31. By Daniel Clarke. Posted on 6/3/2006 4:49:56 PM
I write VB and C# professionally and in terms of the languages themselves they are each as good as each other.

What *IS* annoying however is VS's implementation of C#. It's as if they only half-finding writing the IDE for C# compared to VB. THings like Intellisense for C# really SUCKS, autocomplete sucks, and VS does not finish half-written code for you (in 2003 at least). Call me lazy but I really like the way VS will type all the "End If" and "End Sub" parts for you once you start to write "If something then".

I agree strongly with poing #2, this is infuriating; however this is NOT C#'s fault but VS's fault, it's important to make the distinction.

#32. By Ted Whitton. Posted on 7/3/2006 11:23:11 AM
Well interesting debate. But overall I would say this is exactly the sort of thing that gives us programmers a bad name. You guys need to put this in the context as was quite rightly stated above, that of productivity as well as the BUSINESS requirement.

The business doesn't give a flying fig about strongly or weakly typed languages and without a doubt it is possible to write RUBBISH applications just as easily in both VB.Net and C#

So what I'm saying is Don't waste your time and prodigious brain powers debating something that at the endo f the day is IRRELEVANT and does not matter. Concentrate on what is important, delivering good apps, that are used, easily by the end user and make a difference on the bottom line.

IMHO
Ted

#33. By rajesh. Posted on 7/5/2006 5:14:18 AM
great one,reason 2,6 and 7 are nice one to know...................

#34. By Tehl. Posted on 7/12/2006 4:05:51 PM
In a word: bollocks!

#35. By Ashish Patel. Posted on 7/18/2006 7:14:19 AM
These all have been solved into .net 2.0 so check first then write any statement.

#36. By Anonymous. Posted on 8/8/2006 3:41:22 PM
I agree that VB.NET is better, and I hate C# programmers and wish death upon them all; however I think the break statement in C# (which was just stolen from C, like most of C#) is also useful.

#37. By Radu Serban. Posted on 8/12/2006 8:29:59 PM
Thanks #36 for wishing me dead :) Maybe you just have a problem with those that use things you don't understand...

On a more serious note - I really don't like the verbosity of VB.NET. If I look at an existing program I find it really hard to separate the pieces of the code. I just see alphanumerics and parenthesis everywhere and I have to spend more time to read them. In C# that's much easier, a glance is enough for most of the code. I also don't like the separation between functions and subs - IMHO C# is better in this respect with a void "return type".
Other things that increase verbosity in VB are the casting operators CType(..., ...) - they make the code harder to write and read. And also the lack of the 'as' operator which makes you write more code in VB to compensate for it.
For .net 2.0 C# supports nullable values and the usefull ?? operator - another thing that VB is missing. Oh, and should I mention the horror: x is nothing, x isnot nothing. Compare this to x == null, x != null.

There are some things that I like about VB. I like optional parameters. Instead of several overloads you can use one method with default values. I also like the idea of more indexed properties for a class (instead of a single one, as C# allows).

I'm using both C# and VB, but I have to say that VB is by demand, and if it were my choice I wouldn't use it at all :)

#38. By John. Posted on 8/13/2006 4:00:32 AM
I am a professional VB.NET (Or now VB 2005) developer. I work with some hotshot C# programmer now and he knows very little how to organize his IDE, knows nothing of macros or snippets. When a problem occurs he tries to write code or methods that may already exist in the .NET FCL.

So my limited experience with issue is that my friend is an excellent programmer but lacks knowledge of the FCL and he does not leverage other things to his advantage. His laptop is a mess, unorganized. He complains all the time that I need to get up to speed in C#.

Our company develops software for the military turning original source schematics into troubleshooting tools. I see no need use C# at all except to appease him which I won't do. I think people should leverage their language of choice to the most if .NET is what you happen to be programming in. That is what the dotnot platform was designed for specifically, multiple language, one platform. So, if VB.NET programmers are being intimidated to learn C# just to appease somebody, I would say kiss my a... BUT if you want to learn C# because you want to learn it to broaden your horizons, all power to you. I love America.

John

#39. By WS. Posted on 8/18/2006 12:51:19 AM
Man, =) this is funny. You guys have been fighting over these ten reasons for months. What a battle.

I use both languages. VB for living and C# for hobby. Knowing both languages is great. =) Easy to score a job, especially with .NET 2.0.

Chosing a language for coding is one's decision. =)

#40. By Anonymous. Posted on 10/6/2006 5:03:35 AM
Hey, #10 the best part of VB.NET vs. C#. Background compiler.

#41. By Echale candela. Posted on 10/9/2006 9:18:00 PM
ouch. I agree with stephan.. couldn't help laughing for myself when reading this article.

#42. By VB loser. Posted on 10/25/2006 12:34:51 AM
my language is better than *your* language....

who cares...VB has pretty crap string handling capabilities - can't come close to perl

#43. By Decio. Posted on 11/23/2006 3:55:13 PM
Intellisense being a reason is the most stupid thing I ever seen. Now go back to VI, you spoiled brats.

#44. By Amin. Posted on 12/26/2006 1:17:49 PM
All the C# users on the world explain C# such a Pro Language ... Why?!

That's a bug only!

#45. By AES. Posted on 1/11/2007 11:01:36 AM
Do you think a case provide better error checking than a bunch of nested IF statements? Why? or Why not

#46. By Fred. Posted on 1/23/2007 6:13:33 AM
I think Vb is for children

#47. By pro c#. Posted on 3/13/2007 9:29:09 PM
The concept of Namespace seems like halfway there in VB.net compare to c#

#48. By pro c#. Posted on 3/13/2007 9:31:57 PM
simple statement in c#
m_focusItem = Session["focusItem"] as string;

when you translate it in vb.net
m_focusItem = CType(ConversionHelpers.AsWorkaround(Session("focusItem"), GetType(String)), String)

Where can I find ConversionHelpers???

#49. By lanpipi. Posted on 3/21/2007 1:57:20 PM
Do
Dim attempt As Integer
Try
' something that might cause an error.
Catch ex As IO.FileLoadException When attempt < 3
If MsgBox("do again?", MsgBoxStyle.YesNo) = MsgBoxResult.No Then
Exit Do
End If
Catch ex As Exception
' if any other error type occurs or the attempts are too many, do the following.
MsgBox(ex.Message)
Exit Do
End Try
' increment the attempt counter.
attempt += 1
Loop

in C#,to realize the same function,we can use which statement?

#50. By pgklada. Posted on 3/24/2007 9:09:51 PM
I started with C# several years ago, but I now prefer VB.NET over C#, mostly because of loose casing and better intellisense (although for something like ten years I wrote C programs in system tools, middleware, networking and hardware handling areas). Handles keyword is nice too and other arguments are of less importance.

#51. By Anonymous. Posted on 3/29/2007 7:49:28 AM
>>>Hey, #10 the best part of VB.NET vs. C#. Background compiler.

This the most part I don't like. When I'm doing a huge project with VB.NET, it make me angry by slowing..

and I hate ( ). They used a lot of ( ) in VB. I only want to use in function call n def.
(I most part I don't like () is in Generic.)

and miss out conditional operator (? :).

and consider that..
string sql = String.Format(@"SELECT
{0}
FROM
{1}
WHERE
{2} = '{3}'",
COL_NAME, // {0}
TABLE_NAME, // {1}
COL_ID, id); // {2}={3}

I can't comment like this in VB. When I doing a long SQL, I do want to put comments like that.

#52. By Hitesh. Posted on 4/4/2007 10:03:18 PM
One Negative point about VB.NET, It misses the Continue statemet similar to C# or C/C++. It's very important to have it.
- Though both have equal pros and cons from diff. programmers and needs point of view.
- I like to know both as much as I can, So as to use them both most productively...

Cheers... all

#53. By Anonymous. Posted on 4/19/2007 7:55:40 PM
How about it's not case sensitive for #10.

#54. By LMO. Posted on 4/25/2007 12:47:55 AM
I'm going out on a limb with this, but I think VB.NET and C# will merge someday. With .NET, following what someone has written in C# (I'm a VB.NET developer) is possible. It is like "Hey! I can actually follow a seminar where all the examples are in C#". I run a development shop and I would never want to hire someone with an extreme language prejudice on my team. For the most part a lot of you have raised interesting (and very good points) but if someone is that set in their ways about a language he or she is surely going to be hard to budge in other things. Now what would be funny is putting on hard headed VB programmer next to their C# counterpart for a good session of pair programming!!!!

#55. By Anil. Posted on 4/26/2007 7:36:09 AM
Despite of having many reasons that VB.Net is better than c#, C# has good looking over VB.Net

#56. By Stonkie. Posted on 5/3/2007 10:14:17 PM
This will not work in VB.NET, the second condition is calculated and raises an Exception even if the first calculates to False. This also means a performance hit in normal situations...

If Not ReferenceEquals(myString, Nothing) And myString.Lenght > 0 Then
' do action
End If

If (!myString == null && myString.Lenght > 0) {
// do action
}

#57. By Radu Serban. Posted on 5/4/2007 6:55:01 PM
It is possible to do that in VB.NET, altough in an awkward way:

If Not ReferenceEquals(myString, Nothing) AndAlso myString.Length > 0 Then
' do action
End If

This will behave exactly like the C# counterpart. Also you can write this a little shorter:

If myString IsNot Nothing AndAlso myString.Length > 0 Then
' do action
End If

#58. By Starhawk. Posted on 5/8/2007 3:16:48 PM
I find it very amusing that 3 years after this post people are still commenting to it.
I have enjoyed this so much I felt I needed to contribute my two cents worth. To the person who wanted to comment every line of his dynamic SQL I can have two words for you, stored procedure.
In 25+ of developing software I have learned that flexibility is the most important thing to have especially in the Microsoft world where things change all the time.
I have written C and as a personal preference I don't particularly like case sensitivity, Curly brackets or semi-colons. That is just personal preference. The person who opined that the end result is what matters had it right. How we get there is not important especially in .Net where all languages are created mostly equal.
What is important to me having spent most of my life looking at other peoples code is maintainability and comments. I don't care what language you use as long as you remember one thing that has not changed since I learned programming KISS, for you younger sorts, Keep It Simple Stupid.
While I don't have an axe to grind I will make a note that when I was coding in C I was confronted by lots of bright people who liked to show how clever they were in putting as much functionality into a single line of code as they could. That is so bad in a corporate workplace that I can't begin to rant on it. Clear and maybe even verbose is good, clever is bad. You never know who might have to fix your code someday so it better be clear to even someone with a smaller IQ than you what it is that you are doing.
Yes this is possible in VB or VB.net, in fact I am working with a lot of bad VB.net code right now but there is nothing you can do in VB that is as bad as having function pointers going to the wrong place. Even that pales in comparison with some of the mistakes I made when I was learning assembly, there is nothing quite as bad as writing code that modifies itself during runtime. Try debgging that sometime.

#59. By Anonymous. Posted on 5/31/2007 7:15:22 PM
Reason 9: you do not want to miss including "End Select" in place of c#'s "break" because if your variable satisfies more than one condition, they all those case blocks will execute. And, don't tell me: "how's that possible? 1 can only be equal to 1". Look:

[pseudo code]
switch(int variable)
case 1:
// do magic
case > 0:
// do magic

If you don't break out the first case, you'll have the second one execute also.

#60. By Josh Stodola. Posted on 6/6/2007 9:38:46 PM
Well, I am bi-lingual. I know both languages very well. This is due to my background in Java, but to be completely honest, VB.NET is so much easier than C#

Seriosuly, you can determine this by looking at any program. The syntax of C# is so cryptic with curly braces, semicolons, and everything lower case. It is almost a pain to look at! VB.NET is a very mature and clean language, it is so much easier to write code with. Think about creating a basic class with properties in VB. You have to type like 3 words, press enter, and the entire get/set blocks are all created for you. Is this a dream or what?!

VB.NET is a programmer's programming language. It is easy to code with, easy to read, and if you understand OOP you can create very manageable code with it. I know C# equally as well, but I would never choose to code with it. That's why I am developing for the .NET platform, so I dont have to put up with all the ugly code.

If I wanted to be forced to type in lower case and use curly braces instead of words, I would be writing Java right now. C# is simply a migration tool for the legacy C programmers. Enjoy it, Im sure it will stick around, but VB is NOT going anywhere.

And who in the hell gave it the name C-sharp anyways? I think it should just be called C.NET

#61. By M. Posted on 6/7/2007 7:59:11 AM
Interesting debate, that it seems will never die! So I might as well throw in my thoughts

This article, and some of the comments has some fundamental fallacies.

1) In some cases the author singles out failings/abilities of the IDE rather than the languages themselves. You cannot claim that VB.NET is better than C# because it has better intellisense!
2) "Clean, readable syntax" is a completely amorphous statement that ultimately means nothing. To Arabs, Arabic is a clean, simple and understandable language. This is not the case for those of us who don't speak it.
3) The with restriction in c# can be easily worked around

SimpleObject a = VeryComplexObject.MoreComplexObject.ComplexObject.SimpleObject;
a.Date = DateTime.Now;
a.Name = "Me";
a.Age = 10;
...

4) Some of the arguments are felled by personal preferences. It is purely a matter of opinion whether casting an into to an enumeration is necessary. Personally I would pick the enumeration any time, but that does not mean the languge of choice is lesser because of it!

5) "Less typing" is the classic case of seeing the trees rather than the forest. The aim of systems development is developing systems not the source code. You cannot make sweeping statements that more code is somehow inferior to less code. Not necessarily! Saving keystrokes is fools' economy

#62. By Henry Jones Jr. Posted on 6/14/2007 11:38:46 AM
This article is the most bizzare piece of rubbish I've come across in a long time. The author, despite his claim to 'spend all his days writing enterprise applications', has no business being anywhere near a keyboard. Certainly I would never employ him, and neither would any developer in their right mind. I would recommend any serious developer (or budding serious developer) to completely ignore everything you see on this page - it was written by someone with such a poor understanding of the CLR it's almost comical.

#63. By Amit. Posted on 6/21/2007 2:11:12 PM
I have read all the comments. Most of the discussion moves around only two points
1] Clarity of Syntax
2] Less typing

If only these two points are to be taken into consideration then Java is way ahead
of both c# and vb.net. Its well known that Java is much harder to learn and use than vb.net
and c#. That is what Most of the .NET guys say! .NET provides you most of the basic functionalities. The only advantage that .NET has over Java is Rapid App. Development.
Now about the difference between vb.net and Java. It surprises me that none of you have pointed out this difference. In c# [even in c# 2.o ] the syntax for inheritence is

class x : y
{
------
}

When you define intefaces in c# you have to use same syntax. How in the world one would know whether "y" is a class or an interface? Don't tell me that you can use some Hungarian notation for classes and interfaces. This is in obviously not a good sign for an OO language.

Whereas VB.NET has two seperate keywords as "Inherits" for inheritance and "Implements" for Interfaces.
What you have to understand guys is that most important part of any program is documentation. Without it your program is dogshit. VB.NET just does that! That is why it looks so
verbose! But that does not mean that vb.net is better than c# or vice-versa. Its all about the guy who uses that language! Also in the industry you don't have personal choice of the language. So you its not good to love one language and hate all the others. So don't be emotional, be practical.

#64. By kfinley. Posted on 6/22/2007 9:13:10 PM
VB has always been a language for hack programmers who don't really want to understand how a computer works. If you are too dumb or lazy to read a C style language, then you are probably writing crappy code to begin with...

#65. By nick chan. Posted on 6/26/2007 2:06:42 AM
hi, i'm no expert.

I code in VB.net. what i miss is the ?: operator and the use of braces. IIF() is 'almost' an alternative, though very different.

When I code in C# (rarely), I miss the Object.AnyProperty_AnyMethod calling. (I don't know the workaround yet). That's me being lazy.

Another thing, byRef/byVal are many times oxymoron.(byval for non primitive works like byref)

I didn't know there's no WITH keyword in C# (cause i know javascript has it).But potential to make vb.net code unreadable with WITH keywoard is huge. (namely nested WITH)

some mentioned Dim A as New Textbox is funny. But I think you can do Dim A as TextBox = New TextBox()

Intellisense is an IDE feature, not language

I use lots of OOP in my vb.net projects. Overloading, inheritance, etc... Which is way easier in vb.net/c# than delphi.

Some said about the AddressOf thingy in C#, there's also AddHandler Object.Event, Addressof Sub.Easier in VB.net i think, but the IL code might be different? i dunno

To me, both are OK languages. Thanks to Anders Hejlsberg's influence and vision.

Delphi is still most beautiful to me.

I could not see my self reverting back to Delphi. Beautiful code, stupid IDE !!!

#66. By Toomas. Posted on 7/8/2007 9:46:24 PM
There is nothing to do when you are bad coder and writing ugly code...

I'm sure you use "Using". If you don't need to dispose something then "With" very nice.

Let's assume you need to execute sql stored procedure with 2 params:
Isn't it nice: (100% intellisense)


With SqlHelper.StoredProc("Stored proc name").ExecuteScalar

.AddParam("@Param1",Param1_Value)
.AddParam("@Param2",Param2_Value)

Return .GetData()

End With

#67. By Anal. Posted on 7/20/2007 8:36:35 AM
Its quite good reasons. but some more technical
reason i m expected to know which is better either c# or vb.net.

#68. By Shannon Barber. Posted on 7/25/2007 12:31:58 AM
I've been working with a medium sized VB.Net (1.1 and now 2.0) program (and growing) project for a few years now.
If we could go back and change our minds, we would not have chosen C# over VB.Net
We are exploring options now to convert the entire code-base to C#.

#1 results in buggy code and sometimes exceedingly poor performing code (1 late-binding call can ruin your day)
If there needs to be a cast, I need to see it since it means someone screwed up somewhere and I need to either educate one of the programmers or I need to fix my design

#2 Intellisence with MSVC 2005 is better in C# than VB, this particular example works as desired in C# and see #6 below

#3 Optional parameters were intentionally not implemented in C#, you should prefer overloading to optional parameters
Two ways to do the same thing means mixed methods at best, buggy code at worst. Multiple Nothing parameters is a nightmare.
Software is built on good names and guarantees... not "who knows what's in the box!?"

#4 With is nice (VB only) but so is operator overloading (C# only)
Example given is a good one, but make sure your programmers aren't using with instead of writing sub-routines/methods - we have lots of with code-bloat...

#5 Handles are nice (VB only) but so are anonymous methods (C# only)

#6 Same issue as #3. In C# when you type "= New" it pops up with the detected class-type. VB doesn't. If you have more than 1 New method in the class this is annoying because you may need to new members different ways

#7 Very similar to #5; to raise an event in C#, you just call it...
VB
RaiseEvent UberEvent
C#
UberEvent();

#8 Whomever added that feature to VB needs to be taken out to the woodshed.

#9 Large switch statements -> crappy design -> crappy code
You can't intentionally fall-thru with the VB code which results in code-duplication, code-duplication -> bugs

#10 Lack of case sensitivity means you have to come up with something to name Property and their data by... we're taken to
Dim myName as string
ReadOnly Property Name() as string
Get
return myName
End Get
End Property

C#
string name;
string Name
{
get { return name; }
}

#69. By ange Rapallo. Posted on 7/30/2007 5:21:07 PM
This is correct to an extend, C# is not an Application Programming Language in the true
sense of the word this can be easily seen i the fact that C# programmers can use Pointers
why wouldn an application programmer whoc needs to be focused on the Bussiness Model and
rules care much about how you go about getting Memory.

I think VB is good for Small to Medium size Application mostly Destop and small Networks with
little backend processing. on the other hand C#, C++ and the like are good for Enterprise
Appluications and System Development....

#70. By Mark. Posted on 8/17/2007 4:48:14 PM
I was using VB for about 6 years but knew I would have to eventually learn C#. There are trade-offs with both languages. The worst point with C# is the case-sensitivity but the intellisense with 2005 has made things much easier. I like to be well-versed in both languages. Its hard to understand why we cannot have a uniform development language.

#71. By Killer. Posted on 8/18/2007 2:14:28 AM
The most stupid article!!!

#72. By Amir. Posted on 8/26/2007 11:51:29 PM
Im Completely Agree With The Article and think that we have more in VB.NET that make it better than C#...Included:
1.Static Variables in Subroutines
2.Redim Preserve Keyword
3.Parametrized Properties
4.My Namespace
5.Using Block (Using ... End Using)
6.Parametrized Properties
7...In know there we have 7, 8 nine and may be more...But Its just me..

#73. By Pravin. Posted on 8/27/2007 1:31:41 PM
u've changed my opinion about vb.net. Really!!!!!!!!!!!!!

#74. By Anonymous. Posted on 8/27/2007 11:39:43 PM
I won't be coming back to this page but I was so horrified by what i seen here i felt the need to post.

First of let me say this is "LAZY" programming, it is more beneficial to you to know WHY something has to be casted, it shouldn't be a burden but a duty.
Second With and End With is probably the worse thing to use for code readability, yes in your example it was fine, but imagine when you have a 100 line block of code that is using .Func/Var to pass params around or to manipulate data, STOP BEING LAZY
Third, BECAUSE PEOPLE LIKE YOU, i have to spend my weekend converting 5406 missing casts in a project because our company policy is now OPTION STRICT, 5406 missing casts is from just one developer, imagine if all 4 of us neglected them.

The absolute worse thing in VB.NET is the ability to create a variable without a type, reflection at runtime anyone?

Stop being a lazy ass programmer, stop bitching that c# MAKES you apply best practice programming.

This is truely a unbias opinion, i've used vb/vb.net since i was 12 for about 10 years, i now use c# mainly for the last 2 years.

C# has a powerful syntax that releases more stable code by forcing a programmer to adhere to rules.

#75. By Right Said Fred. Posted on 9/10/2007 6:53:20 AM
People tend to forgot the most important argument: C# is sexy!

#76. By Anonymous. Posted on 9/15/2007 2:26:05 AM
Wtf, I don't get why they made C#.net, programming is not suppost to get harder. Microsoft is advancing the VB language intensivly, and it can already program Xbox360 games, and work with the Direct X9.0, I think 10s coming soon.

#77. By Anonymous. Posted on 9/17/2007 2:25:40 PM
#76.
Xna is supported more towards c# then it is for VB.Net. Directx 10 is already been supported for XNA since about May. :)

#78. By hui. Posted on 9/28/2007 11:25:24 AM
how to increase the time? For example i have a buttom, textbox and label then i choose the time i need to incease in the textbox and the time will show on the label when i click the button. thanks...

#79. By Peter Bromberg. Posted on 9/30/2007 12:52:55 AM
I just have to shake my head and laugh when I read posts like this.

C# was designed from the ground up to target the .NET Framework. A significant part of the Framework itself is written in -- you guessed it, C#.

I programmed in VB classic for years. I wouldn't touch it with a 10 foot pole.

#80. By jasonxz. Posted on 10/12/2007 5:27:50 PM
I grew up writing VB. I've done C# for the last 4 years. I'm doing VB.NET right now. Oh how I wish I was doing C#.
A couple of things:
1. The intellisense in VS2K5 for C# is far superior to that of VB. Why? The VB version makes me wait and wait and wait. OMG! I'm still waiting. Drives me nuts.
2. If you're writing web apps and doing it well, you're already writing brackets and semi-colons. Why would you even think of switching back & forth between 2 completely different syntaxes? This is why I wish I was still doing C#. What I've found is that the web apps written in VB are far less efficient b/c the developers are scared of javascript and handle EVERYTHING on the server through postbacks where they can use that familiar VB syntax. It's just scary. Of course, they could use VBScript on the client in an intranet environment. Ouch.

#81. By Martin. Posted on 10/16/2007 11:31:58 PM
Ok - cards on the table - at work I mainly use VB6, though I'm starting to use VB2005 a fair bit now as well. When working at home, if developing for dotnet, I prefer C#. Not realy sure why - I just find it easier to think with - might be a throw back to my first serious project being in C++. I've also had a brief entanglement with Java, so, framework aside, I feel at home...

Language wars are a bit pointless - people like what they like, and that's the way of it. Now that we're all running under the CLR, who cares? I agree that default valued parameters in c# are perhaps the one thing I feel it is missing, but as the c# proponents have said, it's not exactly rocket science to achieve via overloading... My fellow VB types may scoff, but sometimes there's a lot to be said for appreciating what is happening "under the hood".


What does drive me nuts though, and my own firm are particularly guilty on this one, is people's steadfast refusal to try out the alternatives. Some of my colleagues exhibit a regious, if not fanatical hatred of anything that smells like a semi-colon...

Martin

#82. By Brice Richard. Posted on 10/23/2007 2:56:43 PM
I don't know if anyone has suggested it in these responses (I didn't read all of them) but for me, one of the BEST reasons that I find VB.Net is better than C# in which to program a solution is the MY namespace in VB.Net (2005+).

Anymore questions?

#83. By Mohamed Kassimu. Posted on 10/27/2007 4:27:20 PM
Yeah, it's good to hear that the vb.net is better than the c#. But the question is that, is it possible to handle the data concurrencies? And how can performing that?

Nice evening.

#84. By irene. Posted on 10/29/2007 7:17:25 AM
agreed..haha. always feel that C# is so troublesome..but the programmer of c# claims VB.net or VB2005 is not as powerful as c#..

#85. By Joe Programmer. Posted on 11/9/2007 10:20:56 PM
I cut my teeth as a 12-year old programmer on C-64 BASIC. In my later teen years I taught myself C and C++. My first technical, yet non-developer position required me to learn FORTRAN. When I began working as a professional developer it was with pre-.NET VB. Later I moved onto Java and currently use .NET.

I write and maintain several intranet applications written in both VB.NET and C#.

In all my experience though I would have to say that maintaining previously written VB code was by far the worst. Not because VB is not a capable language but rather it would seem that many (not all) VB coders are either lazy or just not very good.

#86. By Joerg. Posted on 11/14/2007 9:05:57 AM
I'm forced to write code in VB.NET in the moment. I'm used to C, Java and C# with about 5years of experience in each language. Oh well, I did some VB6 stuff in the early beginning of my career.

So many are talking about easy and faster programming in VB.NET. The hell, do you guys know the basic rule in computer science which is "Programming against interfaces not an implementation".

With that the short declaration:
Dim x as New y
just sucks.
Dim x as IY
x = New Y (better someFactory.GetY())
someFactory needs to be input by Dependency Injection (DI)

Have a VB.NETler ever tried to implement an interface in VB. This results in a mess of writing code.

All the mentioned points seems to result in dirty hack code by people who have never been educated in computer science. I even guess VB.NET guys write code like this:

Dim itIsTrue as Boolean = True
IF itIsTrue = True THEN
END IF

Just my humble opinion after 1 week of VB hell.

#87. By Anonymous. Posted on 11/21/2007 9:15:19 PM
Having programmed for the past 25 years and coded in languages from BASIC, Assembly, Pascal, T-SQL, VBA, VB .Net and C# .Net (to name a few languages I have used) I have to say that I find C# by far an improvement on VB .Net.

As a programmer C# encourages better OO design and programming.

The thing about VB .NET is that is is easier to code with but it is also easy to write very sloppy code and I like strong typing.

Okay the case sensitivity is a bit of a pain but the intelisense IDE sorts this out if you use it correctly.

By all means praise VB .NET but I think you will find a lot of people who have programed in both languages opting for C#.

#88. By ashfaq. Posted on 12/9/2007 12:00:40 PM
thank u


i found that u have given agood article compare to other article c# better than vb .net

#89. By F MICROSOFT. Posted on 12/17/2007 9:36:36 PM
VB AND C# BOTH BLOW EQUALLY. THEY ARE DEPRESSING TO USE. I FEEL SORRY FOR YOU GUYS WHO ARE STUCK IN MICROSOFT LAND. SO SAD............

#90. By jmhemadri. Posted on 12/18/2007 11:38:02 AM
yes you are right vb.net is easy
1. vb.net is not case sensitive, where as in C#, we must follow case

#91. By Anonymous. Posted on 12/19/2007 7:37:55 AM
What a moronic article.

#92. By REV-MERIX. Posted on 12/21/2007 5:00:36 PM
OGKW! of syntax generation...

#93. By Jerry. Posted on 12/27/2007 12:17:01 PM
I agree and disagree, I like C# because it keeps close syntax with Java, C and C++ which are other languages I use.

#94. By Ruby. Posted on 12/31/2007 12:28:27 PM
Microsoft and innovation are opposite words. Being rich does not mean being original. Inspite of all the marketing hype from microsoft it won't be able to compete with open source. The truth is that more than 50% of market uses open source technologies. Not just cause they r free but cause they r more reliable, provide more support and r extendable. All of the technologies from microsoft lack these features. So MS guys! its time now to open ur eyes and see the truth as it is (STOP WEARING MICROSOFT GLASSES!!!).

#95. By veronica. Posted on 1/5/2008 12:52:44 PM
u have nicely explained the differences between vb.net,c#.net.
i am intrested to do projects in .net,can u assist how to start,
and we r getting good solutions by going through this articles

#96. By Lord Mashadow. Posted on 1/28/2008 5:32:35 AM
1-You are just kidding me, its as simple as vb-side
"this.WindowState = oIni.GetValue("FormState");

2-Get your facts right, when you type "=" sign like you do in vb, the enum type automaticly shows itself in the intellisense box, then you press dot button and choose the enum

For the fact that you totaly sucked in first two statements, I didnt read the rest of the makeup, cuz I am sure they are all wrong

if you have any response, please dont hesitate to email me

#97. By Anonymous. Posted on 1/28/2008 10:04:13 PM
So confusing

#98. By juan ferrante. Posted on 2/19/2008 4:53:45 PM
I grew up with vb, now i code only in c# and i would never go back if not forced to do so. I was asked to convert a dll from c# to vb and i realized how limited is vb. I think doing the conversion the other way around is easier, so get your own conclusions. addressof or iif are not part of a serious language and should have been left far behind where they belong vb6...
actually iif is a shame for any decent language, a construct that just doesn't work at all, and alone an enough reason to switch over to c#

#99. By Chuck. Posted on 2/26/2008 10:00:43 PM
#10 - C# is case sensitive. This has got to be the most useless feature.

#100. By mike. Posted on 2/28/2008 12:03:26 AM
you are on crack. C# is much easier to code.
Intellisense has to be better in VB, because you need it more (Do I really need intellisense for a bracket?)

That example you gave for exception handling is almost scary. if you are throwing the exception more than once, something is wrong.

You CAN do optional parameters (with param) in C#, but they should be avoided at all costs, it's incohesive code. (Never liked it in C++, it was confusing)

Although I've been guilty of using switch statements for state machines, it's poor design.

Casting is rarely necessary any more with templates.

With..End is hard to read.


Here is some more:

The return character as a separator between commands is stupid

The lack of parenthesis, brackets and colons makes it more unreadable

Although the .net framework has full readable library names, VB still has crappy unreadable keywords like sub and dim.

vb was never meant to be object-oriented, it was a structured language that was patched to become o-o compliant to allow VB programmers to use the .NET framework.

#101. By Jerome Labbe. Posted on 3/4/2008 4:49:13 PM
Yeah man, I totally agree with you, I also noticed that sometimes for no reason the Go to definition just does not work even if the declaration is in the same function!!!!!!! I really think that some people that prefers C# to vb do because they think they are smarter because they are using {} and ; irritating synthaxe! C# is totally unproductive! I know that it is easyer to make bad coding using VB but when you are a smart developper, you know what not to do! I do not hate the language itself but the editor, In vb if you hit enter after an if clause, it will auto complete with Then and End If, but in C# you always have to type the fucking {}, and do not talk to me about code snipets, they are just fast as hiting enter. I'm using .net since the very beginning and I have been using both languages and I can tell that using vb is way more productive.

#102. By Kendall Morley. Posted on 3/5/2008 2:45:57 AM
If you want to comapre vb.net and c# the language, you should compare the langauge features. Features of the IDE are not part of the language. If you want to compare IDE's then compare IDEs.

Intellisense is just not relevant to a discussion about language features. Its like saying I do all my vb.net coding in notepad and all my c# coding in VS2008, which is much nicer than notepad, therefore c# is a better language.

#103. By Anonymous. Posted on 3/12/2008 5:53:49 AM
you can have #Region inside the function in c# but not in VB.NET
Matching the if else conditional statements is much easier in C# caz u can select the opening braces and know the closing one.
Regarding With....EndWith there is alternative in c# just it does not need With....EndWith
for example:
MyClassName
.ThisProperty = "sss"
.ThatProperty = "sss"
.ID = 4
.Name = "Frank"

#104. By lil programmer. Posted on 3/15/2008 2:55:36 AM
How about
10. Vb.net is easier to learn with its lesser scripts !

#105. By Martin. Posted on 3/15/2008 9:18:37 AM
This really is quite funny...

I'm working with Dotnet 2. My employer requires me to work with VB2005, my personal preference is for C# - both because I tend to "think in C", and because of the early adoption of new ideas, which for some reason always seem to come out in C# first. Why they can't release stuff at the same time in both languages is anyone's guess...

The reason I have to use VB a work is because historically we were a VB6 company, and obviously VB2005 is therefore a lot closer to what my colleagues know. For us, that fact alone is a huge point in favour of VB. There are also more people around prepared to take on VB - for much the same reasons...

For personal projects though, and certainly professional projects *If I had a choice*, I think I would prefer C#. A lot of the stuff I've been doing of late has been messing around with the various collection types in the framework, and predicates are a hell of a lot easier on the eye if you have Anonymous Methods at your disposal...

So far though, I've not come across a task that can be done in one of the languages and not the other...

As for the future, anyone who likes DotNet should give Java a look as well, and look at Python and Ruby in terms of seeing where DotNet will be moving toward... They already have a "Dynamic Language Runtime" planned... (And then there's the Iron... stuff - though I can't see IronPython / IronRuby doing much - I think you'll have to wait until c# / vb moves down the dynamic path before much happens there...)

#106. By lil programmer. Posted on 3/15/2008 9:30:27 AM
How about
10. Vb.net is easier to learn with its lesser scripts !

#107. By daniel. Posted on 3/15/2008 3:13:51 PM
In 2. C# Does automatically bring up intellisense for enum types. So HA! You're wrong :) :P
In 3. You can get around this with Function overloads.
In 4. Who really needs this "With" crap?

The other bullets are negligible and become obselete from experience and faster and faster coding with C#.

#108. By Pat Magee. Posted on 3/30/2008 12:45:05 PM
The only valid one you have is the intellisense, but that is is out of date. DotNet 2.0 fixes it.

The worst scenario is Select Case statements in VB.NET - you have to use a primitive type. That is just lame, and on it's own is a good reason to switch to C#

Your main point seems to be "VB.NET is more productive for me, cos I'm a bit of a newbie".

#109. By Belkin. Posted on 4/3/2008 11:40:45 AM
?????. ???? ??????. ????? ?????.

#110. By Kosta. Posted on 4/10/2008 1:57:46 PM
you know people,,, these types of articles really do help us programmers learn more {
about the differences between our languages we use {
this post app woz probably built using either c# or vb but it still communitcates and does the job {
look now how our mobile phones are programmed wot language do they use?
every company seems to use a different type of style of mobile phone programing with their phone book, txt message app,, blah blah, wot language do our mobile use..

kosta

#111. By Kosta. Posted on 4/11/2008 1:53:01 PM
you know people,,, these types of articles really do help us programmers learn more {
about the differences between our languages we use {
this post app woz probably built using either c# or vb but it still communitcates and does the job {
look now how our mobile phones are programmed wot language do they use?
every company seems to use a different type of style of mobile phone programing with their phone book, txt message app,, blah blah, wot language do our mobile use..

kosta

#112. By Mr. Smith. Posted on 4/13/2008 9:15:27 PM
A little joke ...
Someone is replay that C# sounds much powerful instead of "BASIC".
If vb.net is consider as toy language, because of name,
maybe we can call C# a "baby C" (in comparison with C++ ..)
In that way we can solve that part of problem :)

#113. By Mr. Smith. Posted on 4/13/2008 9:20:17 PM
A little joke ...
Someone is replay that C# sounds much powerful instead of "BASIC".
If vb.net is consider as toy language, because of name,
maybe we can call C# a "baby C" (in comparison with C++ ..)
In that way we can solve that part of problem :)

#114. By A.F.. Posted on 4/14/2008 8:37:12 AM
This is BullShit man, all the reasons you specified are Advanteges of C# man, this can only be seen by a proffesional programmer!


Take Care...


A.F.

#115. By A.F.. Posted on 4/14/2008 8:51:46 AM
How about 10:

VB.NET is all preserved words...
Your code looks blue and hard to read. I'm looking on a code in VB.NET and all I see is blue preserved words (about 85% of the code) while C# uses signs like { } ? etc'.

How about the following:

Nullable Types C# and VB.NET

Dim i As Nullable(Of Integer) = 100
i = New Nullable(Of Integer)(i.Value + 20)

- or -

int? i = 100;
i = i + 20;

Gee, which would you rather type?

#116. By mcsdguy. Posted on 4/15/2008 10:52:05 PM
IMHO writing code in a particular language is a personal choice. One should not draw comparison between VB.net & C# as they both use the same .NET framework. Period.

#117. By TheCPUWizard. Posted on 4/22/2008 1:39:11 PM
Alas, most of your items are not really valid.

1) Only works without "Option Strict". NO professional developer would ever allow this.
2) As soon at you hit the "=" Intellisense WILL show the EnumType, so it really boilds down to 1 keystroke.
3) Proven to increase coding errors
4) Typically leads to anomolous behaviour.
5) UnTrue "Event += MehodName" works just fine.
6) Just try to to use that syntax while interleaving the initialization of multiple objects.
7) However it is im possible to even detect if an event handler is registered...VERY important functionallity.
8) Yes, exception filters are a great tool and using them from C# is nearly impossible.

#118. By Shane. Posted on 5/8/2008 3:49:12 PM
To all people saying "case-sensitive": Learn some coding standards. Seriously. If you can't create your variables, controls, and methods using common coding standards, then you need to find a new job. It's people like you that create methods called "get", then GetUser and then Get_User.

#119. By Mohammed A. Fadil. Posted on 5/26/2008 6:39:33 AM
AHHHHHHH.... Shnick shnack :)
VB just for programmers under 14 years old ;)

#120. By Manjeev Singh. Posted on 5/29/2008 2:40:56 PM
Bull sit Your VB.Net it is the one of the painful language. The VB.Net is developed for the duffer programmer they don't have the idea about OOP's concept.

#121. By VbDotSharp;-). Posted on 6/5/2008 2:36:20 PM
10. Application events: In VB, with one checkbox set in the project properties you can catch events globally that you've forgotton to catch locally.
(In "My Project" -> Application tab, first enable the application framework, then click on "View Application Events" button)
This allows to write bullet-proof error handling. In C#, they've forgotten this useful feature completely.
11. The using-statement exists in both languages, but only in VB you can instantiate variables of different data types. In C#, you have to nest
it (e.g. using(/*declaration of SQL object goes here*/) { using(/*declaration of file stream goes here*/) { /* ... body ... */ }})
which results in uglier code. In VB this is just one single using ... end using block.

#122. By Alexander Miller. Posted on 6/13/2008 5:18:00 PM
This is pretty much BS.

This whole thing is based on a biased opinion so take it with a grain of salt. C#.NET is 3 times as fast as VB.NET.

VB6 is a relic and shouldn't be used because its on the verge of being totally obsolete.

VB in and of itself is barley a respected language.

The whole argument of 'extra typing' is based on your skill in the IDE, not the language.

#123. By Martin. Posted on 6/13/2008 6:12:33 PM
And that's just ill informed...

VB.Net and c# resolve to just about the same IL anyway, so there's no real speed advantage when it comes to code execution. You're comments about the IDE are perfectly valid though...

It comes down to what people feel happy with - both languages have almost identical features, though it could be said that new stuff historically seems to make it into C# first...

My personal preference is for C#, but I have to use VB for work, and it's not all that bad... I just get a little annoyed with all the "VB is for idiots" style comments - it isn't. It's for people that want to think in VB. People who want to think in C# can - and I'm one of em!

Martin

#124. By Anonymous. Posted on 6/14/2008 1:02:47 AM
Regarding speed... With 1.0, there was onen condition where VB was 4500 (four thousand five hundred) time faster than C#. Special credit for the first to correctly name it.

From a realistic point of view, there is NO Performance variation between the two. There is NO capabilities differences between the to.

It is a matter of the "Syntactic Sugar" to make your life more convenientand that is 100% in the eye of the beholder.

What I find ironic is that EVERY professional shop I have been involved with (again I have been a developer for 35 years) requires that "Option Explicit" and "Option Strict" are used with VB.Net.

The vast majority of the "advantages" quoted in this discussion all vanish in an instant.

#125. By Mohammed A. Fadil. Posted on 6/14/2008 8:09:04 AM
Give me a break man

#126. By Anonymous. Posted on 6/17/2008 7:10:54 PM
Uhm, yeah. You're an idiot.

Seriously, when new programmers find this they're going to likely take your shit as gosphel and then when they're taught implicit runtime type casting is not such a good idea they're going to be quite confused. This kind of fucking garbage needs to be burned. I work with VB.NET at my job, and it's no picnic. No anonymous delegates, no synactic sugar like using() {}, constant crashing (the IDE is incredibly unstable in VB.NET). All you've done is basically point out that "Hey, with VB.NET, you type less!!" which is very untrue. VB, no, BASIC, was designed to be a verbose language and you end up typing more. Proof?
C#:
if (myBool)
return true;

VB.NET
if (myBool) then
return true
end if

Or how about:
C#:
int MyProperty
{
get
{
return 1;
}
}

VB.NET:
readonly property MyProperty
get
return 1
end get
end property

Thankfully the IDE saves you some time by filling out a lot of that for you.

My favorite though is this:
C#:
unsafe void SetFastPixel(IntPtr bitmapData, int length, byte color)
{
byte *ptr = (byte *)IntPtr.ToPointer();

while (length > 0)
{
*ptr = color;
ptr++;
length--;
}
}

VB.NET:
Uh.. yeah, don't even bother.

Yes, I know, pointers are mystical evil things. But when it comes to speed they're unparalleled (if you know to use them properly, but don't let your lack of knowledge be an excuse for blasting something).

VB.NET is great. It works well for those who like workng with BASIC. But by no means is it "better" than anything else.

Again, I can't state this enough. You're an idiot. Please die.

#127. By Y. Posted on 6/27/2008 5:01:38 PM
Every language has its place. Most programmers who do it for a living are programming in a given language because the people who are paying them tell them to do so. If your company wants VB, you better get good at it and make it work in whatever capacity it needs to.
Programmers time is much more expensive than cpu cycles, these days, and that may be why they are going VB. Just like most of you, I've done different languages, and I'd have to say, if they want a support app built in 1 week, vb can't be beat. Games? no. Critical Systems? probably not.

The thing to remember is that your way (whatever it is) is NOT the only way, and everyone who doesn't subscribe to your idea is NOT an idiot who deserves to die.
If you are eliminating a language or tool from your resume, then, in my opinion, that makes you the fool.

#128. By Anonymous. Posted on 6/27/2008 11:54:37 PM
Actually I have eliminated aleast a dozen languages from my resume (when was the last time you saw a listing for an Algol programmer??)

Seriously, The point about developing what a client requires is (of course) true. And IF they have in-house staff already familiar with VB.NET (NOT VB6), then I readily agree with using that language.

In general I promote C# for a number of reasons.

As a side not, when training people in .NET (solething I do ALOT of), I typically pick VB.NET for C++ programmers and C# for VB6.0 programmers. The syntactical disconnect really does help them to think in new ways (required for managed applications), hereas having a similar syntax often causes them to bring in inappropriate ideas.

#129. By Anonymous. Posted on 6/27/2008 11:57:15 PM
Actually I have eliminated aleast a dozen languages from my resume (when was the last time you saw a listing for an Algol programmer??)

Seriously, The point about developing what a client requires is (of course) true. And IF they have in-house staff already familiar with VB.NET (NOT VB6), then I readily agree with using that language.

In general I promote C# for a number of reasons.

As a side not, when training people in .NET (solething I do ALOT of), I typically pick VB.NET for C++ programmers and C# for VB6.0 programmers. The syntactical disconnect really does help them to think in new ways (required for managed applications), hereas having a similar syntax often causes them to bring in inappropriate ideas.

#130. By Anonymous. Posted on 6/28/2008 3:18:52 PM
Number9:

C# doesn't let you have cases which fall into each other.

#131. By Anonymous. Posted on 6/28/2008 3:22:15 PM
Number9:

C# doesn't let you have cases which fall into each other.

#132. By dan. Posted on 6/28/2008 3:26:35 PM
Number9:

C# doesn't let you have cases which fall into each other.

#133. By daniel. Posted on 6/28/2008 3:37:37 PM
response to:
#40. By Anonymous. Posted on 10/6/2006 4:03:35 AM
Hey, #10 the best part of VB.NET vs. C#. Background compiler.

C# has this now.


Btw: very few arguments on here are still valid as to why vb is supposedly better than C#. C# is winning, it's better.. and more professional, get over it.

#134. By Tomas. Posted on 7/8/2008 11:55:42 AM
Yes, I like VB.NET much more than C#, but VB.NET does not have "yield return", which is very useful and handy. C# does have it. I'll be very happy if the VB.NET team add it into next release. Also property declarations are shorter in C# and I hate that VB.NET is not case sensitive because in property declarations the local variable cannot have the same name and must take _ at its beginning. Why they cannot make a language somewhere between C# and VB.NET? Both languages are good and have some perfect features.

#135. By Tomas. Posted on 7/8/2008 11:56:00 AM
Yes, I like VB.NET much more than C#, but VB.NET does not have "yield return", which is very useful and handy. C# does have it. I'll be very happy if the VB.NET team add it into next release. Also property declarations are shorter in C# and I hate that VB.NET is not case sensitive because in property declarations the local variable cannot have the same name and must take _ at its beginning. Why they cannot make a language somewhere between C# and VB.NET? Both languages are good and have some perfect features.

#136. By T. Phaneuf. Posted on 7/20/2008 10:31:49 PM
Who programs with Explicit=Off in VB.net anyway? Not anyone who knows their stuff. The bulk of the issues that I see in here by C# people assume that someone would work professionally in VB.net without strong typing.

With Explicit=On, VB.net is a strongly typed language with no implicit casting, and the differences between VB.Net are trivial, and a matter of taste.

Other notes:

1. With ... End With is far from bad programming practice. In fact, it is a preferred programming practice when repeatedly accessing the contents of an object. Reference Microsoft Press "Practical Guidelines and Best Practices..." p. 128.

2. When using VB.Net with Set Explicit On, VB.Net is EXACTLY as picky as C# about types. I personally don't know anyone who programs in VB.net professionally without Explicit = On.

3. The better Intellisense in VB.net does result in less actual typing than with C#. This is counter-intuitive because there often is wordier code as the result in VB.net. But the amount of typing by the programmer is less --as is the amount of backspacing and correcting and head-scratching.

4. VB.Net did inherit some stupid words from VB. Microsoft continued by adding some additional dumb words, too. "Dim" continues to annoy me.

5. To the guy who is using a pointer in an unsafe code block: That is your example of good code? I would send you back to your desk to find a way to fix it to use managed code, while me and the rest of the team went to lunch. If you absolutely have to use pointers and unmanaged code (which is rare if ever) you can use IntPtr, Marshal and GCHandle in the .net framework.

6. C# does sound more impressive than Visual "Basic". But once you figure out how easy they both are, who cares?

6. C# and VB.Net are like paint on a car. The car is the .NET framework. Blue is better -- No! Red is better... The .NET language that is better, is a matter of taste, and the language that you prefer to work with. For my purposes and preferences, VB.net is better and I constantly am working with large commercial grade projects. C# is ok, but I have found that development times seem to take longer. I also find that I can ask for specific stuff and get it faster when I have people working in VB.net vs C#.

7. Have been programming in a variety of languages for 20 years, including Delphi (my favorite), C++, C#, VB.net (but never VB), etc. VB.net is bearable. Not perfect -- but even Delphi isn't perfect. The key to both C# and VB.net is the .NET framework. To say that VB.net is for hacks and newbies pretty much exposes the speaker as not terribly wise or informed.

That's it. My $0.02

#137. By T. Phaneuf. Posted on 7/20/2008 10:50:53 PM
Ok. Just saw this comment:

"As a programmer C# encourages better OO design and programming"

What the hell? C# doesn't encourage squat more than VB.net. It is the discipline of the programmer/developer. There is real talent in both camps. And there is also bullshit programmers who give the guys who have a clue about theory, standards, and practices a bad name.

I have to restate this. You can be as non-oop and as bad a programmer (sometimes even worse) in C# as a VB.net programmer. Not only is this possible -- it is disappointingly common.

#138. By JohnJoe. Posted on 7/21/2008 11:48:10 AM
Can we not just agree that they're both awful? Really what your asking is which is better; microsoft made a retarted language basic and built up and bastardised itself, C sharp is MS trying to mess with the compiler market and make it harder to make cross platform software. So in my opinion, VB.net only messes with VB so its a lesser of two evils.

#139. By TheCPUWizard. Posted on 7/22/2008 2:17:50 PM
JohnJoe,

You are just showing you ignorance... C# is NOT a "Microsoft Language". It is an open language that is controled by ECMA specification.

#140. By luke. Posted on 7/30/2008 12:46:06 PM
I think I'm understanding why it's practically useless to code in c#. If you want to code in c# you may as well code in java. It's still important to know both because heaps of examples are in c#

#141. By Shane. Posted on 7/30/2008 2:16:26 PM
Luke, that was a horrible comment. It's not about the language; it's about the framework. So C# resembles Java in certain areas? Big deal. All new languages take ideas from other languages.

#142. By Dave. Posted on 8/4/2008 5:30:32 AM
C# & vb.net both have pros & cons. However my company is migrating from VB6 to C#.
The main reason is because Micro$oft gives more focus on C#.

#143. By Dave. Posted on 8/4/2008 5:31:25 AM
C# & vb.net both have pros & cons. However my company is migrating from VB6 to C#.
The main reason is because Micro$oft gives more focus on C#.

#144. By Luke. Posted on 8/14/2008 10:02:24 AM
Apologies, I guess I just do not know enough about the advantages of .NET over the java..

#145. By Luke. Posted on 8/14/2008 10:03:46 AM
Apologies, I guess I just do not know enough about the advantages of .NET over the java..

#146. By Luke. Posted on 8/14/2008 10:22:40 AM
Apologies, I guess I just do not know enough about the advantages of .NET over the java..

#147. By TheCPUWizard. Posted on 8/14/2008 12:14:47 PM
"Advantage" is a subjective term. "Difference" is objective. You have to make the decision based on your circumstances.

That being said, remember that .NET is a PLATFORM, Java is a language.

You can write .NET code in C#, VB.NET, C++/CLI, J# (aka JAva.NET), COBOL.Net, Fortran.Net, F#, and about 40 more programming languages.

#148. By GeorgeLaya. Posted on 8/31/2008 5:03:12 PM
out of all the comments, i like the #127 the most. It is very logical. :)

#149. By Thomas Ingram. Posted on 9/2/2008 3:38:40 PM
You made some valid points (esp. four & eight), but I don't see how you can blame C# for not having proper IntelliSense. This is not so much a shortcoming of the language as much as it is a lack of support from Microsoft. Also point nine is just slightly more verbose, but the end result is the same thanks to fall-through. Furthermore point six is somewhat stacked in favor of VB.NET, as C# would have been fewer characters had you used a shorter variable name. So really it seems to me that you don't have ten reasons, and your article title is therefore misleading.

#150. By Anonymous. Posted on 9/16/2008 1:48:44 AM
"Intellisense" falls into two categories. Properly highlighting the source, and providing auto completion. I find VB to be on par with
C# in the former. C# lacks in the latter. One reason is that there are so many completion items iit is simplly impractical (unless you wany a list with 500 items....

#151. By Anonymous. Posted on 9/16/2008 1:49:57 AM
"Intellisense" falls into two categories. Properly highlighting the source, and providing auto completion. I find VB to be on par with
C# in the former. C# lacks in the latter. One reason is that there are so many completion items iit is simplly impractical (unless you wany a list with 500 items....

ps I turn off auto complete in BOTH environments....

#152. By Anonymous. Posted on 9/16/2008 1:50:05 AM
"Intellisense" falls into two categories. Properly highlighting the source, and providing auto completion. I find VB to be on par with
C# in the former. C# lacks in the latter. One reason is that there are so many completion items iit is simplly impractical (unless you wany a list with 500 items....

ps I turn off auto complete in BOTH environments....

#153. By Sad VBCoder. Posted on 9/16/2008 5:57:23 AM
Since Microsoft introduced VB.NET, VB is no longer a RAD tool. It lost the merit of easy to use of VB6.
.NET is a heavy framework, it wasn't built with simplicity in mind. In order for VB to win over C#, Microsoft should create VB7 Classic instead of mutating it to a framework centric language. It was a big mistake.

#154. By Sad VBCoder. Posted on 9/16/2008 5:58:53 AM
Since Microsoft introduced VB.NET, VB is no longer a RAD tool. It lost the merit of easy to use of VB6.
.NET is a heavy framework, it wasn't built with simplicity in mind. In order for VB to win over C#, Microsoft should created VB7 Classic instead of mutating it to a framework centric language. It was a big mistake.

#155. By teleman. Posted on 9/24/2008 10:52:04 PM
re: #137 by T. Phaneuf

Excellent point.

I've used both languages since their release and VB5,6 prior to that. It is true that C# produces safer, less error-prone, more performant code than VB.NET typically does. C# doesn't allow many bad practices such as implicit casting, etc. And, nowadays, it provides things like anonymous delegates, lambdas and other contructs which are important and beneficial if you grasp them. However, the idea that VB developers are stupid and C# developers are "smart", or that no "veteran" developer would use VB is horse shit. And, any developer making those statements is simply consumed with his/her own self-proclaimed genius. In fact, a true veteran developer understands the differences between the two languages and knows when to employ one or the other based on the requirements of the project, resources available, etc. VB.NET is not a "beginner's language", though many beginner's do choose it. And, C# is not a "veteran's language", though many veteran's do choose it.

But, my main point here is to dispell this completely incorrect, arrogant statement: "C# promotes OO design moreso than VB" or "C# developers "get" OO moreso than VB developers do"... more horse shit. As previous posts have stated, OO is a design decision and is completely separate from the language choice. VB is perfectly capable of good OO design and has been since introducing inheritance, etc. (.NET). I dare say that few developers I've worked with do "get" OO - including so-called "veteran" C# developers. This is evident every time I find one of these:

public class ValidateSessionRequestContent

written by a die-hard, VB-hating, C# developer who knows all kinds of shit about making an application absolutely totally loosely-coupled, full of design patterns, completely extensible, with all injectable dependencies, yada, yada, yada... but completely misses the whole point of OO and writes that hideous thing. How about:

SessionRequest.Content.Validate()

Objects should model the business domain. But, returning to my point... many applications simply don't require the previously mentioned patterns and practices. And, yes, I've worked on many large "enterprise" apps (that's what I do for a living) - many of those don't either. The ones that do are often apps that are being coded by large teams concurrently, and in those cases, C# and certain design patterns are probably the way to go since your objective will be to make the code highly maintainable by many different people. But, then, you have to realize that you've taken on the need for experienced architects who can enforce the patterns and teach other developers how to take advantage of them - otherwise, what have you gained?

On the performance argument, think about this - the last time you had a performance problem in an application, what was the problem? Was it too many implicit casts slowing your application down? With modern quad-core processors and other modern hardware, probably not - more than likely it was a network roundtrip or a database locking issue that you were facing. These are the things that usually cause a noticable latency in an application. Or, it was a threading issue, which hasn't even been discussed here, so we won't even get into it.

#156. By TheCPUWizard. Posted on 9/25/2008 4:09:09 AM
T. Phaneuf, I agree with all of your post EXCEPT for the part I quote at the end of this post. I have been a professional developer of enterprise applications for over 30 year, have run my own consulting firm for 24 years, and used every version of VB, C#, and C++ that has been produced by Microsoft (As well ah many other vendors).....

It has been my professional experience that while there may be certain programs which do not "require" proper modern design techniques, there is never for ignoring them. It would be analogous to a person deciding they did not "require" their kidney's because they could live on dialysis. Technically true (at least for a period of time), yet no doctor would remove BOTH kidney's from a healthy person for any reason.

The current averge lifecycle of an enterprise application is between 6 and 10 years [as reported by Gartner Group June 2008. At investment at the architectural phase will pay for itself many times over during this period.

In short, poor choices at the begining of a project (typeically "we dont need to .....") will almost surely introduce significantly larger total cost to the total life of the project.

'Nuf Said.


QUOTE: "But, returning to my point... many applications simply don't require the previously mentioned patterns and practices. And, yes, I've worked on many large "enterprise" apps (that's what I do for a living) - many of those don't either. The ones that do are often apps that are being coded by large teams concurrently, and in those cases, C# and certain design patterns are probably the way to go since your objective will be to make the code highly maintainable by many different people. But, then, you have to realize that you've taken on the need for experienced architects who can enforce the patterns and teach other developers how to take advantage of them - otherwise, what have you gained?" - T. Phaneuf

#157. By Anonymous. Posted on 10/1/2008 9:34:53 PM
These are incredibly stupid reasons

1) Your code is awful. Why are you using ints instead of saying FormWindowState eState = FormWindowState.Normal (or whatever 1 is)?
2) Intellisense has NOTHING to do with the language itself. That's like saying French is better than Spanish because your particular
French-to-English dictionary is better than your particular Spanish-to-English one.
3) Overloads in C# accomplish this
4) This just makes for confusing code
5) Adding the event handlers with "+=" syntax is much clearer. It shows what the code is actually doing: it's ADDING a listener, not making
your code "act" like one, which is what "handles" sounds like
6) The number of bytes is how you evaluate a language? That's absolutely ridiculous. In fact, your C# code wouldn't even compile because
you forgot semicolons (and yes these are much, MUCH better than newline-based coding because giving the programmer control
over his/her own newlines and tabbing allows them to make their code always legible despite having long lines or unusual situations.
7) Are delegates that confusing to you? They're not to me
8) Are you serious? You don't need to say "When" when you can just use an If statement in the Catch block
9) You can put multiple cases or their break statements on the same line in C# to make it "look nice", if that's really what's important to you.
Remember, C# doesn't dictate how your code must be spaced, unlike VB
10) I'm sure I could think of 100 reasons to use C#, whereas you couldn't even think of a tenth illegitimate reason for preferring VB

#158. By C#er. Posted on 10/3/2008 10:08:47 AM
#9 c#

switch (a)
{
case 1|2|3:
(...) // Do Action
break;
case 4:
(...) // Do Action
break;
}

#159. By PM. Posted on 10/21/2008 4:50:23 PM
4) & 9) is real "problem"

#160. By TheCPUWizard. Posted on 10/21/2008 5:06:04 PM
I fail to see how "4&9 are real problems" apply.

#4) Usage of "with" statement: First of all, nearly every programming standard recommends avoiding this construct. If yopu have a significant number (typically more than 3) consecutive operations on a given instance, there is the distinct possibility that your object model is flawed.

#9) Multiple values for a given Switch Statement Clause: In general a switch statement is an indication that "structured" programming techniques rather than "object oriented" techniques are being used. This is especially true if two different things (ie values) are really the same thing (ie case clause).

Since neither of these constructs should be common in a well thought out design, I fail to see how they have any meaningful impact.

#161. By Nevermind. Posted on 10/23/2008 9:10:40 PM
As far as I know the language itself doesn't make any programmer any better than he/she really is. You can make great software in C# as well as in VB.Net. On the other hand - you can make shitty software in pretty much any of those languages. It's not the language you know that makes you a better programmer, it's how you're using it. BTW, all of your code gets interpreted anyway, so claiming that C# is faster and therefore better than VB.Net is quite a lame argument. Coding in .Net has much more to do with knowing and using the .Net Framework properly, than with what particular language you're using.

#162. By TheCPUWizard. Posted on 10/24/2008 2:46:04 AM
"Nevermind"....why do you persist in taking a good post (you can write good/bad code in nearly any language) and turning it into a blatant LIE. .Net code is NEVER interpreted. The only thing that ever executes is 100% pure native code for the actual processor. Yes the COMPILATION is broken into two phases, but this is totally immaterial to any discussion.

#163. By Caddbone. Posted on 11/17/2008 7:58:23 PM
You are a complete idiot.

#164. By Anonymous. Posted on 11/22/2008 6:09:45 AM
I don't know about you, but I remember { and } easier then if then end if, while,end while. I don't even know how you'd do a for loop.

Reason 9 was the stupidest. The whole point of the break; in C# is so you can choose if it DOES fall through or not. EX :

Case 9:
Run extra code then execute case 10
case 10
Do not run the extra code, but still execute case 10

Microsoft doesn't support C# more because Visual Basic is better. If you disagree with this, take a look at the XNA framework.

#165. By Anonymous. Posted on 11/26/2008 5:54:56 AM
Your uninformed opinion has already been corrected several times; however I will at least oblige myself and poke fun at the incompetent author.
Dijkstra was certainly correct when he said "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

#166. By paulo gomes. Posted on 12/30/2008 4:38:05 PM
Great article.
In the current project I'm Visual Studio 2008 cannot be used, only VS 2005.The VB Intellisense in Visual Studio 2005 does not show the variables or the controls started with the letter you just typed, but in C# with VS 2005 the Intellisense does.

Quick question: Is there any workaround in the VS 2005 IDE, any download from Microsoft or anything else that can make it happens? Remembering the names of controls, variables, datasets, etc, is almost impossible and it is time consuming go back and forth between the tabs.

Thanks for your help.

Paulo

#167. By paulo gomes. Posted on 12/30/2008 4:45:01 PM
Great article.
In the current project I'm Visual Studio 2008 cannot be used, only VS 2005.The VB Intellisense in Visual Studio 2005 does not show the variables or the controls started with the letter you just typed, but in C# with VS 2005 the Intellisense does.

Quick question: Is there any workaround in the VS 2005 IDE, any download from Microsoft or anything else that can make it happens? Remembering the names of controls, variables, datasets, etc, is almost impossible and it is time consuming go back and forth between the tabs.

Thanks for your help.

Paulo

#168. By Michael. Posted on 1/6/2009 8:21:52 AM
May #10 should be that VB programmers don't walk around the planet acting like they part-created it ?

#169. By Vishal S.Surana. Posted on 1/9/2009 10:20:57 AM
Very nice article.Thank you

#170. By MD. Posted on 1/12/2009 8:14:56 AM
Just read comment #10.. that explains it very well.

#171. By MD. Posted on 1/12/2009 8:24:39 AM
Just read comment #10.. that explains it very well.

#172. By Luis. Posted on 2/19/2009 2:27:58 AM
Live VB.NET

#173. By Ray Casper. Posted on 3/3/2009 5:52:19 PM
how about the little } to end a function these things
are so hard to find. or the fact that C# is case sensitive this will drive you mad.

#174. By John. Posted on 3/9/2009 3:39:09 PM
The biggest difference between C# and Vb.Net is whether you value your code going forward easily or whether you value productivity enhancements now. I value productivity enhancements now. There are quiet a few commands built into VB that make your life that much easier. The C# argument is, why have that overhead if I don't need them? It's a valid argument but it comes down to what you value. In this day and age with computing power as it is, I value how fast I can get stuff done with Vb. C# and Vb are both great languages, I just prefer VB for speed.

#175. By John. Posted on 3/9/2009 3:42:22 PM
The biggest difference between C# and Vb.Net is whether you value your code going forward easily or whether you value productivity enhancements now. I value productivity enhancements now. There are quiet a few commands built into VB that make your life that much easier. The C# argument is, why have that overhead if I don't need them? It's a valid argument but it comes down to what you value. In this day and age with computing power as it is, I value how fast I can get stuff done with Vb. C# and Vb are both great languages, I just prefer VB for speed.

#176. By jerome labbé. Posted on 3/9/2009 4:01:20 PM
At the end, whatever the language you choose, you will be able to reach your goals as soon as you get good developpers. Bad developpers do bad coding no matter the language. It is just a good thing that we have the choice!

personnally I prefer VB because it is the language that all the companies I worked for used.

PS: The client just don'T give a fuck about the language used!!!!!!!!!!!!!!!!

#177. By Tfosorcim. Posted on 4/22/2009 9:02:31 AM
I use both VB.NET & C#.
VB.NET is damn slowwww when my program has growth to more than 40 projects & 300 classes.
My another C# program with 400 classes still has acceptable performance.
Maybe Microsoft think that every VB.NET programmer use quad-core processor with DDR3 RAM.

Bottom line - don't use VB.NET for big project.

#178. By TheCPUWizard. Posted on 4/22/2009 1:00:11 PM
Tfosorcim,

There should be absolutely NO (measurable/meaningful) performance difference between a VB.NET application and a C# application. They both compile to MSIL (and then JIT to native code). If you are seeing a performance difference, then YOU are doing something inappropriate. I have written multiple applications in each (with application sizes of 1,000,000++ lines of code).

#179. By Tfosorcim. Posted on 4/23/2009 5:22:38 AM
TheCPUWizard,

What I meant slow is the Visual Studio IDE performance (especially if most projects have many references).
I didn't mean the MSIL execution speed.

#180. By Anonymous. Posted on 4/23/2009 6:55:57 PM
Do you know what all c# developers have in common? They all think they are god! Do your thing and leave me alone with what you think is good or not. "optional parameters are bad bad bad", how bad????? I have used them before and guess what, nobody dies and the systems I used them in still works!!

I do not hate C#, I juste hate people who think they are smarter because they use C#

#181. By TheCPUWizard. Posted on 4/23/2009 7:48:56 PM
1) I have not experienced the IDE slowing down even with projects containg 1000+ source files. If you could contact me (google my handle, and my direct e-mail is obvious), I would be willing to enter into an NDA to see this....

2) Regarding optional parameters....They have their pros and cons...but the point is moot since C# [4.0] supports them (along with named parameters)...someone is still basing their comments on OLD information.

#182. By foo. Posted on 4/23/2009 10:31:22 PM
People who use C# ARE smarter...

#183. By Ted Whitton. Posted on 4/29/2009 8:36:02 PM
VB.NET is better. VB.NET programmers are damn sexy. I should know.

#184. By TheCPUWizard. Posted on 4/29/2009 11:12:30 PM
1) People who think (or worse try to convince others) that any one language is better than another, without qualifying the situation is Stupid.

2) Stupid people are NOT sexy (Sorry Ted....)

#185. By Dave. Posted on 4/30/2009 8:23:23 PM
This page is amazing!
Somewhere I read that 80% of VB.NET programmers are not very smart. After having read this page I can say this is true.

The problem about VB.NET is that it has become a mixture of a BASIC language and an object-oriented language.
That doesn't work at all and that doesn't make sense at all:

(1) The BASIC syntax was established and optimized for simple MS-DOS programming, that's 30 years ago!

(2) Now VB.NET is OO in a very very primitive way. No programmer of the world will really understand the concept of OO through VB.NET. This is the most ridiculous thing ever happened within the age of computers!

(3) C# and VB.NET use the same framework and CLR. But they don't use the same compiler. VB.NET's compiler puts terrible stuff
into your build. Just one example: methods that try to call the old VB exception-handlings which don't exist anymore in VB.NET. Another example: the Stack handling is dumbshit. It's not like the way other real OO languages do that. Microsoft concentrated on making VB.NET an OO language instead of correcting the real bad internal issues.
--> Consequences of that things: it makes your application have an instable performance and slowing down a little bit also.

(4) People who really think that VB.NET code is easier to read must be little children. C# code is definately more logically and
easier and faster to read.

(5) C# is faster to write.(intellisense is for people who never learned typing)

(6) Microsoft itself know that VB.NET is not quite good. They just go on developing it because a lot of stupid programmers want it!


See sharper, guys !

Dave

#186. By TheCPUWizard. Posted on 4/30/2009 10:50:31 PM
Dave,

Sorry, but all of your points are seriously flawed. Just to start, BASIC [Beginners All-purpose Symbolic Instruction Code] was developed in 1964. Approximately 45 years ago, and over 15 years before MS-DOS.

#187. By Dave. Posted on 5/1/2009 11:06:23 AM
@TheCPUWizard:

I see, you are a specialist...
But that's not correct. It was developed in 1963. 1964 it was published. (First run of a kind of "final draft" BASIC software: 1964-05-01, at 4 PM)
But I guess most people visiting this page got to know it by MS-DOS coming up.

Greetz,
Dave

#188. By Dave. Posted on 5/1/2009 11:09:15 AM
.....by the way:

HAPPY BIRTHDAY, BASIC !

#189. By Jerome. Posted on 5/5/2009 7:33:41 PM
Dave, I've also read that 99% of c# developpers are smart. Obviously you are in the 1% that are not!

Have fun with your c# thinking you are smart!

#190. By Anonymous. Posted on 5/7/2009 4:17:49 PM
i've been looking around the internet trying to decide what language to start using in .NET. All I see is alot of self-proclaimed smart guys hurling insults at each other about how ignorant the other is. Insulting someone is a pure sign of ignorance.

#191. By Anonymous. Posted on 5/7/2009 4:21:52 PM
i've been looking around the internet trying to decide what language to start using in .NET. All I see is alot of self-proclaimed smart guys hurling insults at each other about how ignorant the other is. Insulting someone is a pure sign of ignorance.

#192. By Martin. Posted on 5/7/2009 5:03:36 PM
Hi Anon...

The truth or the matter is that both languages (and I work with both) are very capable - and the differences are such that you are unlikely to notice them until you start getting into really serious code...

Personally, given the choice, I prefer C# - it's easy to learn, concise, and well supported. Another consideration is that, historically, Microsoft always seem to release new language features to C# first, and make VB.Net developers wait for it...

Which is not to say that VB.Net is a bad language - because it isn't - especially if you've come from somewhere like VB6 - in which case you will find a lot of the syntax familiar... I don't believe Microsoft has any plans to drop VB.Net as some of the C# crowd claim/hope - they'd be mad to remove themselves from such a large development community...

Performance wise, I find the two languages to be roughly equal - which you would expect of course because they each compile down to MSIL...

Good luck...

#193. By Vito. Posted on 5/12/2009 10:35:49 AM
On error resume next

#194. By Martin Milan. Posted on 5/12/2009 11:40:10 AM
On Error Resume Next is, generally speaking, not a good idea.

True, if you want to run down a whole sequence of statements, being sure each is executed and ignoring exceptions, it can be useful - but I'd argue if you're doing that then your design is flawed.

On Error Resume Next is a quirk - not a feature.

You shouldn't be using On Error now for error handling in the first place. Use exceptions - far, far more flexible.

#195. By Tim. Posted on 8/19/2009 8:51:20 PM
Wow,

I code it both VB.NET and C#.NET. The are both great languages. Any person who things that one language is better than the other is fooling themselves. You can accomplish any task in both languages. They both compile down to MSIL so it doesnt matter. As for the casting argument in VB.NET, you have the option to force explicit casting, so that doesnt matter either. Each language is more / less verbose in differnet areas and have the syntactical querks but at the end of the day, the end goal is to write some seriously bullet proof code, that is maintainable, in a language that the developer is proficient in whether it be VB.NET or C#.NET, and fulfills the business need that it was written to do.

Tim

#196. By Tim. Posted on 8/19/2009 8:58:56 PM
Wow,

I code it both VB.NET and C#.NET. The are both great languages. Any person who things that one language is better than the other is fooling themselves. You can accomplish any task in both languages. They both compile down to MSIL so it doesnt matter. As for the casting argument in VB.NET, you have the option to force explicit casting, so that doesnt matter either. Each language is more / less verbose in differnet areas and have the syntactical querks but at the end of the day, the end goal is to write some seriously bullet proof code, that is maintainable, in a language that the developer is proficient in whether it be VB.NET or C#.NET, and fulfills the business need that it was written to do.

Tim

#197. By Tim. Posted on 8/19/2009 9:15:16 PM
Wow,

I code it both VB.NET and C#.NET. The are both great languages. Any person who things that one language is better than the other is fooling themselves. You can accomplish any task in both languages. They both compile down to MSIL so it doesnt matter. As for the casting argument in VB.NET, you have the option to force explicit casting, so that doesnt matter either. Each language is more / less verbose in differnet areas and have the syntactical querks but at the end of the day, the end goal is to write some seriously bullet proof code, that is maintainable, in a language that the developer is proficient in whether it be VB.NET or C#.NET, and fulfills the business need that it was written to do.

Tim

#198. By Greg. Posted on 8/25/2009 8:27:31 PM
UR Dumb!

VB.NET is the goofiest programming language ever created.

You "may" be able to write VB quicker by writing fewer lines of code, but if you ever need to change languages it will take you 10 times longer because the syntax is so much different.

No one programming language can be called "the best ever"...it depends on the scenario, but I can guarantee that VB.NET would never be called the best language under ANY circumstances!

#199. By Martin Milan. Posted on 8/25/2009 8:36:15 PM
The two languages are quite similar, and the only real differences I would suggest are that VB is easier for the newbie to get their head around, where as C# tends to get the good stuff first...

Of the two, I prefer C# - but that doesn't mean I look down on VB.Net guys - they just chose another path...

As for the argument about C# being easier to migrate - if you really think that the biggest issue in migrating from one language to another is the end of line syntax then you my friend have a lot to learn...

Martin.

#200. By Greg...yes me again. Posted on 8/25/2009 8:38:37 PM
My namespace eh? To start with My is not a namespace it is a self reference to the current class...again not a namespace.

C# has a My equivalent, it's called "this"

VB.NET Blows

#201. By TheCPUWizard. Posted on 8/25/2009 8:42:08 PM
Greg...you are WRONG!

"Me" is a self reference (the same as "this" in C#.
"My" is completely different (and has been properly described)

#202. By Anonymous. Posted on 9/19/2009 11:24:34 PM
I find it interesting that most of the personal insults in this thread have been hurled by the C# proponents. The VB users meanwhile, simply proclaim themselves as being sexier.

On the topic of which is better... I'm can't provide a steadfast answer because I don't use C#. I like VB.NET, but at some point I will attempt to learn C# simply to beef up my resume.

From what I've briefly seen of C#:
-I don't like that the lines must end in semicolons. It's a wasted keystroke.
-I hate Hate haTe a case-sensitive language. It's nearly impossible to skim-debug code if you have to worry about capitalization. It also makes verbally discussing the source code difficult... [Person #1] "what's the value of varchar1?" ... [Person #2] "Are you asking about varchar1 with a capital 'V' or with a capital 'C'? Or the varchar1 that is all lowercase?"

From what I've experienced using VB:
-I find the lack of a batch comment (/* */) to be very annoying.
-I find the inclusion of "THEN" in the "IF/THEN" statement to be pretty much unnecessary.

Regarding some of the other topics I've seen mentioned in this thread...
-Option Explicit turned off might make you cringe, but allowing variables to change cast automatically is a big time-saver. You might think it could introduce problems into the application, incorrectly converting types into something else at the wrong time, but a competent programmer can handle the explicit conversions without any problems. Of course, if you anticipate that some inept programmers will be dealing with the code, you can always turn on the option explicit rule and type away the extra code to your heart's content. Flexibility in VB is part of what makes it good.

-Optional parameters in functions are GOOD! It is effectively a short-hand equivalent to using overloaded functions, and because it keeps all the code in one function, it allows for simplicity when maintaining the code. Overloaded functions on the other hand, can be numerous, and each function requires separate maintenance... not a very friendly prospect. Even if they're just shell functions referring to a central function, those shells still need tending.

I think the big issue though, is not the debate of whether C# or VB is better. Rather, the big issue is acknowledging that they both kind of suck. What we should be striving for, as developers, is a language that has C++ capabilities and speed, with a simple and intelligent interface, designed with the option to easily compile native executables for multiple operating systems. When that happens, we can all politely kick .NET to the curb.

#203. By navajo joe. Posted on 9/24/2009 7:11:08 AM
ur smokin' crack if u think vb is better.
i say kill all vb developers

#204. By TheCPUWizard. Posted on 9/25/2009 12:09:52 AM
@Anonymous #202

1) The ";" it quite valuable, at it eliminates line based dependancies. When appropriate you can combine multiple statements on a single line - you can not do this in VB

2) "but a competent programmer ...." (in the context of "Option Explicit". I defy you (or anyone else) to show me a single programmer who has worked in VB full time for more than 5 years who has not had at least ONE occurance of an unexpected typecast/conversion. ONE time is enough to justify it. AT 2am after coding solid for over 30 hours, the humnan will make a mistake, but the compiler will not. Regardless of language/platform/tool, ANY technique/approach/feature which can induce a compilation error instead of a potential runtime error (or misbehaviour) is preferred. ps: ALL Warnings should be set to be flagged as Errors, preventing the generation of an output file!

#205. By Martin Milan. Posted on 9/25/2009 12:30:14 AM
@CPU Wizard...

Nobody ever wins a language flame war, as I suspect you already know...

Both languages are fine - it mostly comes down to personal preference.

You can have multiple statements on the same line in VB - it's the colon...
It's not all that elegant though. The main point of the semi colon is that, as you hinted, it makes line feeds into whitespace from the compiler's perspective - which means none of that _ nonsense that VB has...

Not sure I agree with you that all warnings should be set to report as errors (try convincing a mid to large development team with an existing codebase of that!), but I appreciate where you're coming from - and I definitely agree with the idea that "the more strongly typed, the better..."

Having briefly looked at Python and Ruby, they are worthy languages, but I don't see the attraction of dynamic / duck typing. I'm firmly with you - find problems quickly, and find them with the compiler...

Martin.

#206. By TheCPUWizard. Posted on 9/25/2009 10:49:56 AM
@Martin, you are quite right about "flame wars", and I am definately NOT intending to start or expand one. The majority of my comments have been about techniques/methodologies/approaches to implementing code. Considering that most studies indicate that the cost of original (V1.0) development for an application is between 5% and 10% of the total cost over the lifecycle of a product, the only "Rational" goal is to invest the time upfront to maximize the maintainability of the system for the long haul.

I can write a very "poor" C# program just as easily as I can write a very "good" VB.Net one.

It is when one looks at the "Why" a certain feature is used (or abused) for to help achieve or inhibit this goal that things get "interesting" (and subjective); and it is in this context that I make most of my posts. When someone says "X is good because it allows Y" or "X is bad because it prevents Y" - but "Y" is a negative, that the net effect of the conclusion about X is exactly the opposite as to what is being presented!

#207. By Paresh. Posted on 10/8/2009 7:51:04 AM
Thanx for the saharing.

#208. By Blake. Posted on 10/9/2009 3:20:05 PM
VB is for mentally challenged kids who have a hard time spelling their own name.

Why do you think it's called Visual BASIC??

VB is far too verbose! If I wanted to write a novel, I would have become a writer, not a developer.

It comes down to this code for me:

VB.NET
--------------------------------------
Dim otherString As String = "blue"
Dim myString As String = ""
If otherString = "blue" Then
myString = "awesome"
Else
myString = "not so awesome"
End If

C#
--------------------------------------
string otherString = "blue";
string myString = (otherString == "blue" ? "awesome" : "not so awesome");

#209. By Kyle. Posted on 10/10/2009 8:34:17 AM
Hi, here is an interesting article (little old but still relevant):
http://www.bitwisemag.com/copy/bytegeist/bytegeist7.html

#210. By martin. Posted on 10/10/2009 9:21:31 AM
Never heard of IIF then?

If VB is to verbose for you, fine, don't use it... but drop the holier than thou act founded on little more than your own special preferences...

I prefer C# myself, but it's VB that pays the mortgage...

#211. By Guido. Posted on 11/27/2009 11:30:02 AM
Heya guys,

I've been reading this topic with much pleasure. It's fun to see the war between languages still rages on.
I myself come from a vb6 background and worked with vb.net since then. I've always loved the language, and I doubt
there is much that I cannot do which can be done in c#.

That said, I got a new job and I have to work with c#. Now I don't see this as a problem, it's always good to see
how another language handles things. I find it is somewhat harder to read but that is because of my vb background.
It all boils down to the same thing.


One thing I am bothered with (so far) in c# is the referencing, and I was hoping you guys could shed some light on why c# does what it does.

example:
I have 2 classes.
BaseClass
DerivedClass

As you might of guessed, DerivedClass inherits BaseClass.

Now when I use DerivedClass in my project, I also have to reference the BaseClass in my references, otherwise it will throw an error. Though in VB this isn't neccesary, I can just add a reference to the DerivedClass in my project and be done with it. C# however doesn't allow this. I'm sure there is a very good reason for it, but I can't figure it out. Now with all the brainpower around here, you guys should be able to tell me why C# requires all classes to be referenced, and vb is fine with just the derivedclass reference (I know that "under the hood" vb probably adds the reference to the baseclass too, but why doesn't c# also do this?

Hope you guys can shed some light on it.

For the rest, battle on. May the best language win
Personally I think it's all based on where you come from, and technically there isn't much difference. But I can imagine more novice programmers using vb.net over c#.net and therefor more junk is being produced with vb.net. It does however not mean that c# is better because of it. It just means there are more lazy vb.net programmers:D

Greetings from Holland!

#212. By Anonmous. Posted on 11/30/2009 11:01:48 PM
No, VB pretty much sucks. Any language that used dimensional statements to declare variables i don't want to use. I may be forced to use it though. Is .NET, so i must respect that. C# is a pretty solid language, but i think that C++ is still where it is at. I know i know, people say it is dying language. I still love it. C# is right up there, because it does garbage collection and since C# 3.0 you can declare pointers with the "unsafe" keyword and them compiling it with the "/unsafe" switch.

#213. By Anonymous. Posted on 12/4/2009 6:38:16 AM
I've been using VB.Net for years now. Love it. I can, of course write C# as well (the language syntax is too similar to have not picked it up over the years), but prefer VB.Net... C# reads like pig latin to me (string str = "Pig Latin";). There's no performance penalty with either language you use. The performance penalty is with poor coding, not reusing your objects, not closing connections, etc. (By the way GC.Collect calls garbage collection in VB....)

I would venture to say both VB and C# have long, happy lives ahead of them. Definitely, there is a greater share of developers using C# these days (anyone searching the net for code examples has noticed it). This is a shame really, since it will likely steer new developers away for VB.

In my years developing in .Net, I've seen nothing but C# vs. VB flame threads all over the place. Just use whatever you feel comfortable with and become awesome with it. Things could be worse. You could be using PHP. =)

#214. By Jimmy Hoffa. Posted on 12/8/2009 7:35:41 PM
Your out of your damn mind vb.net is better than C#...........................................

#215. By Stephen. Posted on 12/23/2009 6:40:49 PM
Just wanted to comment on this

6) There's arguably LESS typing in C#. The WITH statement is something that isn't used as often as the scope definition that makes c# less typing. Consider this:

If Not (Session["User"] Is Nothing) Then ' If not isnothing(Session["user"]) then <--- Avoids Object not set to ref. error


If ((txtUsername.Text.Length<1) Then
Return
End If
If Not ValidateUser() Then
Return
End If
End If
============================
if(Session["User"]!=null)
{
if(txtUserName.Text.Length<1)
return;
if(!ValidateUser())
return;
}

#216. By Stephen. Posted on 12/23/2009 6:40:53 PM
Just wanted to comment on this

6) There's arguably LESS typing in C#. The WITH statement is something that isn't used as often as the scope definition that makes c# less typing. Consider this:

If Not (Session["User"] Is Nothing) Then ' If not isnothing(Session["user"]) then <--- Avoids Object not set to ref. error


If ((txtUsername.Text.Length<1) Then
Return
End If
If Not ValidateUser() Then
Return
End If
End If
============================
if(Session["User"]!=null)
{
if(txtUserName.Text.Length<1)
return;
if(!ValidateUser())
return;
}

#217. By Bradstor. Posted on 1/10/2010 6:36:50 PM
I've got several projects going which are written in both languages, and frankly I can't see that much of a difference that's worth arguing about. Personally I like doing all the type conversions and casts explicitly in C#. I really like knowing exactly what the resulting type is exactly rather than assuming it will be implicitly cast as the type I want. I write code in the exact same style in both languages meaning that if I'm converting a type, I will explicitly code for a type conversion or a cast as the required object. Things like with are minor time savers which I don't personally use. I find it's quicker to type the first letter of the object, intellisense brings it up and then ctrl+space. These are all very minor points which hardly set one language above another.

One thing that I think is much better in C# is the use of overloads instead of optional parameters. An optional parameter is used when you specifically want to do something different with a method. Whether it's simply passing a boolean flag or something more in depth as adding more data. In either case your method is going to act differently, so it's worth splitting the actions up within your class object.

For example, just off the top of my head, Say you have a method which moves a graphic around the screen and returns a Point (the final position). By default the graphic's starting position is it's current position, but you may have an optional parameter which indicates a different starting position. A better way would be to have an overload with the new starting position. The overload method will set the starting position, and then call the original move method as two separate steps. Instead of having several "If.. Then" in your method which checks the values of the optional parameters, your functionality is separated into individual actions. With optional methods it's too easy to combine distinct functionality because it's related.

#218. By Bradstor. Posted on 1/10/2010 6:37:13 PM
I've got several projects going which are written in both languages, and frankly I can't see that much of a difference that's worth arguing about. Personally I like doing all the type conversions and casts explicitly in C#. I really like knowing exactly what the resulting type is exactly rather than assuming it will be implicitly cast as the type I want. I write code in the exact same style in both languages meaning that if I'm converting a type, I will explicitly code for a type conversion or a cast as the required object. Things like with are minor time savers which I don't personally use. I find it's quicker to type the first letter of the object, intellisense brings it up and then ctrl+space. These are all very minor points which hardly set one language above another.

One thing that I think is much better in C# is the use of overloads instead of optional parameters. An optional parameter is used when you specifically want to do something different with a method. Whether it's simply passing a boolean flag or something more in depth as adding more data. In either case your method is going to act differently, so it's worth splitting the actions up within your class object.

For example, just off the top of my head, Say you have a method which moves a graphic around the screen and returns a Point (the final position). By default the graphic's starting position is it's current position, but you may have an optional parameter which indicates a different starting position. A better way would be to have an overload with the new starting position. The overload method will set the starting position, and then call the original move method as two separate steps. Instead of having several "If.. Then" in your method which checks the values of the optional parameters, your functionality is separated into individual actions. With optional methods it's too easy to combine distinct functionality because it's related.

#219. By Bradstor. Posted on 1/10/2010 6:49:38 PM
Please note, the double post above was caused by angle brackets not being handled correctly, which triggered a server error.

#220. By Nomaan. Posted on 1/12/2010 9:36:59 AM
In VB.NEt you cannot locate matching IF statement of End IF statement by using keyboard shortcut "Ctrl + }" as you can do in C#.

#221. By phantomking. Posted on 1/19/2010 9:12:26 PM
Basic was the first language I learned when I was 12 years old, some 25 years ago. It was cool, mainly because I was able to easily make my computer perform calculations and graphics... just like the pros ;).

In university I was introduced to C, it looked cryptic at first, but man is it powerful, and really quite sexy. After graduating to the professional world I was working mostly with VB6 and VB.NET in the early days. Then I was introduced to C#, it was like déjà vu.

I don’t care what people say about “personal preference” and what works best for an individual, the original C style has lasted so long and has manifested itself in so many different languages, C#, Java, Objective-C, C++. VB.NET exists because Microsoft couldn’t strand all those VB6 apps out there without an easy migration path. C# exists because Microsoft wanted to keep mature and competent developers using their .NET product while providing much easier access to the .NET library vs. C++, so that RAD was possible.

Not that there aren’t mature and competent developers that use VB.NET, but if that is all you used I doubt you are.

#222. By phantomking. Posted on 1/19/2010 9:45:19 PM
Basic was the first language I learned when I was 12 years old, some 25 years ago. It was cool, mainly because I was able to easily make my computer perform calculations and graphics... just like the pros ;).

In university I was introduced to C, it looked cryptic at first, but man is it powerful, and really quite sexy. After graduating to the professional world I was working mostly with VB6 and VB.NET in the early days. Then I was introduced to C#, it was like déjà vu.

I don’t care what people say about “personal preference” and what works best for an individual, the original C style has lasted so long and has manifested itself in so many different languages, C#, Java, Objective-C, C++. VB.NET exists because Microsoft couldn’t strand all those VB6 apps out there without an easy migration path. C# exists because Microsoft wanted to keep mature and competent developers using their .NET product while providing much easier access to the .NET library vs. C++, so that RAD was possible.

Not that there aren’t mature and competent developers that use VB.NET, but if that is all you used I doubt you are.

#223. By Anonymous. Posted on 1/26/2010 3:06:53 PM
You can add implicit cast operator overloads in C# too if that suits you better.

#224. By Dan. Posted on 2/28/2010 11:45:51 PM
Ok, so I'm posting to an ancient post here, but for point 1, I would argue that if you are seeing 10 casts per 50 lines of code in any language, then you need to rethink your design.

#225. By Tomasz. Posted on 3/1/2010 4:33:43 PM
The requirement of semicolons breaks one of the fundamental usability design goals: design for the common case. For me one line statements are the most common and the trouble of writing multilines I can deal with.

#226. By Anonymous. Posted on 3/3/2010 12:45:13 PM
nice

#227. By vk. Posted on 3/3/2010 12:47:59 PM
ya.. its really a valuable one.......

#228. By Sanish Joseph. Posted on 3/18/2010 12:47:05 PM
Umm interesting, I was thing C# is better than VB.net But u just proved me wrong.
Great !!

#229. By zombieChan. Posted on 3/25/2010 12:04:34 AM
Why are we fighting about this?

We're .Net Developers

#230. By zombieChan. Posted on 3/25/2010 12:04:39 AM
Why are we fighting about this?

We're all .Net Developers

#231. By Martin Milan. Posted on 3/25/2010 10:05:28 AM
Some are more mature than others...

#232. By GOD. Posted on 4/7/2010 9:38:47 PM
You are a moron!

#233. By Lordango. Posted on 4/13/2010 2:35:08 AM
What started out to be a personal opinion became a debating topic.

This is interesting...

#234. By Wayne. Posted on 4/13/2010 3:59:06 AM
OK. I just started out with ASP.NET, as I have been working with ASP Classic for the better of 5 years and just recently gone professionally in my design skills.
I have been forced to work with ASP.NET as it offers a way to create Image Thumbnails without the need of a 3rd component to be installed on the server side.

I started out with the C# examples of the Uploadify and for the last 2 weeks have been breaking my back trying to get thing to work properly, of which they never did.
To start of with, I had to include the FileUpload control with the ashx file and with C# I had to create an Application of this really messed up the Uploadify, to where it had to be simi-rewritten.

Today I decided to give VB.NET a shot as the Uploadify example comes with both C# and VB examples.
About 3 hours into the project, I was able to create a Variable (From the error popup message) for the FileUpload control, to include it in the ashx file. C# DOES NOT give you this option within a "Web Site" page.
So.
One more thing about C#, it does not give you the handy little hints for uncluding Variables within your pages to use within other pages.

I think that I am going to stick with VB.NET, as I am already somewhat use to using VB code within ASP Classic anyway. I have also done Delphi programming, so that helps out as well with the cross-over to VB.NET.

Thanks to this page for my decision to go with VB.NET.

Wayne

#235. By jack. Posted on 4/16/2010 12:15:22 AM
i like what others tend to agree with

#236. By Steel. Posted on 4/23/2010 5:25:40 AM
VB.NET is certainly the languages of simpletons and dummies. You don't have to think. Why would a good programmer want to think?

#237. By Anonymous. Posted on 5/24/2010 5:44:38 PM
If you can get the intellisense working at all given the particular setup of your project and solution...usually takes a hack when you get beyond anything but the most basic of solutions. Don't try to advocate vb.net, you shill. It's as terrible as it's predecessors. Not to mention they decided to take all the existing OO vocabulary and change it around just because...well it's them. I mean wtf, mustinherit, notinherittable, shadows....did they not realize reserved words like virtual already existed? Seriously, don't advocate vb.net just because it's the devil you've become familiar with...that doesn't make it a good thing.

#238. By Anonymous. Posted on 5/24/2010 5:50:48 PM
Vb.net itself is nothing special. All this article proves is that microsoft designed VS and VB.NET in conjunction. As far as languages go, in general, those that were superior pre .NET and have been ported to .NET are still far superior to VB on multiple levels. I would admit that is just an opinion if you didn't have to draw a line between theory and reality at some point, but alas you do. All you're doing is pointing out the fact that VB.NET has had the inherent advantage of being so closely coupled with the development of VS. Cheers.

#239. By alberto. Posted on 5/28/2010 3:31:16 AM
ammmmmmmm can you repeat the question ? the thing is that iam very slow i know iam an asshole but its so you guys smile a little bye bye !!!!

#240. By JMemini8. Posted on 5/28/2010 8:07:08 AM
i read all your question and answers about pros and cons of vb.net and c#. For me both of this language is for professional and powerful that is why I used both of them for my project. I think you missing a good point about VB.Net over C# is the use of public "global" variables. Which is give more convenience for a programmer in creating a big project. Imagine if you have around 20 or more variables that will store data and needed to be use in most of the sub and function in your project. In C#, you have to use the get and set methods and declare a module as public static to get the value of the stored variables, well as in VB.Net you just have to declare a variable public in one of your modules then you can use that variables in your entire project.

#241. By stef. Posted on 6/4/2010 5:34:27 PM
dim strFact as String = ""
If (VB.NET > C#) then
strFact = "Hi! My name is Junior and i'm a script kiddie!"
else
strFact = "In my opinion, You've just been trolled..."
end if

#242. By Ravena. Posted on 8/19/2010 11:14:46 PM
The hole point of .Net is that you have several different sintaxes languages to create the same intermediate code.
Is J# better than C#? is F# better than VB.Net? c'mon, guys... that's only butting arround!

The tools for programming in VB.Net in VS are better then the tools for C# (intellisense, for instance)?
Depends!
C# doesnt have a With...End With statement and it sux when you're retrieving the controls from a Form and populating a class, for instance!
but try declaring a attribute with getters and setters in C# and in VB.Net in the 2008 version:
VB.Net
Private crap As Bollocks
Public Property Whatever As Bollocks
get
return crap
end get
set(value As Bollocks)
crap = value
end set
C#
public Bollocks Whatever { get; set; }
(this is fixed in 2010: Public Property Whatever As Bollocks)
or try a casting:
VB.Net
dim myCrap = CType(Bollocks, Crap)
C#
Crap myCrap = (Crap)Bollocks;

thow, the intermediate code generated for this to be read by the GACUtil (Global Assembly Cache Utility) IS THE F...ING SAME!
you can reverse a compiled C# project to a VB.Net project!

So, if you rather code in C#, good for you! You're so "i love java and linux style f...ing nerd"!
If you're glad programming in VB.Net, good for you to! You're a dumbass pseudo programmer!
Anyways, hardly any of us guys will take the office hotty out cuz we are geeks...
Try learning F#, Brains!

#243. By Ravena. Posted on 8/19/2010 11:16:55 PM
The hole point of .Net is that you have several different sintaxes languages to create the same intermediate code.
Is J# better than C#? is F# better than VB.Net? c'mon, guys... that's only butting arround!

The tools for programming in VB.Net in VS are better then the tools for C# (intellisense, for instance)?
Depends!
C# doesnt have a With...End With statement and it sux when you're retrieving the controls from a Form and populating a class, for instance!
but try declaring a attribute with getters and setters in C# and in VB.Net in the 2008 version:
VB.Net
Private crap As Bollocks
Public Property Whatever As Bollocks
get
return crap
end get
set(value As Bollocks)
crap = value
end set
C#
public Bollocks Whatever { get; set; }
(this is fixed in 2010: Public Property Whatever As Bollocks)
or try a casting:
VB.Net
dim myCrap = CType(Bollocks, Crap)
C#
Crap myCrap = (Crap)Bollocks;

thou, the intermediate code generated for this to be read by the GACUtil (Global Assembly Cache Utility) IS THE F...ING SAME!
you can reverse a compiled C# project to a VB.Net project!

So, if you rather code in C#, good for you! You're so "i love java and linux style f...ing nerd"!
If you're glad programming in VB.Net, good for you to! You're a dumbass pseudo programmer!
Anyways, hardly any of us guys will take the office hotty out cuz we are geeks...
Try learning F#, Brains!

#244. By Duck!. Posted on 8/31/2010 10:25:31 PM
Enforce good programming practices and you'll reap the rewards whatever the language.

#245. By John Li. Posted on 9/20/2010 2:40:12 PM
Lets face it. VB.NET is a superior language. It is more elegant than the java clone that c# is.
Case insensitivity is a dream.

#246. By @Young_Developer. Posted on 9/25/2010 10:53:09 AM
i am looking for the way hoe can improve my coding either using c# or vb.
as a new programmer i know that both languages produce the same result.
my question is How to maximize (code better)your coding skill to make your application run faster and better either by using C# or VB.
Thank you.

#247. By dave. Posted on 10/14/2010 3:11:28 PM
here's a good reason to choose c#: more jobs, higher salaries.

#248. By oh gosh. Posted on 10/20/2010 6:29:26 PM
I saw many stupid articles... but that one is number 1 !!!!!!
I'm a C# programmer, moved from VB6 (thanks god) 12 years ago and VB6 was "fine" but VB.NET is garbage given for temp uses until you all learn how to program in C#.

#249. By Programmer with Common Sense. Posted on 10/22/2010 11:11:42 AM
You are very right. VB.NET is smarter, better, much more efficient than C#. Problem with most programmers is that they are insecure about their coding. Most like to write code using cryptic symbols (i++ {}; &&) because it make them feel 'cooler'. They think C is more powerful than other languages. With all this noise that they have created, it is true that there are more jobs in C#. But remember, the smart ones teach us - when all birds are flying in one direction, it is possible that they are all going in the wrong direction. Why? Because they do not use their brain and just follow one bird, who may be quite clueless. It is also called the 'herd instinct'. Another example: You see a herd of cows grazing in a field, in one corner where there is less grass. The rest of the field is lush green with grass. If they could only think that spreading to other parts of the field will provide them with more grass. But Cows cannot grasp that simple fact because they are not smart enough (or simply put - quite dumb!). Well, that is what is happening with C# programmers. They think they have more formal education! That they are better! They are willing to write more code, waste more time, cost their companies more money! Are they really smart? Think about the cows!

C only became popular because at the time there was nothing else to replace other languages. Rest is all circumstantial. The point is currently, we do have some choice. Althoung VB.NET and .NET itself are not the greatest platforms for development, but they are better than Java and Open Source (support issues) and VB.NET makes a lot more sense than C# (even if Microsoft uses it more than VB.NET).

Moral: It pays to think. Just because a lot of people are doing something may only imply that it is because it appeals to the less gifted (more people equals a lesser average level of capability).

#250. By Programmer with Common Sense. Posted on 10/22/2010 11:12:45 AM
You are very right. VB.NET is smarter, better, much more efficient than C#. Problem with most programmers is that they are insecure about their coding. Most like to write code using cryptic symbols (i++ {}; &&) because it make them feel 'cooler'. They think C is more powerful than other languages. With all this noise that they have created, it is true that there are more jobs in C#. But remember, the smart ones teach us - when all birds are flying in one direction, it is possible that they are all going in the wrong direction. Why? Because they do not use their brain and just follow one bird, who may be quite clueless. It is also called the 'herd instinct'. Another example: You see a herd of cows grazing in a field, in one corner where there is less grass. The rest of the field is lush green with grass. If they could only think that spreading to other parts of the field will provide them with more grass. But Cows cannot grasp that simple fact because they are not smart enough (or simply put - quite dumb!). Well, that is what is happening with C# programmers. They think they have more formal education! That they are better! They are willing to write more code, waste more time, cost their companies more money! Are they really smart? Think about the cows!

C only became popular because at the time there was nothing else to replace other languages. Rest is all circumstantial. The point is currently, we do have some choice. Althoung VB.NET and .NET itself are not the greatest platforms for development, but they are better than Java and Open Source (support issues) and VB.NET makes a lot more sense than C# (even if Microsoft uses it more than VB.NET).

Moral: It pays to think. Just because a lot of people are doing something may only imply that it is because it appeals to the less gifted (more people equals a lesser average level of capability).

#251. By Programmer with Common Sense. Posted on 10/22/2010 11:45:03 AM
After my previous post I reads posts by our good English speaker - Ravena.

Ravena, Sin-tax is actually 'syntax'. There is no word such as sintax.

In any case, having read almost all the posts it truly is shocking how little C# programmers really know. This is not to imply that VB.NET programmers are better or smarter people in general. What it shows is that how easily programmers are influenced by information which is complete non-sense.

One person writes that option paramaters break the concepts of .NET. This silly ill-informed, but nice person, does not realize that just because .NET does certain things in a certain way does not necessarily mean that it is right.

Remember when C was created they even forgot to include the string data type! By the way I used to write device drivers from Unix in C, many years ago; so have knowledge of core C and its libraries (which are a lot more complex than C# and .NET). But I still say that C or C# are not the best languages, and VB.NET makes you a lot more productive. And that is what matters in business (or should matter). Unless of course you are writing software just for fun, in which case it makes no difference.

Problems with C# are:-

- It is more stressful to glance through the code (mainly dues the {} for everything). This has nothing to do with what college degree you have (or not), it is simply a human thing. It is harder to differentiate between blocks, unles you put cursor on each {}.
- There is no advantage in making a language case-sensitive. One only creates more confusion. They say you should not have variables such as - OneVariable and oneVariable. Although legal and allowed in C#, they can lead to bugs. So what is the point of case-sensitivity?
- Casts are confusing to read at best. I do agree that automatic data type conversions can lead to problems. But you can turn them off in VB. And more importantly, the problem exists in .NET due to it ridiculously large number of classes. If there were less of them, there would be less instances where casts would be needed.
- C# syntax. No it is not shorter, it is just more confusing. Glancing through VB.NET code you can quickly tell where there is a function, sub routine, where it ends, what is a property, where there is just a variable, etc. This does not make the code longer. If anything, casts and other issues in C# make the C# code much longer! Just because you do not need line breaks in C#, does not mean the code is shorter.

What programmers need to do is look at what is better for the business i.e. where you can produce applications with the lowest cost. I say that because I have been managing large IT departments now for over 15 years.

#252. By Aralmo. Posted on 1/3/2011 1:03:39 PM
Almost correct for .net 1.1 and event in 2004 i could make a top 20 reasons why vb.net should dissapear from the map.
If you compare VB.Net with C# now (2010) vb.net its just pure crap.

#253. By Shubhojit Banerjee. Posted on 1/19/2011 5:14:01 AM
Actually a nice post,but let me say that I work in the IT industry and c# is always used more preferably than its counterpart j#.net or vb.net...in fact in the past 3 companies i haven't seen anything apart from C sharp.

So take advantages/disadvantages in theory only...

#254. By James. Posted on 2/1/2011 8:47:53 PM
It's amazing how the discussion continues now in 2011, and here I am just adding to it. Even though the article begins, "So let's get practical, religion aside, with an eye on programmer productivity..." the arguments were basically 90% religion. Hopefully no PHB will use this article as a basis for mandating VB.NET. The few arguments that were valid (in terms of productivity) at the time the article was written are no longer valid, since the languages have both evolved.

1. If I see someone write "FormWindowState eState = 1;" in anything approaching enterprise code... I don't know what I'll do. But it won't be pretty.

2. As others have said, the behavior of Intellisense is not a good argument for one language over another. And even if this was a valid argument in 2004, it isn't anymore.

3. This was an arguably religious issue in the first place, but since C# 4 has optional parameters, it isn't even that anymore.

4. This is just a duplicate of #6, so I'll address it there.

5. You cover this in #7, so I'll address it there.

6. A few points here:
- "var a = new TextBox();" is the C# equivalent of "Dim a As New TextBox()".
- When you say "update some class" I hope you mean "update some object", because if those properties are all static you aren't following good OO principles for modularity and testability.
- I rarely see this pattern when it's not directly preceded by the instantiation, in which case the following code is even more concise (and the compiler will check that you're not accidentally setting the same value twice):
var myClassObj = new MyClassName {
ThisProperty = "sss",
ThatProperty = "sss",
ID = 4,
Name = "Frank
};
- If you really want to do something like this outside of an object instantiation, and if the extra code *really* bugs you, the following code will do exactly the same thing:
{ // braces create a private scope for "a"
var a = myClassObj;
a.ThisProperty = "sss"
a.ThatProperty = "sss"
a.ID = 4
a.Name = "Frank"
}

7.
- Raising events is one place where C# is unnecessarily verbose, and I agree that VB.NET makes things easier. A couple of extension methods can reduce the pain, but in a framework that depends so heavily on events, this is a glaring pain point.
- The Handles keyword is a nifty way to be very obvious about what event a particular method is expecting to handle. It's debatable how important this is, but this does appear to be a value-add.
- I don't see any practical value to the AddHandler keyword as opposed to putting a += statement in the constructor

8. C# doesn't need that feature because it's really easy to do this:
catch(FileLoadException ex)
{
if(attempt < 3 && MsgBox("do again?", MsgBoxStyle.YesNo) == MsgBoxResult.No)
break;
throw;
}

9. Saying case 1,2,3 could be useful, but I've had to do it so rarely as to make it a non-issue for me.

10. ... so since 4 and 5 were the same as 6 and 7, this should really have been "7 Reasons..."

#255. By blankJB. Posted on 4/4/2011 11:22:45 PM
Could it that the reason why C# is so popular in the enterprise, is that, if C#
programmers started using VB the following will quickly happen:
1. Their bosses will see what lousy programmers they are,
2. The CIO will look at the code and say "And for this rubbish, I pay you so much"
3. Repeat contract to fix impossible to track bugs will disappear
3. With C# there is no need to obfuscate your code
4. Even if an experienced C# programmer were to look at your code, the effort to understand
the code will be so exhausting that he will not have time to criticise the lack of elegance in
solving the business problem
5. How will all the "design pattern vendors" and "framework vendors" make a living?
C# rules!!

This arguments, to me sound akin to the arguments that could have ensued in a debate
about switching over from Latin to english. Maybe one day, when computers speaks perfect english
or japanese or whatever, our ancestors will look back and smile that we preferred c# to vb

I mean businesses faces enough challenges already:
So why should enterprise programmers prefer stilted english (c#) to plain english (vb)

I think MS did the world a great favour by showing that all computer languages are
largely equivalent, so any difference between vb and c# is a difference of "dialect" not
functionality, so why should businesses prefer an obscure dialect to a more expressive one?

Let the debate continue.
The future of businesses depend on it.
Our future depends on it.

#256. By James Close. Posted on 5/9/2011 12:26:36 PM
On the point about Optional parameters, C#4 now supports them fully along with named arguments, which is nice.

Before that you could use params keyword in C# (similar to ParamArray in VB).

However Overloads can never fully replace optional parameters due to type ambiguity, e.g. I can write an function in VB like:

Sub MyFunc(Optional ByVal strParam1 As String = Nothing, Optional ByVal strParam2 As String = Nothing, Optional ByVal strParam3 As String = Nothing)

I couldn't reproduce this with a series of overloads as all parameters are degenerate by type.

#257. By James Close. Posted on 5/9/2011 1:14:01 PM
On the point about Optional parameters, C#4 now supports them fully along with named arguments, which is nice.

Before that you could use params keyword in C# (similar to ParamArray in VB).

However Overloads can never fully replace optional parameters due to type ambiguity, e.g. I can write an function in VB like:

Sub MyFunc(Optional ByVal strParam1 As String = Nothing, Optional ByVal strParam2 As String = Nothing, Optional ByVal strParam3 As String = Nothing)

I couldn't reproduce this with a series of overloads as all parameters are degenerate by type.

#258. By Br.Bill. Posted on 6/10/2011 11:16:32 PM
Nice flame war you have going here.

Anyone who says that C# is never less verbose than VB.NET is lying or ignorant of the facts. They each suck worse in different situations.

Perfectly good example of C# syntax, inherited from C++, that is bad and too verbose at the same time, and how VB.NET handles it better:

Often we create classes with good, descriptive names, so it's easy to see what they do. Nothing wrong with that. Let's go with a real-life example: "System.Xml.XmlDocument", which is long, but not ridiculous.

Let's declare a new object of that type and create an instance for that object.

C#:
-----
System.Xml.XmlDocument xDoc = new System.Xml.XmlDocument();

This is stupid, ugly, redundant syntax. Mentioning the type twice has no benefit whatsoever, and decreases readability of the code.

VB.NET:
----------
Dim xDoc as new System.Xml.XmlDocument();

This is cleaner AND shorter. BETTER.

#259. By John. Posted on 6/27/2011 4:40:12 PM
Yeah, how about all the punctuation? It's more work, more chance for mistakes, more clutter, and perhaps most importantly, one little omission or typo can create cascading errors in much or all of the module following the mistake, and not so easy to find. What's worse is that in many cases it's overkill.

#260. By Dnyaneshwar Sable. Posted on 7/1/2011 8:40:51 AM
I think Vb.Net is much Easy than C#.Net.because Vb.Net's syntax is very easy to understand than C#.Net.

#261. By Ben Stephens. Posted on 7/14/2011 12:53:40 AM
It appears to me your real problem with C# is a lack of understanding.

#262. By johnnyxp64. Posted on 7/26/2011 6:39:01 AM
10)even thought a lot of users claim the need of special &_ to change code lines in vs2010 compiler you dont anymore! but 10 is for me that many c# developers clain the vb.net code spreads a lot to the left (weidth) but this can be avoided if you know how to type, and specially c# sreads a LOT to height so you have to scroll because all those stupid { } take an entire LINE!

11)in vb.net there is no special need for ending with special character like ; even though in vs2010 is changes lines without &_ still doesnt need the ; to understand where the lines END!

#263. By mayur pandey. Posted on 7/26/2011 10:41:39 AM
No "Val" function in C#
No "Format" function in C#

#264. By Casey Harmono. Posted on 8/19/2011 11:15:11 PM
10. Doesn't work as well with Visual Studio Lightswitch?

#265. By Casey Harmono. Posted on 8/19/2011 11:17:42 PM
#10. Does not work as well with Visual Studio LightSwitch. In C# it seems you can only use the drop-down write code box, where in VB you can look for an event that is not in the drop-down box?

#266. By sarathi. Posted on 9/19/2011 7:19:37 AM
hey guys and girls we are competitor to the Java .... don't argue or fight within our product...our product are best according to our situation....

#267. By Paul. Posted on 9/29/2011 7:48:37 AM
This is all bullshit. None of this really matters...C#/Vb.net A real expert knows this.

Red is better than blue cause its red.
Blue is better than red cause its blue.

All Bullshit... =)

#268. By Paul. Posted on 9/29/2011 7:50:28 AM
This is all bullshit. None of this really matters...C#/Vb.net A real expert knows this.

Red is better than blue cause its red.
Blue is better than red cause its blue.

All Bullshit... =)

#269. By Mike Lazur. Posted on 10/4/2011 6:35:23 PM
CTYPE() is a much simpler form of generics.

#270. By Meganeura. Posted on 10/27/2011 3:05:00 PM
Its been 5 years would u guys stfu already.

#271. By Andrea. Posted on 10/28/2011 1:43:55 PM
The simple fact that over the Internet you can find hundreds of programs to translate from C# to VB.NET and vice-versa tells more than any other argument that the two languages are just equivalent.

#272. By Andrea. Posted on 10/28/2011 1:44:07 PM
The simple fact that over the Internet you can find hundreds of programs to translate from C# to VB.NET and vice-versa tells more than any other argument that the two languages are just equivalent.

#273. By Rupesh. Posted on 11/5/2011 12:09:16 PM
which language is better to build Super market Billing System or suppose Showroom.

#274. By VB 4 LIFE. Posted on 11/22/2011 3:13:51 PM
VB .NET is FAR easier to work with. Hence, it is more efficient.

You type the first two letters of a block and you'll get the entire block. For eaxmple -

"Tr" (you select the try from the list and you already have the entire block statement) whereas in C# you have to not only type out the entire block but you also have to type the curly brackets and semi-colons as well.

If an expert VB .NET programmer was coding the same exact project as an expert C# programmer, the guy coding in VB .NET will finish much much faster. Anyone saying otherwise is an idiot.

While you're doing all your dumb conversions and adding ;'s and {}'s everywhere, the VB .NET programmer is already done and laughing at your face.

Time is money and VB .NET blows C# out of the water.

Get real people. Nobody thinks you're cool if you code in C#. More like they think you're an idiot.

The goal with programming is to solve problems. VB .NET does just as much as C# does and it is far easier and more efficient.

If you wanted to feel cool, you should have gone into nuclear engineering rather than Computer Science.

#275. By VB 4 LIFE. Posted on 11/22/2011 3:17:35 PM
VB .NET is FAR easier to work with. Hence, it is more efficient.

You type the first two letters of a block and you'll get the entire block. For eaxmple -

"Tr" (you select the try from the list and you already have the entire block statement) whereas in C# you have to not only type out the entire block but you also have to type the curly brackets and semi-colons as well.

If an expert VB .NET programmer was coding the same exact project as an expert C# programmer, the guy coding in VB .NET will finish much much faster. Anyone saying otherwise is an idiot.

While you're doing all your dumb conversions and adding ;'s and {}'s everywhere, the VB .NET programmer is already done and laughing at your face.

Time is money and VB .NET blows C# out of the water.

Get real people. Nobody thinks you're cool if you code in C#. More like they think you're an idiot.

The goal with programming is to solve problems. VB .NET does just as much as C# does and it is far easier and more efficient.

If you wanted to feel cool, you should have gone into nuclear engineering rather than Computer Science.

#276. By Anonymous. Posted on 11/22/2011 3:19:11 PM
VB .NET is FAR easier to work with. Hence, it is more efficient.

You type the first two letters of a block and you'll get the entire block. For eaxmple -

"Tr" (you select the try from the list and you already have the entire block statement) whereas in C# you have to not only type out the entire block but you also have to type the curly brackets and semi-colons as well.

If an expert VB .NET programmer was coding the same exact project as an expert C# programmer, the guy coding in VB .NET will finish much much faster. Anyone saying otherwise is an idiot.

While you're doing all your dumb conversions and adding ;'s and {}'s everywhere, the VB .NET programmer is already done and laughing at your face.

Time is money and VB .NET blows C# out of the water.

Get real people. Nobody thinks you're cool if you code in C#. More like they think you're an idiot.

The goal with programming is to solve problems. VB .NET does just as much as C# does and it is far easier and more efficient.

If you wanted to feel cool, you should have gone into nuclear engineering rather than Computer Science.

#277. By Anonymous. Posted on 11/22/2011 3:20:23 PM
VB .NET is FAR easier to work with. Hence, it is more efficient.

You type the first two letters of a block and you'll get the entire block. For eaxmple -

"Tr" (you select the try from the list and you already have the entire block statement) whereas in C# you have to not only type out the entire block but you also have to type the curly brackets and semi-colons as well.

If an expert VB .NET programmer was coding the same exact project as an expert C# programmer, the guy coding in VB .NET will finish much much faster. Anyone saying otherwise is an idiot.

While you're doing all your dumb conversions and adding ;'s and {}'s everywhere, the VB .NET programmer is already done and laughing at your face.

Time is money and VB .NET blows C# out of the water.

Get real people. Nobody thinks you're cool if you code in C#. More like they think you're an idiot.

The goal with programming is to solve problems. VB .NET does just as much as C# does and it is far easier and more efficient.

If you wanted to feel cool, you should have gone into nuclear engineering rather than Computer Science.

#278. By Christopher Welborn. Posted on 11/26/2011 2:52:56 PM
I don't see reasons 6 and 3 being very similar. The With statement, and using optional parameters Sub MySub(ByVal Optional bUseDebugMode As Boolean = False) are two very different things. Things that I love by the way. Number 10 should be curly brackets, semi-colons, case-sensative, otherwise ...Syntax in General.
-Cj [VB3 Pro - VB.Net 2010]

#279. By Christopher Welborn. Posted on 11/26/2011 2:59:01 PM
Read "It's the runtime stupid" , google it. The language doesn't matter, it all compiles to the same thing. M$ has said that there are almost no performance differences, all roads lead to IL.
-Cj [VB3 Pro - VB.Net 2010]

#280. By me@nospam.com. Posted on 12/2/2011 8:55:00 PM
Wow, what a load of crap.

#281. By Sergey. Posted on 12/15/2011 10:17:52 AM
Yes, VB is the best. C++ fuck and fuck c# and other langueges... sorry for my english

#282. By renjinil. Posted on 12/18/2011 5:56:19 AM
I am a Btech computer science student.I want to know about that,which language is better for frontend of project(vb.net or java)and which one is better for coding the web

#283. By Malarky. Posted on 12/30/2011 4:18:26 PM
Hello and Wishing everyone a Happy New Year,
I'm new to program language and admit to still being niggled by html and theories of gravity, so after having appreceated half this thread, will now probably need a few months for it to sink in!
But is the VB script useing more "electrickery" than c# in order to provide a window to help programmers catch the streams?
Great stuff to find,
Thanks.

#284. By Anonymous. Posted on 1/10/2012 10:56:14 PM
VB.net is better for the less experienced programmer.

Much of what you have said makes vb.net better is because of this.
if also makes VB.net not have some of the functionality of c#.

#285. By Krank. Posted on 1/12/2012 8:03:44 PM
I'm trying to figure out best way to do things in C# since I moved over from VB. So in VS/VB.NET code behind there was a dropdown right above the code window that had all the controls from the aspx/ascx and you could select a control and another dropdown would populate with all the events for that control. When you select an event the empty method automatically gets inserted into the code. Is there a similar way to do this in C# or do I need to remember all the event names and the arguments that go along with the events?

Thanks

#286. By Suresh. Posted on 1/24/2012 12:22:56 PM
hi this nice one to explain d basic difference........

#287. By victor soucik. Posted on 1/31/2012 9:25:12 AM
Bottom Line - VB.NET Sucks; ASP Classic (VBScript) is better.

#288. By victor soudick. Posted on 1/31/2012 9:25:54 AM
Bottom Line - VB.NET Sucks; ASP Classic (VBScript) is better.

#289. By victor soudick. Posted on 1/31/2012 9:39:42 AM
1. VBScript don't need casting. (Kiss my big butt).
2. Screw Intellisense;I do programming on Paper.
3. Parameters are for pussies. Just hardcode everything.
4. Got that on VBScript I think; only more flexible.
5. Handle's? You mean door handles? I got plenty of those at home
6. Write, don't type. Then type on Notepad. Notepad kicks ass
7. Events? Birthday Party Events? VBScript, less learning curve..
8. On Error Resume. Never get an error message ever. Beat that pussy.
9. VBScript got it.
10. Go Spend your time on something worthwhile.

#290. By victor soudick. Posted on 1/31/2012 9:40:57 AM
1. VBScript don't need casting. (Kiss my big butt).
2. Screw Intellisense;I do programming on Paper.
3. Parameters are for pussies. Just hardcode everything.
4. Got that on VBScript I think; only more flexible.
5. Handle's? You mean door handles? I got plenty of those at home
6. Write, don't type. Then type on Notepad. Notepad kicks ass
7. Events? Birthday Party Events? VBScript, less learning curve..
8. On Error Resume. Never get an error message ever. Beat that pussy.
9. VBScript got it.
10. Go Spend your time on something worthwhile.

#291. By victor soudick. Posted on 1/31/2012 9:43:24 AM
1. VBScript don't need casting. (Kiss my big butt).
2. Screw Intellisense;I do programming on Paper.
3. Parameters are for pussies. Just hardcode everything.
4. Got that on VBScript I think; only more flexible.
5. Handle's? You mean door handles? I got plenty of those at home
6. Write, don't type. Then type on Notepad. Notepad kicks ass
7. Events? Birthday Party Events? VBScript, less learning curve..
8. On Error Resume. Never get an error message ever. Beat that pussy.
9. VBScript got it.
10. Go Spend your time on something worthwhile.

#292. By trogo. Posted on 2/15/2012 5:30:58 AM
whatever.NET is big sh!t.
It is yet one more attempt of MS to put "programmers" into frame cage
where they cant broke anything and keep them away from windows.

#293. By Mike. Posted on 2/20/2012 7:55:31 AM
Since both c# and vb.net generates managed code, there's no place for any kind of performance differences between both languages. But concerning the verbosity of vb.net over C# it looks like the only gain for c# lies in the curly braces over the End Sub, End Function, End If,... Of course, the way we build long strings in c# is a must:
@"Multiple line spawning long string like some
of T-SQL complete stored proc definition without interruptions..."
In vb.net you have to double-quote-end each line and append an ampersand prior to start another line but it does not make your code less clear an spaghetti-like.
I also think that the vb compiler is much faster at least in its parsing job. Introducing syntactic error in code will make the IDE react instantly; in C# i noticed a significant delay before the error list shows up. Don't know exactly why but must mention that.

VB does not have to make use of implicit casting. If you set the compiler STRICT switch to ON, you'll have to cast every thing using CType and other convert methods.
C# is a totally new language not concerned with legacy code porting as for VB.NET from VB6. That's why we see some CLS compliance violation in VB.NET like the optional parameter in function definitions witch can be replaced with the override mechanism except for default value we must provide for each optional parameters. A Sub of function with one parameter witch is also optional cannot be differentiated from the parameterless version of the same sub or function and it does not compile. But the Overrides construct can be defined using a single version with an optional parameter so, less verbose :)

The handles keyword is again, optional but is also the default behavior of the event proc if we don't need to make use of AddHandler/RemoveHandler mechanism. It's there only because of the RAD aspect of Visual Studio IDE; just double-click a Command Button and you'll have defined a stub for the Click event of that button.


If Not (Session["User"] Is Nothing) Then
If ((txtUsername.Text.Length<1) Then
Return
End If
If Not ValidateUser() Then
Return
End If
End If

Can be written like this:

If Not (Session["User"] Is Nothing) Then
If ((txtUsername.Text.Length<1) Then return
If Not ValidateUser() Then Return
End If
4 lines not 8! ...

#294. By Ken. Posted on 3/1/2012 11:18:08 PM
I plan to switch from VB.NET to C#.

Does anyone have an opinion on which is better?

#295. By Anonymous. Posted on 3/4/2012 8:12:10 AM
Reason #10: Case insensitivity
Does it make sense to distinguish between let's say
thisvar
thisVar
Thisvar
ThisVar
THISVAR
... ?
C# does, because C does. What a mess...

#296. By Scott. Posted on 3/8/2012 4:26:10 PM
I don't even have to read this article to know VB.Net will never be better than any language. Especially C#

#297. By UDontEvenKnow. Posted on 3/15/2012 6:08:03 PM
The only people who EVER say C# is better than VB are those that have never used it or used it far less than they've used C#. VB is twice as fast. I'm proficient in both and you can send VB code out at twice the rate. Time is money. VB had intellisense and TONS of built in functions long before C#. Now that they are both in .NET, those advantages go away but still doesn't help the fact that VB is far faster. Between event handling, case-insensitivity, looser programming constructs, etc., etc., etc. VB blows C# out of the water. If you argue that, you are biased. People, to this day, still have the misconception that VB is a prototyping language and not a serious language. I can do anything in VB that I can do in C#...guaranteed. And bad programming is bad programming...don't give me the argument that VB leads to bad programming. It only does if you're a bad programmer. Most people I directly talked to who have bad opinions of VB haven't used it since 5.0 or 6.0 days...some have never used it at all, they just go off misconceptions similar to those plastered all over this board.

#298. By UDontEvenKnow. Posted on 3/15/2012 6:08:19 PM
The only people who EVER say C# is better than VB are those that have never used it or used it far less than they've used C#. VB is twice as fast. I'm proficient in both and you can send VB code out at twice the rate. Time is money. VB had intellisense and TONS of built in functions long before C#. Now that they are both in .NET, those advantages go away but still doesn't help the fact that VB is far faster. Between event handling, case-insensitivity, looser programming constructs, etc., etc., etc. VB blows C# out of the water. If you argue that, you are biased. People, to this day, still have the misconception that VB is a prototyping language and not a serious language. I can do anything in VB that I can do in C#...guaranteed. And bad programming is bad programming...don't give me the argument that VB leads to bad programming. It only does if you're a bad programmer. Most people I directly talked to who have bad opinions of VB haven't used it since 5.0 or 6.0 days...some have never used it at all, they just go off misconceptions similar to those plastered all over this board.

#299. By Quandary. Posted on 4/4/2012 6:34:20 AM
10: VB.NET supports local static variables.

#300. By Quandary. Posted on 4/4/2012 6:34:46 AM
10: VB.NET supports local static variables.

#301. By Will. Posted on 4/6/2012 6:58:36 PM
VB.NET is better because:
No ;
'End Next' means more than '}'
is faster to parse than C#.
Case insensitivity makes life faster.
Make a global change and wait in C#.
More intuitive and self documenting.
Coding just flows from your fingers.

#302. By pergsify. Posted on 7/25/2012 1:17:48 PM
welp... our clients would say "Show me the output" ,they wouldnt ask "in C# or VB" .perhaps it isn't about C or VB after all, it is how you execute a process the shortest path possible.

#303. By pergsify. Posted on 7/25/2012 1:26:11 PM
welp... our clients would say "Show me the output" ,they wouldnt ask "in C# or VB" .perhaps it isn't about C or VB after all, it is how you execute a process the shortest path possible.

#304. By Jalle. Posted on 9/15/2012 10:39:36 PM
Signing every word you said !

I am big fan of VB.NET and now forced to do my coding in C#.

AND I HATE IT!!!

and 11. point to add to your list:
After all VB is coded with pure english words. today its almost as i you know to write english you know to write vb code.


PS: many more examples here http://www.simple-talk.com/dotnet/.net-framework/10-reasons-why-visual-basic-is-better-than-c/#commentform

#305. By Jalle. Posted on 9/15/2012 10:42:09 PM
Signing every word you said !

I am big fan of VB.NET and now forced to do my coding in C#.

AND I HATE IT!!!

and 11. point to add to your list:
After all VB is coded with pure english words. today its almost as i you know to write english you know to write vb code.


PS: many more examples here hxxp://www.simple-talk.com/dotnet/.net-framework/10-reasons-why-visual-basic-is-better-than-c/#commentform

#306. By Jalle. Posted on 9/15/2012 10:42:54 PM
Signing every word you said !

I am big fan of VB.NET and now forced to do my coding in C#.

AND I HATE IT!!!

and 11. point to add to your list:
After all VB is coded with pure english words. today its almost as i you know to write english you know to write vb code.


PS: many more examples here hxxp://www.simple-talk.com/dotnet/.net-framework/10-reasons-why-visual-basic-is-better-than-c/#commentform

#307. By Jalle. Posted on 9/15/2012 10:56:32 PM
Signing every word you said !

I am big fan of VB.NET and now forced to do my coding in C#.

AND I HATE IT!!!

and 11. point to add to your list:
After all VB is coded with pure english words. today its almost as i you know to write english you know to write vb code.


PS: many more examples here hxxp://www.simple-talk.com/dotnet/.net-framework/10-reasons-why-visual-basic-is-better-than-c/#commentform

#308. By Pete. Posted on 1/2/2013 8:13:17 PM
I've used VB.NET and I've used C#. C# is superior in a number of ways. This was clearly written by someone who doesn't get C#.

#1: "The amount of data casts and conversions in C# is gigantic" - Your understanding of C# is about as good as your knowledge of English. Gigantic is a measure of size, not quantity. Real programmers understand the value of strongly typed languages.

#2: How intellisense operates is an implementation independent of the language. A real programmer would understand this.

#3: C# now has optional parameters, but I never missed them before it go them. Optional parameters are rarely a good idea from the point of view of writing quality code. The muddy the intent of the method.

#4: static classes, checked and unchecked code, unsafe code, partial interefaces, multiline comments. -nuff said.

#5: Now implemented in C#

#6: You show a single contrived example and say C# is more verbose than VB. Show me a large project that's been converted from one to the other and then we'll talk. How about this:

if (x==4) DoItFor(4);
vs.
If x = 4 Then
DoItFor 4
End If

I could show a dozen example like that with other keywords and I guarantee you that kind of stuff is 10 times more common that your example.

#7: There are generics that can do this as simply in C#.

#8: I HAVE NEVER had a need for something like that.

#9: How often do you implement "very large state machines?" I'm thinking back over my 30 year career as a programmer and not one time comes to mind. Not that people don't, but again, I've never needed it.

All in all, a list made by someone who fancies themselves a programmer, but doesn't really understand good programming practice.

#309. By Amol S. Yelne. Posted on 1/12/2013 10:24:35 AM
C# is better than vb.net

#310. By nuffSaid. Posted on 1/27/2013 4:04:46 PM
Pete, for someone who so easily bashes someone for lack of programming knowledge I'm surprised you didn't know that in VB you can do this:

If X=4 Then DoThis()

or

If X=4 Then DoThis() Else DoSomethingElse()

Also, optional parameters are very often a good programming practice. Why worry about overriding when I can just add an optional parameter and not break backward compatibility, etc.? There are many, many good reasons which is why they added them in C# too. I'm sure you're a very good programmer but don't bash VB or someone trying to explain its benefits when you don't know it yourself.

I use both VB and C# along with many others and I can tell you from experience, VB churns out at a much faster pace.

#311. By lymar bayod. Posted on 2/18/2013 9:24:22 AM
its very hard 2 creat a program.can u pls teach me hehehe

#312. By lymar bayod. Posted on 2/18/2013 9:25:08 AM
its very hard 2 creat a program.can u pls teach me hehehe

#313. By schlebe. Posted on 3/12/2013 3:41:19 AM
Great and fun article :-)

I am engineer and I program in C since 1986 and in C++ since 1996 and I found VB.Net more readable and more ... professional !

I will add 4 other reasons to use VB.Net

The first reason is that in C# you can generate a very vicious error in IF when you mistype the equal operator.

See the C# code with this error

if (iCount = 0)
{
// iCount is assigned and the comparaison is incorrect
// that is very dangerous pour Enterpise application
// so C# is for little application !
}

I know that you can write

if (0 = iCount)
{
// error at compile time
// so you can correct your code in development !
}

but this is very unreadable !!!

In VB, this problem does'nt exist !

if iCount = 0 then
' no problem in VB
End If

I program in C++ since 1996 and I have made this error very often :-)
In VB, I do not made this mistake anymore.

#314. By schlebe. Posted on 3/12/2013 3:43:30 AM
Great and fun article :-)

I am engineer and I program in C since 1986 and in C++ since 1996 and I found VB.Net more readable and more ... professional !

I will add 4 other reasons to use VB.Net

The first reason is that in C# you can generate a very vicious error in IF when you mistype the equal operator.

See the C# code with this error

if (iCount = 0)
{
// iCount is assigned and the comparaison is incorrect
// that is very dangerous pour Enterpise application
// so C# is for little application !
}

I know that you can write

if (0 = iCount)
{
// error at compile time
// so you can correct your code in development !
}

but this is very unreadable !!!

In VB, this problem does'nt exist !

if iCount = 0 then
' no problem in VB
End If

I program in C++ since 1996 and I have made this error very often :-)
In VB, I do not made this mistake anymore.

#315. By schlebe. Posted on 3/12/2013 3:48:19 AM
Sorry for the 2 identical posts.
But the ASP Site is not working correctly.
I suppose that is it written in C# :-)

#316. By schlebe. Posted on 3/12/2013 3:54:09 AM
The second reason is the if on 2 lines without { }

In C# (like in C), you can write

if (iCount < 10)
DeleteProducts();

but you can also add a semicolon behind the IF and you obtain

if (iCount < 10);
DeleteProducts();

The copmiler compile but in runtime your program does'nt work like you will !

This mistake is not easy to find.

In VB, you write

if iCount < 10 then
DeleteProducts()
end if

or

if iCount < 10 then DeleteProducts()

I program in C++ since 1996 and I have made this error very often :-)
In VB, I do not made this mistake anymore.

#317. By Anonymous. Posted on 3/12/2013 4:04:28 AM
The third reasons is

It is more easy for me to type "then" or "endif" that to type [] or {}.

On my keyboard,
to type { I must press AltGr + 4
to type } I must press AltGr + °

For this message, I have typed {} to times and that is very annoying.

Personally, I found C++ and C# very cryptic, too much cryptic and I prefer to read plain text like "then" or "end if".
In my C++ code, when the IF is too long I had a pseudo "then" in my code like this ...

#define then
#define and &&
#define or ||

if (iCount > 0
and (sIBAN != ""
or sBIC != "")
)
then
{
// TRUE code here
}
else
{
// FALSE code here
}

I found that more readable !

#318. By Anonymous. Posted on 3/12/2013 4:15:53 AM
The 4th reason is that there are more possibility to "break" a loop in VB.Net that in C#.

Here is a VB.Net example

Try
While iCount > 0
Do While iStep < 10
If sText = "" Then
Exit While
End If
...
For i = 0 To 8
If sName = "" then
Exit Do
End If
If sSociety <> "" then
Exit Try
End If
Next i
Loop
End While
Catch
End Try

In C++, this is impossible.
The "break" with parameter like "break loop1" where "loop1" is a label before the loop instruction does'nt exist !!!

Sorry for my indentation but I have not found (quickly) explanation about the message syntax !

#319. By schlebe. Posted on 3/12/2013 4:30:39 AM
The last reason is that the C# "break;" statement used in "switch" statement is a vicious coding.

In C#, you can continue the code in the following "case" bloc if the preceding bloc have no break statement.
Some people say "that is a advantage".
With my experience, I say "that is a disavantage and a source of mistake" !

Some times, I forget the "break;" and the stupid C# compiler accept my functional mistake.
Some times, per mistake (copy of code by Ctrl+X), I delete the "break" and the stupid C# compiler accept the change.

I program in C++ since 1996 and I have made this error very often :-)
In VB, I do not made this mistake anymore. There is no "break" to write in Select.

I have terminated and I am very interesting to read the argument of the C# or Java programmers.

I have forgot to say that like many other readers, I like the Case Insensitive functionality of Visual Basic.

#320. By lin. Posted on 6/4/2013 10:18:37 AM
Great work

#321. By Howard. Posted on 8/8/2013 7:44:34 PM
Although I prefer C# for personal use... I try to use VB for team development. Mostly because VB syntax is stricter. Stricter syntax results in fewer logic errors and helps ensure that all the developers on the team use the same design patterns.

#322. By siraj. Posted on 9/23/2013 10:42:13 AM
how to insert the jpg image in vb.net sir..........

#323. By Anon. Posted on 9/28/2013 1:08:25 AM
You are a but clencher.

#324. By cindy. Posted on 10/24/2013 4:15:23 AM
as for me,C# is my favorite and i used it to create barcodes
http://www.keepautomation.com/guide/csharp_barcode_generator.html

#325. By cindy. Posted on 10/24/2013 4:16:47 AM
as for me,C# is my favorite and i used it to create barcodes
http://www.keepautomation.com/guide/csharp_barcode_generator.html

#326. By cindy. Posted on 10/24/2013 5:48:56 AM
as for me,C# is my favorite and i used it to create barcodes
http://www.keepautomation.com/guide/csharp_barcode_generator.html

#327. By VB_Fan_1. Posted on 11/19/2013 3:11:45 PM
I would like to add another example for an advantage of VB.
Imagine you are a programmer who has the task to add a line of code after the inner loop of a certain procedure.
You scroll to the end of that procedure and you see this:

End Select
End If
Next cntInner
End If
End If
End Select
Next cntOuter
End If
End Sub
End Class

You immediately see where to insert your new line code.
Now the same in C, C# or Java:

}
}
}
}
}
}
}
}
}
}

That's why curly-brace-programmers say things like "it is bad practice to have more than 4 nesting levels".
LOL. VB programmers can easily handle a lot more nesting levels without losing code readability.
By the way, the keyboards in most countries have the curly braces difficult to access (alt gr + 7 and alt gr + 0).
This also applies to other types of braces and other characters used a lot in C# (|| && for example).

#328. By VB_Fan_1. Posted on 11/19/2013 3:16:01 PM
I would like to add another example for an advantage of VB.
Imagine you are a programmer who has the task to add a line of code after the inner loop of a certain procedure.
You scroll to the end of that procedure and you see this:

End Select
End If
Next cntInner
End If
End If
End Select
Next cntOuter
End If
End Sub
End Class

You immediately see where to insert your new line code.
Now the same in C, C# or Java:

}
}
}
}
}
}
}
}
}
}

That's why curly-brace-programmers say things like "it is bad practice to have more than 4 nesting levels".
LOL. VB programmers can easily handle a lot more nesting levels without losing code readability.
By the way, the keyboards in most countries have the curly braces difficult to access (alt gr + 7 and alt gr + 0).
This also applies to other types of braces and other characters used a lot in C# (|| && for example).

#329. By ISHYGDDT. Posted on 1/3/2014 11:21:56 PM
Wow, oh shit, i don't even have words to describe this cancerous, failed abortion piece of shit. Your points are so weak. You are a fucking script-kiddy, a total moron that doesn't know how to program, just knows a shitty language that nobody will ever use to a useful purpose in the industry. Cancer. Die.

#330. By gani. Posted on 3/3/2014 7:39:13 AM
VB is Faster than C# and much more on Intellisense factor.
Another is, VB is globally accessible by default without instantiating a new class.This is what I really most appreciated.

VB
Form1.ShowDialog

C#
Form1 myform = new Form1();
myform.ShowDialog();

#331. By gani. Posted on 3/3/2014 8:28:10 AM
hey idiots.. c# is old way-> ride your camel ^_^
vb is modern like obama!

#332. By Ali. Posted on 3/27/2014 2:28:28 PM
Very Nice :X

#333. By Anonymous. Posted on 4/23/2014 3:30:36 PM
these are only a few reasons why I decided to start coding on PC's using VB.NET and not C#. Thanks for this - there are to many other posts saying the opposite

#334. By srinivas. Posted on 6/11/2014 10:13:25 AM
good