To VB or not to VB?

**Patrice** · Jan 5 '06, 02:25 PM

Re: To VB or not to VB?

What existing code base and/or skills do you have in your shop ?

As a side note VB.NET is OO though it provides constructs (such as modules)
that are likely here to ease porting from earlier versions, I'm not English
but "shared" seems more meaningfull to me than "static".

He forgot to mention "just becuase I prefer C#" which would be IMO more
honest and professional et this poitn of argumentation. Finally keep in mind
that for .NET the language is just the "glue".

You should find more comprehensive discussions (for example VB.NET better
for late binding, C# better for unsafe code) by Googling...

--
Patrice

<zacks@construc tion-imaging.com> a écrit dans le message de
news:1136469922 .817285.39500@g 43g2000cwa.goog legroups.com...[color=blue]
> A co-worker where I work is proposing all future code devopment be done
> in Visual C#. Here is his assessment of VB:
>
> VB.NET is hack as far as the CLR(Common Language Runtime) goes. It was
> retrofited into the .Net framework for those people who simply don't,
> and do not care to, understand object oriented programming. Quite a
> few of it's (features) were forced into the language through very ugly
> means to make it easier for the VB guys to bring in their code. Things
> like "static" veriables and functions are called "shared" in VB.NET,
> because the keyword static was already used in VB6. VB.NET is loaded
> with these kinds of little idiocies.
>
> Any comment?
>[/color]

**Joseph Ferris** · Jan 5 '06, 02:45 PM

Re: To VB or not to VB?

VB.Net is a hack then, in much the same way that C# is an attempt by
Microsoft to make language solely intent on attracting Java developers
and selling a concept to early adopters who jump on buzzwords faster
than Steve Ballmer can throw a chair accross a room.

In all seriousness, though, the assessment provided by your coworker
sounds like it is based on little more than personal preference.
Personally, I use and like both. What I use is usually at the request
of a client. Currently, I am working in a full time permanent position
where we primarily use VB.Net, although I am about to start another
part time contract in C#. Both have their pros and cons. But, here
are some reasons why I think VB.Net is better than C# in certain
regards...

It is a lot easier to wire events in VB.Net than it is to set up
delegates in C#.

More advanced Catch syntax. Catch ... When is one of the coolest
things since sliced bread. Seriously. ;-)

C# is way too cast heavy.

C# has a larger following of elitist snobs, which we don't need in the
industry. ;-)

Joseph

**zacks@construction-imaging.com** · Jan 5 '06, 03:05 PM

Re: To VB or not to VB?

Virtually all of our existing code is in VB6, recent code in VB.NET
with a smattering of C#.

Yes, it is obvious that this co-worker prefers C#.

**Christian Blackburn** · Jan 5 '06, 03:25 PM

Re: To VB or not to VB?

Hi Z,
How about VB is known for being having the most programmers and easiest
most english like syntax of any major programming language. You can
actually show a lot of VB code to a non-programmer and they'll
understand some or all of it if they give it a fair try. If he's your
only programmer and you guys want to keep him and aren't willing to
teach him a better language then I think C# is a fine way to go. As
the years progress the largest talent pool will be more and more VB
only, so that should be considered. VB is clearly the new C++ on the
block.
Cheers,
Christian Blackburn

**Joergen Bech** · Jan 5 '06, 03:35 PM

Re: To VB or not to VB?

VB.Net-programming is more vb.NET than VB.net, no matter how
much the programmer loves the functions in the Microsoft.Visua lBasic
namespace as well as the rest of the syntax that was ported from
classic VB.

Most of the time you are using portions of the .Net framework that
have nothing to do with VB anyway. The rest is just syntax.

VB has advantages over C# as well as the other way around.

Does your co-worker like curly braces? Are C#-programmers paid
better? If working with Managed DirectX, go for C#. If writing lots
of COM InterOp code, go for C#. If working with automation, go
for VB. If ...

