Totally a newbie question.. Sorry.

My co-worker & myself are seeing that C# is the prefered language over VB. We would like to change, but right now it is only to make sure we are more marketable as our company is going down the tubes.

We cannot go to our company using that as a reason to change from VB to C#..

Can anyone give us the arguement to convince our company it is in their best interest. ( I would imagine, it must be popular due to the benifits it has over VB.)

>right now it is only to make sure we are more marketable
>as our company is going down the tubes.
Changing your implementation language because it's more "popular" isn't going to save a company.

>I would imagine, it must be popular due to the benifits it has over VB.
Not really. VB.NET and C# are largely identical in terms of features and capabilities. The choice of one or the other is more often than not based on the preference and experience of the development team. Developers coming from VB6 will have an easier time migrating to VB.NET and C++ or Java developers will have an easier time migrating to C#.

i thinks all is depend on your ability. both of this language is great. as narue said a "Popular" language is not going to save your company but a language which u capable to write. If you prefer C# than VB but you didn't have an ability or experience in C# it will reattack you. But if you still want migrate to C# i suggest do step-by-step. so when you fully change to c# you have ready to facing the problems in front.
happy coding friend :)

C# and vb.net are the same for all intensive purposes. It's really about formatting... easy to convert from one language to another.

It is always good not to be tied to just the Microsoft platform. Rather than C# I would rather pick up Java. Once you are familiar with Java, C# will be easy to add.

commented: Boo at this post! Grats on your thousandth anyway, when you make it! +0

You can also look at it this way. If i'm comming to your company because i need you to make a program that can do what i need. and you can say that your company can program in C#, and VB.Net that looks a little more impressive than saying you can only program in 1 language. But i also have to agree that you might want to pick up Java since it wont keep you tied down to Microsoft.

>It is always good not to be tied to just the Microsoft platform.
Can you say Mono?

>Once you are familiar with Java, C# will be easy to add.
And vice versa, with the language syntax at least. The big learning curve for both is the library.

well, I see that I am a bit late in replying to this topic, but a friend just found this and threw the link my way.

As a programmer with 3 years experience in Java and 2 in C#, I'll have to say that there were quite a few noticeable differences between VB and C#.

First of all, if you are using the .NET framework, you can bounce around between languages and get the best of both worlds, but as far as I've seen, there isn't a library I've needed from VB that wasn't implemented better in C# or J#.

The best reasoning behind C# over VB is code readability.
When you are working on a project that involves more than one person, is going to be used commercially, and requires speed and maintainability, C# has the right toolset.

With the Visual Studio IDE, you have complete control. Drag and drop for controls on your windows forms, Intellisense for making quick and easy implementation of new libraries, and the ability to interop between all the languages of the .NET Framework are all great for making commercial line software efficiently.

So far as readability goes, here is one example involving a foreach loop, a do while loop, and using the MySqlDataReader class. I think that this should suffice for my argument:

VB Code:

Private Sub setUpArray(ByVal reader As MySqlDataReader)
        Dim row As DataRow

        For Each row In reader.GetSchemaTable.Rows
            Me.colList.Add(row.Item(0).ToString)
        Next

        Dim colCount As Integer = Me.colList.Count

        Do
            Dim row As New SqlDataRowClass(Of String, SqlDataClass)(Me.colList)
            Dim colNum As Integer
            For colNum = 0 To colCount - 1
                row.Add(Me.colList.Item(colNum), New SqlDataClass(reader.GetString(colNum), reader.GetValue(colNum).GetType.ToString))
            Next colNum
            Me.rows.Add(row)
        Loop While reader.Read

        Me.isReady = True
    End Sub

C# Code:

private void setUpArray(MySqlDataReader reader)
{
    foreach (DataRow row in reader.GetSchemaTable().Rows)
    {
        this.colList.Add(row[0].ToString());
    }

    int colCount = this.colList.Count;
    
    do
    {
        SqlDataRowClass<string, SqlDataClass> row = new SqlDataRowClass<string, SqlDataClass>(this.colList);

        for (int colNum = 0; colNum < colCount; colNum++)
        {
            row.Add(this.colList[colNum], new SqlDataClass(reader.GetString(colNum), reader.GetValue(colNum).GetType().ToString()));
        }

        this.rows.Add(row);
    }
    while (reader.Read());

    this.isReady = true;
}

Above code samples didn't include comments because I wanted to portray how much more readable C# layout is. Though this is not the only difference, it is one big enough for consideration when deploying something at the commercial level. If it takes 10 minutes for someone to look at a piece of code and understand what is going on and he has 20 more modules to look at before he can start fixing bugs and applying updates, then there's time lost for each module he's working on.

