Why there is perception that VB.NET is good for small to medium size application and not for enterprise class project? [closed]

Question

I love VB.NET very much. Coding VB.NET with Visual Studio is just like typing messages. Smooth, fast and simple. Any error will be notified instantly. The OO capability of VB.NET is good enough.

But often in any .Net languages discussion, there is perception that VB.NET is good for small to medium size application and not for large scale project?

Why there is such perception? Or am I missing anything regarding to VB.NET?

Answer 1

Back in the early 90's the PC was primarily used as an emulation terminal, Excel host and Email client. So when we wrote desktop applications they were usually small departmental applications. The development tool of choice was VB because it abstracted away a LOT of the pain known as Windows API development. We could create applications in hours that would take a C++ program days. This earned VB a reputation as being a toy that was fine for creating small business applications.

Then in the late 90's the development paradigm was shifting because of Java. Suddenly it was cool to write applications using Object Oriented techniques. People like Grady Booch were becoming household names. While VB could support some OO concepts it just wasn't a good fit. So now VB programers were starting to be viewed as those non-OO programmers (ergo non Enterprise App programes).

Also the server was doing more than hosting batch applications and RDBMS systems. There were software component being dropped on the servers that could be used by Web or Desktop clients. The VB legion shifted to writing COM components that were used by ASP and MTS. Well this didn't improve VB's reputation as a solid programming language.

So by the time MSFT introduced .Net in 2000 the VB camp was ready to shed the stigmatism of being associated with VB. Here was this exciting language, C# that had great support of OO concepts and still felt productive. So VB was no longer seen as cool.

So this stereo-type is still around today because most of todays Sr. Managers grew up in IT while all this was happening. They remember VB as that rowdy kid that really made people at the departement level sing, but made the system admins scream. So VB will probably never be seen as a good language for building Enterprise applications (even though we know that it is just not true).

Answer 2

This belief is a hold over from vb6 days. Many large enterprises have two types of programmer ones that went to school and were brought into the origination as IT people and those that migrated to that role whilst involved in a business unit. Of those that assumed that role the vast majority that I meet were VBA excel/word/Access macro writers that solved a business need much more quickly then an IT project could/should have.

Many times their original spread sheet macro would grow to become much more then you could handle with VBA/office and a project, and would fail catastrophically. At that point the business unit would scream for help and a project would be started by IT to come up with a "real" solution. The real solution usual wouldn't be in VB and hence the perception that real projects are not done in VB.

Like I said perception. you can write good and bad applications in any language, but languages with low barriers for entry often get a bad wrap because language allows poorly written applications to actually do something. You have to think about how difficult it is to get a c program to do anything compared to a VB form app that fact alone will limit real world c applications to be written by people who have taken more time to understand what there language does. In its modern form VB is totally acceptable for large scale projects.

Answer 3

Technically there is little difference whether you use VB.NET or C#. Therefore the notion you mention must come from somewhere else.

Most likely it has something to do with human resources. Finding VB.NET programmers is getting more challenging as they are migrating to C#. Some people might see it as an inconvenience when a large enterprise project becomes dependent on being able to find good and capable VB.NET programmers.

It is also generally seen that the average level of C# programmers is higher than that of VB.NET programmers. VB.NET programmers often have the Visual Basic programming background which had long shaped their mindset while C# programmers often come from C++ background which is more challenging. Naturally you want smarter programmers for a large project. But these are just the statistics, they do not necessarily apply to each and every case.

Other than that I can think of no other reason right now.

Answer 4

Short answer:

Because there are famous developers keep spreading inaccurate facts regarding to VB.NET and C#. By providing false positive for C# and thus makes VB.NET as relatively inferior .Net language for big projects.

There are 2 interesting articles:

Why C# Is(n't) Better Than VB.NET

people continue to spread the myth that C# is superior basically because it has the letter C at beginning of the name usually at the cost of the VB Classic developer

Top 10 reasons C# is better than VB.NET

C# is better because:

VB.NET doesn't have Increments/Decrements e.g. a++;a--

Comments in C# are just better. You can do multiline comments

Answer 5

One reason for the belief centers on typing. VB.NET by default is dynamically typed. People who come from strictly typed languages believe that type checks are very important for larger projects, and frequently look down on dynamically typed languages. VB can be made strictly typed with Option Strict, but I suspect that many people don't know that.

Answer 6

When I hear that VB is only good for small scale projects I think about the old days when basic was considered a language for learning how to program and not a language to develop real world applications. I really see no reason why VB.NET cannot be used for enterprise scale development. From my int of view it has all the power required for the task.

Answer 7

Visual Basic .Net is the fruit of many years of experiences, which are gained from assembly, c, c++, etc. Therefor it has all the capabilities of the aforementioned programing languages, and can solve virtually any programing problem.

Answer 8

I think its because of physical code size due to syntax.

I use both at work, and c# is definitely more compact, which makes it quicker and easier to read.

So here are some generic examples:

Dim i as Integer ' vb

int i; // c#

For very large projects, vb code will be several times larger than c# code, just because it is more verbose.

My biggest gripe with vb is this:

var x = isTrue ? notNullValue : nullValue; // c#

Dim x as MyObject = Iif(isTrue, notNullValue, nullValue) ' vb & fails

this is becuase iif is older, although it has been replaced by the following

Dim x as MyObject = If(isTrue, nutNullValue, nullValue) ' vb

there is more:

// C# switch
select (x) { 
    case AWESOME_ENUM_A:
    case AWESOME_ENUM_B:
    case AWESOME_ENUM_C:
    case AWESOME_ENUM_D:
    case AWESOME_ENUM_E:
    case AWESOME_ENUM_F:        
       break;
    default:
}

' vb switch
select x
   case AWESOME_ENUM_A, _
        AWESOME_ENUM_B, _
        AWESOME_ENUM_C, _
        AWESOME_ENUM_D, _
        AWESOME_ENUM_E, _
        AWESOME_ENUM_F:

   case else:

end select

very often i see vb code exceed 100 columns, since not many vb coders break up their long lines.

so you will see the following more:

' vb switch - more commonly found in code
select x
   case AWESOME_ENUM_A, AWESOME_ENUM_B, AWESOME_ENUM_C, AWESOME_ENUM_D, AWESOME_ENUM_E, AWESOME_ENUM_F:

   case else:

end select

And another person brought up commenting: (this can be ignored since the ide helps you with them)

/*
    Hello
    Comment
*/

'
'   Hello
'   Comment
'

The biggest advantage is lambda and LINQ, vb syntax is horrible with it.

(x,y) => x + y; // c#

Function(x,y) x+y 'vb

// C# linq
var ret = from x in db
          where x < y
          select x;

' vb linq
Dim ret = From x In db _
          Where x < y _
          Select x

The c# versions are easier to read and type

The only advantage that vb has over c# is the following:

' vb with, only thing awesome about vb syntax
With someReallyLongNameVariable.Property.Nested
   .a = someValue1
   .b = someValue2
   .c = someValue3
End With

// c# aww
someReallyLongNameVariable.Property.Nested.a = someValue1
someReallyLongNameVariable.Property.Nested.b = somevalue2
someReallyLongNameVariable.Property.Nested.c = someValue3

// but you can always to this, although it sort of breaks readability
var n = someReallyLongNameVariable.Property.Nested;
n.a = someValue1;
n.b = someValue2;
n.c = someValue3;