In the "early" days of VB, it was suggested that VB6 programmers
use C# rather than VB.Net so as not to be confused by the differences
between the languages (16 vs 32-bit Integer, etc) when switching
back and forth. I come from a classic VB background and this was
no issue for me. I moved to VB.Net and such issues never affected
me.

I feel I am more productive using VB.Net and cannot think of many
instances where I would want to use C#. Only when programming
in a problem domain where most of the available documentation and
samples were made for C# do I feel that I bet on the wrong horse.

That feeling usually passes as quickly as it came.

If you are writing new VB.Net code, you can pretty much avoid
most of the "retrofitte d hacks" that were introduced to entice VB6-
developers to switch. And no, I am not talking about the recent
"Rnd vs Random" discussion, but something like "On Error ...".

VB.Net is good. C# is good. There is something called "J#.Net" on
my system. That, on the other hand, I don't know anything about,
so that is probably bad :)

Google:

VB .NET or C# – The Rematch | Dan Appleman - Kibitzing and Commentary

http://www.danappleman.com/index.php?p=27

http://www.codinghorror.com/blog/archives/000128.html

Page Not Found - DotNet 24/7

http://www.dotnet247.com/247reference/msgs/15/78183.aspx

....etc.

Question: I would like to have something like the C# "unsafe"
keyword. Is there an equivalent in VB2005?

/Joergen Bech

On 5 Jan 2006 06:05:22 -0800, zacks@construct ion-imaging.com wrote:
[color=blue]
>A co-worker where I work is proposing all future code devopment be done
>in Visual C#. Here is his assessment of VB:
>
>VB.NET is hack as far as the CLR(Common Language Runtime) goes. It was
>retrofited into the .Net framework for those people who simply don't,
>and do not care to, understand object oriented programming. Quite a
>few of it's (features) were forced into the language through very ugly
>means to make it easier for the VB guys to bring in their code. Things
>like "static" veriables and functions are called "shared" in VB.NET,
>because the keyword static was already used in VB6. VB.NET is loaded
>with these kinds of little idiocies.
>
>Any comment?[/color]

**m.posseth** · Jan 5 '06, 03:45 PM

Re: To VB or not to VB?

You took the words right out of my mouth ;-)

however i have this to add

Anyone who says that one of the languages is more powerfull in the terms of
VB6 vs C++ does not know what he is talking about

I use both C# and VB and just love VB more as Basic is my native tongue :-)
in my opinion VB has one main advantage above C# and that is that it is more
friendlier and thus faster to program with

regards

Michel Posseth [MCP]

"Joseph Ferris" <joseph.ferris@ gmail.com> wrote in message
news:1136471676 .032820.9970@g4 4g2000cwa.googl egroups.com...[color=blue]
> VB.Net is a hack then, in much the same way that C# is an attempt by
> Microsoft to make language solely intent on attracting Java developers
> and selling a concept to early adopters who jump on buzzwords faster
> than Steve Ballmer can throw a chair accross a room.
>
> In all seriousness, though, the assessment provided by your coworker
> sounds like it is based on little more than personal preference.
> Personally, I use and like both. What I use is usually at the request
> of a client. Currently, I am working in a full time permanent position
> where we primarily use VB.Net, although I am about to start another
> part time contract in C#. Both have their pros and cons. But, here
> are some reasons why I think VB.Net is better than C# in certain
> regards...
>
> It is a lot easier to wire events in VB.Net than it is to set up
> delegates in C#.
>
> More advanced Catch syntax. Catch ... When is one of the coolest
> things since sliced bread. Seriously. ;-)
>
> C# is way too cast heavy.
>
> C# has a larger following of elitist snobs, which we don't need in the
> industry. ;-)
>
> Joseph
>[/color]

**Marina** · Jan 5 '06, 04:35 PM

Re: To VB or not to VB?

I think saying that VB was retrofitted to fit into the .NET framework is a
fair point, and so it that a lot of the syntax is clumsy and awkward because
of that. I personally agree with that.

However, as far as every day programming, you will find that VB and C# are
really the same thing. So you use a curly brace here versus an 'End If'
there. So what? Translating from one to the other is trivial in almost all
cases.