My next argument is speed. When programming in VB, consider that you have no definite types, things are defined at runtime, where c# uses defined types. Its like the difference between C++ and JavaScript. There is a noticeable difference in speed. Also, one thing to note with that is error handling.

When you are writing an app, the last thing you want to do is have a bug that sneaks by you and rears its ugly head at deployment or somewhere after you thought you fixed the major issues of your app. When you don't define specific types for your variables, you are in essence losing the filter that keeps bad things from happening. It is more helpful to have compile time errors rather than runtime errors. You have cleaner output and a better end product.

DIM num
num = 5
num = "Hello World" 'you just turned it into a string
num = num + 1 'what's "Hello World" + 1?
int num = 5;
num = "Hello World"; //compile time error, not a bug that will pass you by
num = num + 1;

The above was a very simplistic example, which hopefully noone has done, but the concept still stands. If you edit the variable later on down in the code and aren't super careful, it can slip by, have its type changed, and suddenly, you have a runtime error...

Also, given the above example, strict-types ensures that you do not develop into a "lazy programmer" and that you don't develop "lazy" habits. Lazy habits produce code that is hard to maintain, read, and eventually hit a brick wall.

I hope that I was able to supply enough information to aid in your business decision.

---------------------------
Nate VanBuskirk
C#, C++, Asp.Net Developer
http://seriussoft.com

commented: Awesome post +9

As far as the C# language's prettiness goes, dudeserius's post gives a poor example. Lots of well-written C# is much prettier and much more readable than that. He's working with a particularly poor API in that example.

It is always good not to be tied to just the Microsoft platform. Rather than C# I would rather pick up Java. Once you are familiar with Java, C# will be easy to add.

Your post is extremely stupid for several reasons. First, nobody got hurt because they are good at a language which works on the Microsoft platform. Microsoft will die much slower than it takes to learn some other language, and that doesn't mean the .NET platform would die too.

Second, Java doesn't even have closures, and therefore Java programmers generally hate their lives more than equivalent C# programmers.

Above code samples didn't include comments because I wanted to portray how much more readable C# layout is. Though this is not the only difference, it is one big enough for consideration when deploying something at the commercial level. If it takes 10 minutes for someone to look at a piece of code and understand what is going on and he has 20 more modules to look at before he can start fixing bugs and applying updates, then there's time lost for each module he's working on.

Readability is subjective, small procedures might seem more readable in C#, but I am certainly glad to see End If, Next, Loop and End Sub rather that }, }, }, or } at the bottom of said block. Prevents me from having to scroll up to figure out which block this bracket belongs to. For me, VB is MUCH more readable (it was designed to be more verbose than C# to begin with, which is a good thing for maintainability). It might take YOU 10 minutes to read VB code, but personally working with both languages I see no difference in time between the two. One is more verbose, the other is less verbose and more cryptic. The end.

My next argument is speed. When programming in VB, consider that you have no definite types, things are defined at runtime, where c# uses defined types. Its like the difference between C++ and JavaScript. There is a noticeable difference in speed. Also, one thing to note with that is error handling.
When you are writing an app, the last thing you want to do is have a bug that sneaks by you and rears its ugly head at deployment or somewhere after you thought you fixed the major issues of your app. When you don't define specific types for your variables, you are in essence losing the filter that keeps bad things from happening. It is more helpful to have compile time errors rather than runtime errors. You have cleaner output and a better end product.

This entire paragraph is rubbish. There is absolutely no difference in execution speed between the two languages, they both use the same functions from the same framework, they just have different syntax.

foreach (DataRow row in reader.GetSchemaTable().Rows)

is EXACTLY the same MSIL as

For Each row As DataRow In Reader.GetSchemaTable().Rows

Type inference is a shortcut, to reduce verbosity a little. It makes no difference on the output MSIL, it only reduces keypresses, and is available in both VB and C#. Also you cannot "change" the type of a variable. The variable is what it is, if you decide to explicitely cast it to some other type, that it your decision. Exactly the same with errors, if you write bad code, you will get exceptions, no matter which language you work in.

The ignorance showed here really shows how much of a bad programmer you are, not how C# is better than VB.NET (it isn't; in fact with all things being equal VB has a little bit of an edge over C# hinging on IDE features mostly...)

Prevents me from having to scroll up to figure out which block this bracket belongs to.

Unless you're on a painfully small resolution monitor, you might consider that your blocks are too large. ;) Also note that most code editors these days will highlight the opening and closing braces.

That said, both languages are reasonably pleasant to work with, so it really does come down to personal preference as to which is "better".

I think finding a 4 year old post and berating the poster (who also hasn't log on in 4 years) shows what a bad forum user you are :)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.