a companion discussion area for blog.codinghorror.com

VB vs. C# -- FIGHT!


#1

If I see one more blog entry complaining about VB's verbosity, or the elitism of C# developers, I think I'm gonna puke. Why can't we all just get along? Part of what makes the .NET Runtime unique is that it offers you a choice of syntax; we should embrace that philosophy, rather than wasting a lot of time sniping at perceived slights. If I wanted a single language to bind them all, I'd be writing in Java. 'nuff said.


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2004/07/vb-vs-c----fight.html

#2

Peace! The VB vs. C# debate is getting old.


#3

The FileDisassembler add-in helps a lot when converting VB to C# or vice versa… very handy!

http://www.denisbauer.com/NETTools/FileDisassembler.aspx


#4

This is getting a bit tired. Personally you must understand that you are programming against the CLR so what syntax you use that the upper level really does not matter too much. More on this at my blog:
http://blog.richard-callaby.net/PermaLink.aspx?guid=d135611d-8c50-43e1-a25e-a88a3b8d4f8f


#5

The following C# to VB.NET online converter does an excellent job from my experience:

http://www.developerfusion.com/utilities/convertcsharptovb.aspx


#6

Well, the only things keeping me from C# at this point are…

  1. Lack of background compilation. It’s more productive, period. If people don’t like it they should be able to switch it off, but not including it is a misstep. Consider that the #1 most popular (and most prominently advertised) feature of the much-loved Reflector is EXACTLY THAT: background compilation!

  2. Case sensitivity is Just Wrong. I cry for a world where “Jeff != jeff”. It gets abused, too: I’ve worked on several C# classes where public variables are named Var1 and private variables are named var1? Yeah, that’s not confusing at all… :stuck_out_tongue:

Other than that, it’s a wash, but those two things will keep me in VB.NET for reasons of productivity.


#7

er… by Reflector I meant JetBrains “Resharper”. Sorry.

http://www.jetbrains.com/resharper/

One of the most powerful and helpful features in ReSharper is its ability to quickly detect and highlight errors in code, without the need to compile it. ReSharper automatically analyzes your code while you work and will highlight a variety of possible syntax or logical errors. It can also detect and emphasize statements or constructs that you should be warned about (e.g., unused or uninitialized variables).

Smells like background compilation, and it’s the first item listed on their advertising page.


#8

I agree that objective better or worse in language-religious debates is rubbish. However, as someone who has spent more than a couple of years with C-ish languages as well as VB, I have to say on an aesthetic level I much prefer writing guard clauses this:

public void foo(string arg)
{
if (null == arg) return;
// code here
}

than this:

Public Sub Foo(ByVal arg As String)
If arg is Nothing Then
Return
End If
End Sub

I would love a VB version of the If statement that didn’t require an end if for a return allowing me to have:

Public Sub Foo(ByVal arg As String)
If arg is Nothing Then Return
// code here
End Sub

Is End If so bad that it makes me puke? Hell no. And this is a matter of personal taste. But it bugs me enough to make me select C# for new projects.


#9

I’d rather hire someone the is programming C# than VB.Net for some reasons I’ve experienced:

  1. Professional/advanced programmers tend to choose C# because of it’s syntax.

  2. C# programmer most often have background from other programming languages.

  3. Every C# programmer I’ve met reads and writes VB.Net code very good, while VB.Net programmers scratch their head and give up when they see a few lines of C# code.

  4. Beginners tend to start with VB.Net. While other programmers start with C# when moving to the .Net platform. Also I’ve seen many moving from VB.Net to C# after some time. I have never seen anyone move from C# to VB.Net (unless “forced” by management).

This is only what I’ve seen, and ofcourse isn’t the most important aspect of hiring someone for a job.