If anyone doesn't care or understand OO programming, they are going to have
an equally big problem with both languages. A lot of VB6 programmers come to
VB.NET figuring it's really mostly the same - which it is not. And that's
where the problems come in, because they don't really understand what's
going on, and don't take the time to.

It all comes down to preference and what you are used to working with. The
power is all in the .NET framework, it doesn't matter which language you use
to get your work done.

In any case, if you do a search on Google groups, you will find a bazillion
posts of C# vs VB.

<zacks@construc tion-imaging.com> wrote in message
news:1136469922 .817285.39500@g 43g2000cwa.goog legroups.com...[color=blue]
>A co-worker where I work is proposing all future code devopment be done
> in Visual C#. Here is his assessment of VB:
>
> VB.NET is hack as far as the CLR(Common Language Runtime) goes. It was
> retrofited into the .Net framework for those people who simply don't,
> and do not care to, understand object oriented programming. Quite a
> few of it's (features) were forced into the language through very ugly
> means to make it easier for the VB guys to bring in their code. Things
> like "static" veriables and functions are called "shared" in VB.NET,
> because the keyword static was already used in VB6. VB.NET is loaded
> with these kinds of little idiocies.
>
> Any comment?
>[/color]

**Herfried K. Wagner [MVP]** · Jan 5 '06, 05:25 PM

Re: To VB or not to VB?

<zacks@construc tion-imaging.com> schrieb:[color=blue]
>A co-worker where I work is proposing all future code devopment be done
> in Visual C#. Here is his assessment of VB:
>
> VB.NET is hack as far as the CLR(Common Language Runtime) goes. It was
> retrofited into the .Net framework for those people who simply don't,
> and do not care to, understand object oriented programming. Quite a
> few of it's (features) were forced into the language through very ugly
> means to make it easier for the VB guys to bring in their code. Things
> like "static" veriables and functions are called "shared" in VB.NET,
> because the keyword static was already used in VB6. VB.NET is loaded
> with these kinds of little idiocies.[/color]

It's obvious that your co-worker is totally cueless.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

**Herfried K. Wagner [MVP]** · Jan 5 '06, 06:05 PM

Re: To VB or not to VB?

"Joergen Bech @ post1.tele.dk>" <jbech<NOSPAMNO SPAM> schrieb:[color=blue]
> In the "early" days of VB, it was suggested that VB6 programmers
> use C# rather than VB.Net so as not to be confused by the differences
> between the languages (16 vs 32-bit Integer, etc) when switching
> back and forth. I come from a classic VB background and this was
> no issue for me. I moved to VB.Net and such issues never affected
> me.[/color]

ACK. Maybe this has been caused by the strong marketing of .NET in
conjunction with the C# programming language, mainly to attract Java
developers which have not already been Microsoft customers. VB programmers
on the other hand already used a Microsoft tool and thus it was not as
important to market VB.NET than it was for C#.
[color=blue]
> I feel I am more productive using VB.Net and cannot think of many
> instances where I would want to use C#. Only when programming
> in a problem domain where most of the available documentation and
> samples were made for C# do I feel that I bet on the wrong horse.[/color]

Yep, same here.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

**tomb** · Jan 5 '06, 06:15 PM

Re: To VB or not to VB?

I remember the days when C++ programmers looked down their noses at VB
programmers. Back then, C++ was an incredibly powerful, versatile, and
close-to-the-machine way of programming. The C++ programmers thought
they were superior, when in fact, only the tool was superior. It was a
really arrogant stance VB programmers still had to be able to figure
out what to do, which is the hardest part, and write good code, which is
the next hardest part. The major difference was in the compiler and
function libraries, and those were the real reason VB lagged behind in
performance. But anyone who was honest about it would admit that C++
was more powerful, but VB was faster for developing the User Interface.

