VB vs C#

[Rena]

Hi all,

I really would like to know the managment of MS, will put more effort on
either VB or C#, because I believe there are not fair balance in the world.
I used to VB 6.0, and now working on VB .Net. I wonder if MS will now shift
most of their effort from VB to C#, or would like to retain them
in order to keep it as competive as they were during vb 5.0, 6.0 ages...

I donot wanna know it too late..... really hope some internal staff can
share their idea, thought and direction about it.

thx a lot,
Rena.

 

[Patrice]

Not an internal team but from what I've heard and seen so far they evolve
both.

Try :
http://msdn.microsoft.com/vbasic/wh...brary/en-us/dnvs05/html/vbnet2005_preview.asp
for Visual Basic 2005 enhancements...

In some cases they tend to favor C# in code samples (such as in the DirectX
SDK AFAIK) but on the other hand VB.NET could be favored in applications
such as Office as a replacement for VBA...

Patrice

 

[Peter van der Goes]

Hi all,

I really would like to know the managment of MS, will put more effort
on
either VB or C#, because I believe there are not fair balance in the
world.
I used to VB 6.0, and now working on VB .Net. I wonder if MS will now
shift
most of their effort from VB to C#, or would like to retain them
in order to keep it as competive as they were during vb 5.0, 6.0 ages...

I donot wanna know it too late..... really hope some internal staff can
share their idea, thought and direction about it.

thx a lot,
Rena.

I'm sure you'll get lots of opinions here in a public newsgroup, but I
really doubt that you'll get anything definitive from a Microsoft
representative. There are probably thousands of reasons why, but I'll throw
one out: Nondisclosure Agreements.
I, however, have a question for you. As the largest part of the learning
curve is not a given language, but .NET itself, why would this worry you? By
using VB.NET, you're learning the framework and that knowledge is applicable
to any language supported by .NET.
Start studying C# (and maybe C++ as well) now, just to become more
versatile, and you'll be covered for any future situation.
Just my $.02 worth...

 

[Rena]

Hi Patrice,
Yup, "tend to favor C# in code samples " that's also what i saw. And
although they keep to saying that choosing VB / C# are the same, as they are
compatable year before.
There are things C# can do but VB don't and visa versa. Really don't know
what MS / Bill's are thinking............

Rena.

 

[Rena]

Hi Peter,
Thx for your sharing.
it is possible if u are managing a team to know both VB / C#, but not as
productive / indepth as having a team know either one given
the same among of time right? If .net really is a framework that can
function 100% the same between VB & C#, I won't worry about
which one go for....or even ignore it. So it is not meaningless to decide
which to go b4 too late.
Framework, support, new component / template will affect the productivities,
and what i worry is that whether MS will bias either VB
or C#...as I can see when C# first come, lot of effort are given on it.

Rena.

 

[Patrice]