(I’m programming both C# and VB.Net :slight_smile:


#10

Jeff, I’m with you on background compilation being a nifty feature (done right), but the syntatic productivity gains of C# far outweight that for me. Every so often, I hit CTRL+SHIFT+B out of habit (I think I picked this up from TDD) and it provides enough feedback for me. Besides, I’d lay a substatial wager that you’re not as dependent of background compilation as you might think. How often are you really screwing up syntax? I’d venture a guess that it’s not that often. Also, how many times are you slinging some text around and the IDE is adding in some stuff you’re going to have to delete? Here’s an example:
Dim mArray As String(5)

Now you might reach over and copy mArray and paste it five times on five consecutive lines in order to initialize each element. Then VB comes along and adds the annoying () at the end and underlines the whole thing in blue. You know what I’m talking about… :slight_smile:

As for case sensitivity, I most certainly don’t think Jeff should == jeff. It’s just too easy for programmers to think this is some sort of truth and woe to them when they actually have to worry about encodings and i18n.


#11

Another great C# - VB.NET converter that works in real time (?!) as you type:

http://www.carlosag.net/Tools/CodeTranslator/Default.aspx


#12

My C++ prof would roll over in his grave…
public void foo(string arg)
{
if (null == arg) return;
// code here
}

Your C++ professor must not have been Martin Fowler who recommends the guard clause technique over nested ifs since they are so much easier on the eye (and it goes without saying with whom I wholeheartedly agree). Of course, this is a matter of preference, but escaping out of the function in one line of code to enforce my preconditions (feel free to throw an ArgumentNullException or other exception rather than simply return) seems elegant to me. Oh yeah, I also believe in programming by contract. :wink:


#13

If you’re comparing strings in an application, should Jeff be equal to jeff?

Ab-so-fricken’-lutely they should be equal.

Is http://www.Amazon.com the same website as http://www.amazon.com ? Can I get a hell yes?

Case sensitivity is the outlier, NOT the norm. Sure it’s necessary in some extraordinary situations, but making it the default is just wrong and violates the 80/20 rule big time.


#14

No moral reason for the discrepancy in pay packet size, perhaps, but the reason (and note I haven’t looked at the stats) is because generally the banks are adopting c# big time for the UI (primarily because it’s similar to java, and most devs in the banks at the moment are Java, and C++ to a lesser extent). the Banks tend to pay more… and if other companies are competing with the banks for c# staff (for whatever reason), then they will in turn have to pay more… just a theory.


#15

I like C# because it makes jumping into ActionScript, JavaScript, and other languages easier for me. Suprisingly, I was 95% vbScript in the classic ASP days and I don’t miss it one bit. Looking at vbScript just looks funny now.

Do VB.net and C# actually have any real strengths over the other?


#16

If you’re comparing strings in an application, should Jeff be equal to jeff?

Ab-so-fricken’-lutely they should be equal.

Your kidding right? RIGHT??!!!

but making it the default is just wrong and violates the 80/20 rule big time.

80/20 rule? Well, I guess I shall not pitty the poor sole who only has programed on one platform with only one langage… Like Directories in MS not being case sensitive yet in the real world, er… I mean Linux C:\home IS different the C:\Home

Your right: http://www.Amazon.com the same website as http://www.amazon.com is the same place… a LOCATION but, if Jeff == jeff in your world how in God’s name would you ever test for Jeff !== jeff!!!


#17

Everyone knows the Linux and UNIX file systems are case sensitive. The question is, is that a good idea?

The English language is not case sensitive, nor are the humans that speak it. Most people will not even see “may-2005” as being different from “May-2005”. The psychological different between the two is just shy of nil. So why needlessly complicate things for the user?

Since the compiler is a program that humans work with. Since humans are case insensitive, the compiler should be as well.

As for not being able to test for “Jeff !== jeff”, you are just being dense. No one is saying that we should remove the ability to make case sensitive comparisons.


#18

in German common words are starting by a majuscule, but adjectives not. In some sens german is case sensitive.

But anyway I agree with you, case sensitive naming rules is really tricky. I’ve never seen any arguments in favour


#19

Most of the arguments against case sensitivity are the same ones used as for. Its all a comfort issue. I prefer insensitivity. However, when forced to write in Java as is often the case in my job. I deal with it. The paycheck has the same numbers at the end of the week.

Wow, are we still at this after two years???


#20

Wow, are we still at this after two years???

I know. And many programming religious wars go back 10, 20, even 30 years. It’s amazing any actual work gets done, isn’t it?