With the introduction of .net, those major differences are pretty much
obliterated. The speed and power of C# vs VB are practically identical,
and as pointed out in several other posts, it's really a matter of
syntax preference. I like VB, and I like C#. I also like FoxPro, and
PHP, and Smalltalk, and Java, and Delphi. The real benefit of
developing in .net is you can mingle C# projects with VB projects in the
same solution. And, as Joergen pointed out, there may be the time when
one is better suited to a particular task. But to say any development
tool is the best one to use in all situations only indicates ignorance,
and I would be wary about any advice from that person.

So, if your coworker prefers to develop in C#, so be it. Let him. And
you do yours in VB.

Tom

zacks@construct ion-imaging.com wrote:
[color=blue]
>A co-worker where I work is proposing all future code devopment be done
>in Visual C#. Here is his assessment of VB:
>
>VB.NET is hack as far as the CLR(Common Language Runtime) goes. It was
>retrofited into the .Net framework for those people who simply don't,
>and do not care to, understand object oriented programming. Quite a
>few of it's (features) were forced into the language through very ugly
>means to make it easier for the VB guys to bring in their code. Things
>like "static" veriables and functions are called "shared" in VB.NET,
>because the keyword static was already used in VB6. VB.NET is loaded
>with these kinds of little idiocies.
>
>Any comment?
>
>
>[/color]

**Brad Rogers** · Jan 5 '06, 06:35 PM

Re: To VB or not to VB?

Zack, you should consider firing your co worker for incompetence, thats my
first comment. Anyone who would say such a ludicrous thing is not rational
or is very dishonest. Whats probably going on is your co worker cannot
comprehend vb.net and wants to play a poker style "bluff" on everyone to
hide his/her incompetence. OH, vb.net is stupid, it doesnt work... when in
fact its so complicated everyone would find out his/her lack of ability by
not being able to "cope" or "keep up".

Their only shred of hope now is to disparage vb.net and make baseless
accusations. Have the person move to facilities maintenance or landscaping
and get someone interested in software development to take their place.
Well again, it depends on whether or not your company is in business to
succeed and take things seriously?

Please share my comments with him/her.

<zacks@construc tion-imaging.com> wrote in message
news:1136469922 .817285.39500@g 43g2000cwa.goog legroups.com...[color=blue]
> A co-worker where I work is proposing all future code devopment be done
> in Visual C#. Here is his assessment of VB:
>
> VB.NET is hack as far as the CLR(Common Language Runtime) goes. It was
> retrofited into the .Net framework for those people who simply don't,
> and do not care to, understand object oriented programming. Quite a
> few of it's (features) were forced into the language through very ugly
> means to make it easier for the VB guys to bring in their code. Things
> like "static" veriables and functions are called "shared" in VB.NET,
> because the keyword static was already used in VB6. VB.NET is loaded
> with these kinds of little idiocies.
>
> Any comment?
>[/color]

**Joseph Ferris** · Jan 5 '06, 08:05 PM

Re: To VB or not to VB?

Brad Rogers wrote:
[color=blue]
> Please share my comments with him/her.[/color]

For the sheer entertainment value, maybe he/she should be invited here
for a "group discussion"? ;-)

Joseph

**Matthew.Gertz@feedback.microsoft.com** · Jan 5 '06, 11:55 PM

Re: To VB or not to VB?

Nice comments, all, and I appreciate them. I may regret leaping into this :-), but just some comments of my own:

"Retrofitti ng" makes it sound like we took the VB6 code and starting adding hooks to make it work with .NET. In actuality, not a single line of code from VB6 made it into VB .NET -- zip, zero, nada. It was entirely built from scratch. That is of course the reason why things like EnC, etc., were initially missing -- attempting to rewrite ~10 years of VB code in 3.5 years against an entirely new set of APIs was quite challenging. Of course, we wanted to make it as VB6-like as possible where *general* syntax was concerned -- hence the retention of certain odd syntax constructs like OnError as such which were just too hard to map into Try/Catch in most cases on migration -- and so those all got built in. Occasionally, the goal of matching functionality could be very tricky when weighing other directions we wanted to go, like having to retain comparison operators which didn't short-circuit, or retaining typeless coding via late-binding. But, on the other hand, it was a great opportunity to clean up what I personally viewed as problems with VB6 syntax, such as trying to remember when to use parentheses with arguments on calls to subroutines and functions, odd constructs like GoSub, and irrelevant legacies like Let/Set and so forth.