You'll notice that in most cases features unique to a .NET language are
largely based IMO on "tradition" (ie easy late bouding in VB.NET, pointers
in C# etc...). Anyway this is the just the "glue" for the Framework.
Ultimately they both compile to the same MSIL language and overall they are
quite similar...

I even wonder if you won't be able to mix them in a single project in
VS.NET 2005 (and it could perhaps be possible now with the command line
compiler ?). Also keep in mind that IMO your investment is not really in the
language you use but rather in what you make it do (and now you make them do
things in a very similar manner as they are both using the same class
library).

Frankly I wouldn't worry much about this until quantic computing or whatever
the next best thing comes out....

Pick just the one you are most comfortable with. Get familiar with the other
one and you should pretty much cover it...

Patrice

--

 

[Gerry Hickman]

I really would like to know the managment of MS, will put more effort on
either VB or C#,

I don't know what MS will do, but C# is the language of the future. It's
been rubber stamped by the ECMA, is more closely related to PERL and
JScript than VB, and can work outside the Microsoft framework.

I'm glad I chose C# three years ago because I won't need to "migrate"
for a long time!

 

[Guest]

You say "there are things C# can do but VB don't and visa versa." Quite
frankly... in terms of "doing"... I can't think of anything that one does
that the other doesn't.

Their differences are mainly in "how" you do things. VB has declarative
event handling (Private Myproc() Handles Object.Someevent), while delegates
abound in C#. VB can have loose typeing (which no good VB developer would
ever use... Option Strict should always be on), while C# has some neat GUI
tools to create Methods and Properties (which VB6 had but VB.NET strangely
doesn't!!!)

Although I like C#, I find VB is a lot more productive... mainly in the way
events are handled but also because the Microsoft.VisualBasic namespace
contains great wrappers around some really annoying non-RAD things in the
..NET. For instance doing MyStr.Substring() and specifying a value bigger than
the string results in a exception! The classic BASIC Left() function is smart
enough not to.

If you like the fact that using DateDiff() (in the VisualBasic namespace) is
one line of code while using DateSpan objects arithmatic can be several lines
of code, then VB is for you.

 

[Guest]

Aren't all those things true of Java as well? Is that "the language" of the
future?

 

[Peter van der Goes]

Hi Peter,
Thx for your sharing.
it is possible if u are managing a team to know both VB / C#, but not as
productive / indepth as having a team know either one given
the same among of time right? If .net really is a framework that can
function 100% the same between VB & C#, I won't worry about
which one go for....or even ignore it. So it is not meaningless to decide
which to go b4 too late.
Framework, support, new component / template will affect the
productivities,
and what i worry is that whether MS will bias either VB
or C#...as I can see when C# first come, lot of effort are given on it.

Rena.

My *opinion* is that targeting a development group (as you seem to indicate)
as a one language group is shortsighted and unnecessarily restrictive. As
somebody else pointed out in this thread, it's hard to point out anything VB
can do that C# cannot (or vice-versa) from a practical standpoint.
Encouraging developers to be versatile is good for them and good for the
organization for which they work.

 

[Sean Hederman]

Aren't all those things true of Java as well? Is that "the language" of
the
future?

Nope, Java is a proprietary language, whilst C# is not controlled by
Microsoft (although AFAIK they do chair the ECMA C# committee).

 

[Sean Hederman]

My *opinion* is that targeting a development group (as you seem to
indicate) as a one language group is shortsighted and unnecessarily
restrictive. As somebody else pointed out in this thread, it's hard to
point out anything VB can do that C# cannot (or vice-versa) from a
practical standpoint.
Encouraging developers to be versatile is good for them and good for the
organization for which they work.

I agree. Whilst we generally work in C#, sometimes we use VB.NET, largely
when interfacing with VB6 components. It makes dealing with things like
optional parameters *so* much easier.

 

[Sean Hederman]

You say "there are things C# can do but VB don't and visa versa." Quite
frankly... in terms of "doing"... I can't think of anything that one does
that the other doesn't.

C#: unsafe code blocks, checked/unchecked, operator overloading, using
statement, explicit interface implementation, unsigned types
VB.NET: optional parameters, named indexers, Catch/When, With statement,
implement interface members with method of different names

 

[Gerry Hickman]

Hi CMM,

Aren't all those things true of Java as well? Is that "the language" of the
future?

Absolutely! It's just the discussion seemed to be more in the context of
what's included in Microsoft's .NET

After many years of dismissing Java, it now seems I was WRONG to write
it off. Arrhhhhh!

 

[Gerry Hickman]

can do that C# cannot (or vice-versa) from a practical standpoint.
Encouraging developers to be versatile is good for them and good for the
organization for which they work.

Yes, but as we discussed earlier, it's not about making personal
choices; it's about making the RIGHT choice for the big business of
tomorrow. That means making sure you've got standards in place, and that
you choose the language which is going to get the best support from the
vendor (C# in this case), and also that the language you choose is going
to available in the job seeker pool of tomorrow.

One of the biggest problems with VB vs C# right now, is that all the
experts choose C# and all the students/beginners choose VB. If you're in
world of big bucks enterprise computing, the choice is obvious.

You only have to look back at VB, VBScript and VBA to see how it hasn't
kept pace with open standards. C++, JScript and C# have all survived the
test of time, but there's simply no point in flogging the dead VB horse.

I'm really glad I never used VB6. I chose W3C DOM and PERL/JScript
instead, and while all my VB friends are busy trying to "migrate", I'm
just sitting back and relaxing.

 

[Guest]

Great examples of some key differences... but they still fall under what I
categorized as "how." For instance, Optional Parameters can be mimicked in C#
using carefully crafted overloaded methods. What I meant by "*what* you can
do" is for example: VB6 inability to create a standard Win32 library under
any circumstance... or maybe both C# and VB.NET's inability to expose and
share SingleInstance classes from an exe (like ol' COM EXE could do... though
you can still mimic it in .NET using Remoting).

Frankly, I'm hardpressed to think of anything (end-result) I can't
accomplish in either language.

 

[Guest]

You only have to look back at VB, VBScript and VBA to see how it hasn't

kept pace with open standards. C++, JScript and C# have all survived the
test of time, but there's simply no point in flogging the dead VB horse.

I can't see how what you say is true when the majority of internal business
apps and objects are written in VB or VBA. Also, you state C# has survived
the test of time. Isn't that an overstatement? I mean, it's 4 years old.
Perhaps you meant to say that C-derived languages have survived. Again, I
would beg to differ as the most widely used languages are actually
BASIC-derived or BASIC-esque... including the major database SQL procedural
languages (T-SQL for instance).

Only time will tell which one of these two great languages (VB.NET vs. C#)
will go the way of Delphi. ;-) My bet is that both will have their place...
C# will entrench in the back-end business objects, and class libraries, and
services, and VB will remain the top choice for User Interface development.
We'll see.

 

[Guest]

Correction... I didn't mean to overstate the usage of VB or non-C
languages... I know full well that pretty much all major technologies and
platforms are written in C/C++... including the Java runtime. I was speaking
about business objects, database front-ends, office automation, etc.

 

[Guest]

Correction... I didn't mean to overstate the usage of VB or non-C
languages... I know full well that pretty much all major technologies and
platforms are written in C/C++... including the Java runtime. I was speaking
about business objects, database front-ends, office automation, etc.

 

[Guest]

Correction... I didn't mean to overstate the usage of VB or non-C
languages... I know full well that pretty much all major technologies and
platforms are written in C/C++... including the Java runtime. I was speaking
about business objects, database front-ends, office automation, etc.