It's my hope (and belief) that VB .NET stands as a language in its own right, both as compared with VB6 and C#, and is not just some weird fusion of VB6 and .NET. But, that's for y'all to decide, I expect... :-)

--Matt Gertz--*
VB Compiler Dev Lead

-----Original Message-----
From: Marina
Posted At: Thursday, January 05, 2006 8:22 AM
Posted To: microsoft.publi c.dotnet.langua ges.vb
Conversation: To VB or not to VB?
Subject: Re: To VB or not to VB?

I think saying that VB was retrofitted to fit into the .NET framework is a
fair point, and so it that a lot of the syntax is clumsy and awkward because
of that. I personally agree with that.

However, as far as every day programming, you will find that VB and C# are
really the same thing. So you use a curly brace here versus an 'End If'
there. So what? Translating from one to the other is trivial in almost all
cases.

If anyone doesn't care or understand OO programming, they are going to have
an equally big problem with both languages. A lot of VB6 programmers come to
VB.NET figuring it's really mostly the same - which it is not. And that's
where the problems come in, because they don't really understand what's
going on, and don't take the time to.

It all comes down to preference and what you are used to working with. The
power is all in the .NET framework, it doesn't matter which language you use
to get your work done.

In any case, if you do a search on Google groups, you will find a bazillion
posts of C# vs VB.

<zacks@construc tion-imaging.com> wrote in message
news:1136469922 .817285.39500@g 43g2000cwa.goog legroups.com...[color=blue]
>A co-worker where I work is proposing all future code devopment be done
> in Visual C#. Here is his assessment of VB:
>
> VB.NET is hack as far as the CLR(Common Language Runtime) goes. It was
> retrofited into the .Net framework for those people who simply don't,
> and do not care to, understand object oriented programming. Quite a
> few of it's (features) were forced into the language through very ugly
> means to make it easier for the VB guys to bring in their code. Things
> like "static" veriables and functions are called "shared" in VB.NET,
> because the keyword static was already used in VB6. VB.NET is loaded
> with these kinds of little idiocies.
>
> Any comment?
>[/color]

**_AnonCoward** · Jan 6 '06, 06:55 AM

Re: To VB or not to VB?

<zacks@construc tion-imaging.com> wrote in message
news:1136469922 .817285.39500@g 43g2000cwa.goog legroups.com...
:
: A co-worker where I work is proposing all future code devopment be
: done in Visual C#. Here is his assessment of VB:
:
: VB.NET is hack as far as the CLR(Common Language Runtime) goes. It was
: retrofited into the .Net framework for those people who simply don't,
: and do not care to, understand object oriented programming.

That's just pure ignorance speaking. VB.net was at least in part a response
to the VB community to make the language truly object oriented. There were
already OO like aspects in VB6 (properties, Public/Private/Friend functions,
Interface implementation, etc.) but it was sorely lacking. Now, VB
programmers have a full fledged OO language on a direct par with C# and
Java. To say the VB was created just to satisfy programmers who don't
understand OOP is simply wrong. Your co-worker literally doesn't know what
he's (she's?) talking about here.

: Quite a few of it's (features) were forced into the language through very
: ugly means to make it easier for the VB guys to bring in their code.

Of course MS wanted to make the new version of VB compatible with VB6 -
there are a lot of very good VB programmers out there and it would have been
foolish for MS to have ignored them when rolling out the .net framework.
Porting over existing VB6 programs into VB.net is generally speaking not a
trivial matter. The language serves more to allow the programmers to
leverage their existing language skills rather than force them to learn a
new language, wasting time and effort. Odds are in that case, the VB
community would have had little or nothing to do with .net as a result.
Quite frankly, .net would likely not have been nearly as successful it has
been if MS hadn't made it realistic for VB coders to move into the framework
with most of the syntax intact.

And by what standard does your co-worked define "ugly"? Which is uglier:

Option Strict
Imports System

Public Class [class]
Public Shared Sub Main(Args() As String)
For Index As Integer = 0 To 100
Console.WriteLi ne(Index)
Next
End Sub
End Class

or

using System;

public class Class {
public static void Main(String[] args){
for(int Index = 0; Index <= 100; Index++){
Console.WriteLi ne(Index);
}
}
}

Or how about this:

If var1 = 1 Then
For Index = 0 to 10
If var2 = Index Then
DoThis
Else
Select Case var3
Case "A"
DoThisToo
Case "B"
DoThisInstead
End Select
End If
Next
End If

compared to:

if(var1 == 1){
for(Index = 0; Index < 11; Index++){
if(var2 == Index){
DoThis();
}else{
switch(var3){
case "A":
DoThisToo();
break;
case "B":
DoThisInstead() ;
break;
}
}
}
}

I personally like the VB examples as being cleaner and easier to read - the
curly braces in particular can be very confusing when you have deeply nested
logic. VB isn't without its difficulties in this respect, but at least you
can more quickly know if you're looking at the close of an IF-THEN block or
a SELECT-CASE block. But of course that is a purely subjective opinion based
on years of experience with VB versus C or its derivatives. C++ or Java
programmers would likely prefer the C# examples.

Further, the VB compiler is tolerant of the occasional wrong use of case
(e.g.: for Index as integer = 0 to 100 complies without issue, just as it
should). Sometimes, knocking out some quick code as a test is helpful. You
can dispense with worrying about caps in VB - but C# (and C/C++ and Java)
throw a fit if you type Console.WriteLI ne instead of Console.WriteLi ne - how
ridiculous is that?

Another problem with case sensitivity is that it can lead to the
introduction of hard to find bugs. For example, say you have two variables
myVar and myvar in a C# function. It is easy to accidentally type myvar when
you meant myVar (and vice versa) and locating the inappropriate variable
name can waste time that a VB coder doesn't have to worry about. (And let's
not even discuss how many times using = instead of == in logical compares
causes hours of wasted man hours trying to figure out why a function isn't
working correctly...)

: Things like "static" veriables and functions are called "shared"
: in VB.NET, because the keyword static was already used in VB6.
: VB.NET is loaded with these kinds of little idiocies.

Well, yeah - the Static keyword *was* already part of the language when
VB.net was introduced. Why on earth should MS have changed that? Secondly,
declaring a function or property (or what have you) as "Shared" is actually
more meaningful than "Static". Declaring a member variable as "Shared" means
it is 'shared' by all instances of the class - any changes to the variable
in one instance are visible to all others instances. This is clearer than
saying it is "static" which implies that it never changes.

When all is said and done, VB.net and C# are just languages - each do pretty
much the same things. Both languages bring strengths and weaknesses to the
table and neither is inherently better than the other - it usually comes
down to personal preference as to which language is used.

Frankly, it sounds like your co-worker is a language bigot. It's one thing
to say he/she prefers C# over VB for whatever reason - it's a totally
different thing to suggest that VB coders and VB code are somehow inherently
inferior. I've seen plenty of poor programming by VB, C++ and Java
programmers over the years (and well paid programmers at that) and I've
learned that it is never the language that is at fault; it is *always* the
programmer. Poor programmers produce poor programs, bottom line.

In the final analysis if your company or team chooses the C# route over the
VB route, that will do just fine. However, in my opinion I think you'll find
VB programmers will have a slight edge because VB's syntax is easier to read
and debug than C# - but that's just my own bias showing now.

Ralf
--
--
----------------------------------------------------------
* ^~^ ^~^ *
* _ {~ ~} {~ ~} _ *
* /_``>*< >*<''_\ *
* (\--_)++) (++(_--/) *
----------------------------------------------------------
There are no advanced students in Aikido - there are only
competent beginners. There are no advanced techniques -
only the correct application of basic principles.