The Demise of C#

[Kevin Spencer]

About 2 years ago, and as recently as perhaps 1 year ago, I can recall
seeing many posts about what language to use with ASP.Net. The consensus was
that employers paid more for C# programmers, and it seems that C# became the
darling of the ASP.Net crowd.

In the meantime, I have observed an interesting phenomenon. Originally,
employers hired programmers who used C# because it was based on C, and the
prevailing opinion was (and may still be) that C# developers were better
because they must have known and/or practiced C or C++ at some time, which
would make them better programmers overall. C and C++ are hard-core
programming languages compared to VB.

However, now that nearly everyone has jumped on the C# bandwagon, it seems
to me that the distinction between the languages has nearly disappeared, at
least in terms of evaluating programmers for hire. There seem to be almost
as many clueless C# developers out there as VB.Net developers. Many C#
developers today are basically VB.Net developers using a different syntax. I
wonder if the employers have become aware of this trend?

--

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

[Martin Dechev]

Hi,

"Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> wrote in message
news:Ov******** ******@TK2MSFTN GP15.phx.gbl...

There are a few things that C# can do that VB.NET can't, and there are
things that VB.Net does that C# can't do without added in a bunch of
VB.NET
references.
I'm afraid that's just not true. The only things that C# can't do without

a bunch of VB.Net References is use the Microsoft.Visua lBasic NameSpace. This doesn't mean that you can't do those things with C#. In fact, the
Microsoft.Visua lBasic NameSpace is mostly a lot of functions that wrap
functionality in the CLR, but with the older VB syntax.

For example, take CInt(string). This is taken straight from VB syntax, but
under the covers it is calling System.Convert. ToInt32(string) . Or the
Replace() method in VB.Net, which is a wrapper for System.String.R eplace().
On the other hand, you can't use unmanaged code in VB.Net. Now, many people might think that this is a small thing, but it certainly is not for myself. I have written a number of classes and utilities that work with images
(LARGE images), and use unmanaged code and pointers to work with the pixels of the images. Without unmanaged code and pointers, these apps would
function extremely slowly. I find it impossible to believe that I'm the only developer who has this sort of need.
You're not the only one.

Another thing that comes to my mind is when I had to make a really
performant calculations with arrays of integers and I didn't want to write
it in C++ (I'm lazy). The crucial part was allocating the arrays on the
stack using stackalloc. Just another example when one should go for C#.

So, in fact, while C# can do anything that VB.Net can, VB.Net can not do
everything that C# can.
Absolutely.

Greetings,
Martin Dechev
ASP.NET MVP

to wonder: with the technical reasons for using C# all but gone, why would new programmers choose C# (new, meaning they aren't coming from years of
C++
of java development)?
If the technical reasons for using C# were all gone, I wouldn't have

written this. I think the ability to use pointers all by itself is technical reason enough.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
What You Seek Is What You Get.

"cmay" <cm**@discussio ns.microsoft.co m> wrote in message
news:63******** *************** ***********@mic rosoft.com...

Funny... I don't really see a need for C# :)

There are a few things that C# can do that VB.NET can't, and there are
things that VB.Net does that C# can't do without added in a bunch of
VB.NET
references. But the reason for the very few things that VB.NET can't do
isn't any limitation of the language. What I mean by that is, MS could,
if
they wanted to, add all the extra stuff C# does to vb.net if they cared to do
so. There isn't anything really holding them back from doing that. In
fact!
C# is starting to get a lot of the nice features of VB.NET, such as "With" blocks.

Now, I'll be clear that I use both VB.NET and C#, but I clearly prefer
VB.NET, save a few things that bug me.

My 2 major annoyances with VB.net, as compared to C# are:
1) XML Comments -- I have the XML comments add-in, but it doesn't tie
into
the intellisense. It would be nice if my comments showed up in my own
intellisense function calls in vb.net just like they do in C#.
2) The "Dumbifying " of terms. "MustInheri t", "Shared" etc. A standard question for all interviewers who program in vb.net should be "what is an abstract class?" If you have to explain that "abstract" means
"MustInheri t"
then you know what kind of programmer you are dealing with.

Now, I think you would be hard pressed to prove that you can develop as
fast
in C# as you can in VB.Net. The intellisense and error catching is so
much
better in VB.NET (Im referring to the VS ide).

Either way, I agree the 2 will be moving closer to one another, but you
have
to wonder: with the technical reasons for using C# all but gone, why would new programmers choose C# (new, meaning they aren't coming from years of
C++
of java development)?

Better question: Is there any (quality) vb.net programmer out there who
can't read/write C#? Maybe not as fast, but everything is so similar...

"Alvin Bruney" wrote:

I believe they did. (can of worms here)

I really don't see a reason for VB.NET given the fact that it certainly
isn't VB with .NET classes. Eventually, VB.NET will have to morph into
something else. Programmers who need to learn VB.NET coming from VB
classic
are better off learning C#.

--
Regards
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
--------------------------------------------------
"Steve C. Orr [MVP, MCSD]" <St***@Orr.ne t> wrote in message
news:OT******** ******@TK2MSFTN GP09.phx.gbl...
> The main reasons they went with C# is because they were experienced
> with
> C++ (becuase C++ was more powerful than VB6) so it was more of a
> natural
> progression for them, and the other reason was because C# was the "new" > language and they wanted to eat their own dog food to ensure C# would
> become capable of all that they'd envisioned and all they needed.
>
> It wasn't because they saw C# as superior to VB.NET in any way.
>
> --
> I hope this helps,
> Steve C. Orr, MCSD, MVP
> http://SteveOrr.net
>
>
> "Robbe Morris [C# MVP]" <in**@turnkeyto ols.com> wrote in message
> news:Oy******** ******@TK2MSFTN GP09.phx.gbl...
>> When I saw that when deciding whether to continue on with VB.NET
>> (I was an old VB 6 and a C# coder), I went with C#.
>>
>> I figured if the Microsoft guys saw fit to use C#, maybe I should too. >> There must be a reason they picked it.
>>
>> --
>> 2005 Microsoft MVP C#
>> Robbe Morris
>> http://www.robbemorris.com
>> http://www.mastervb.net/home/ng/foru...t10017013.aspx
>> http://www.eggheadcafe.com/articles/..._generator.asp
>>
>>
>>
>> "Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> wrote in message
>> news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..
>>> About 2 years ago, and as recently as perhaps 1 year ago, I can
>>> recall
>>> seeing many posts about what language to use with ASP.Net. The
>>> consensus
>>> was that employers paid more for C# programmers, and it seems that C# >>> became the darling of the ASP.Net crowd.
>>>
>>> In the meantime, I have observed an interesting phenomenon.
>>> Originally,
>>> employers hired programmers who used C# because it was based on C,
>>> and
>>> the prevailing opinion was (and may still be) that C# developers were >>> better because they must have known and/or practiced C or C++ at some >>> time, which would make them better programmers overall. C and C++ are >>> hard-core programming languages compared to VB.
>>>
>>> However, now that nearly everyone has jumped on the C# bandwagon, it >>> seems to me that the distinction between the languages has nearly
>>> disappeared, at least in terms of evaluating programmers for hire.
>>> There
>>> seem to be almost as many clueless C# developers out there as VB.Net >>> developers. Many C# developers today are basically VB.Net developers >>> using a different syntax. I wonder if the employers have become aware >>> of
>>> this trend?
>>>
>>> --
>>>
>>> Kevin Spencer
>>> Microsoft MVP
>>> .Net Developer
>>> Neither a follower nor a lender be.
>>>
>>>
>>
>>
>
>

[Naja]

C# shops also hope to draw from the pool of Java developers as well as OOP
developers. The Jave devs have network/web experience already.

Is there really a true demise, or is it just a very slow adoption?

"Peter Rilling" wrote:

Okay, I write this message with the full knowledge that I am going to piss a
large number of people off. So I fully expect some flaming to happen.

As languages evolve, there becomes less and less that differentiates them.
There is nothing that you can do in C# that you cannot do in VB.NET.

I came from a VB development background and moved to C# about five years
ago. I do not necessarily think that companies look for C# people because
of the tie-in with C++, but rather that C# develops have more of an OOP
sense about them. C++ and C# are object oriented languages and therefore
those people tend to think in object design. VB used to be thought of a toy
and only used for RAD development. There was little emphasis placed on
proper coding styles. It was more of a "let's get it done" mentality rather
then "let's design something for expandability and maintainability ". Keep
in mind that until VB.NET was released, the concept of classes was shoddy at
best and certainly did not have inheritance or polymorphism, which means
that VB was NEVER an object oriented languages.

Remember that when the GUI first came out it was also thought of as a toy.
Why would real computer uses use a graphical interface, was the mantra of my
command-line gurus.

"Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> wrote in message
news:#X******** ******@TK2MSFTN GP12.phx.gbl...

About 2 years ago, and as recently as perhaps 1 year ago, I can recall
seeing many posts about what language to use with ASP.Net. The consensus

was

that employers paid more for C# programmers, and it seems that C# became

the

darling of the ASP.Net crowd.

In the meantime, I have observed an interesting phenomenon. Originally,
employers hired programmers who used C# because it was based on C, and the
prevailing opinion was (and may still be) that C# developers were better
because they must have known and/or practiced C or C++ at some time, which
would make them better programmers overall. C and C++ are hard-core
programming languages compared to VB.

However, now that nearly everyone has jumped on the C# bandwagon, it seems
to me that the distinction between the languages has nearly disappeared,

at

least in terms of evaluating programmers for hire. There seem to be almost
as many clueless C# developers out there as VB.Net developers. Many C#
developers today are basically VB.Net developers using a different syntax.

I

wonder if the employers have become aware of this trend?

--

Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.

[Ken G.]

Durring the 30 odd years I've been in this business the question of which
language to use has come up many times. My obersavation, for what its worth,
is that the more that a language/development tool dose for you the less the
programmer thinks about what they are doing. This can lead to code that is
harder to maintain and has performance issues. This is not always the case,
one can write bad code in any language.

As for VB vs C#, while most ASP pages are programmed in VB Script, there
isn't really a choice. All though I use VB Script alot, I prefer a more
"robust" language.
We are in the process of converting our website from ASP using VB Script to
..NET using C#.

So why C#? While VB programmers tend to have more "business" experience then
C programmers, if they learned to program the "Microsoft" way the code is
difficult to maintain and not preform well. Also, VB programms tend to be on
the small side.

We booked 75k orders on our website last month. That number is expected to
double in 6 months. We have to think very carefully about how our code is
written and C programmers have more experience doing that.

All that said, I continue to use VB for small desktop apps & VB Script for
lower volume web sites. For us it was a choice between C# or Java (which is a
much longer descussion)

[Kevin Spencer]

> So why C#? While VB programmers tend to have more "business" experience

then
C programmers, if they learned to program the "Microsoft" way the code is
difficult to maintain and not preform well. Also, VB programms tend to be
on
the small side.
Oh, so you're a "heightist, " eh? Don't like small people? ;-)

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"Ken G." <Ken G.@discussions. microsoft.com> wrote in message
news:B6******** *************** ***********@mic rosoft.com... Durring the 30 odd years I've been in this business the question of which
language to use has come up many times. My obersavation, for what its
worth,
is that the more that a language/development tool dose for you the less
the
programmer thinks about what they are doing. This can lead to code that is
harder to maintain and has performance issues. This is not always the
case,
one can write bad code in any language.

As for VB vs C#, while most ASP pages are programmed in VB Script, there
isn't really a choice. All though I use VB Script alot, I prefer a more
"robust" language.
We are in the process of converting our website from ASP using VB Script
to
.NET using C#.

So why C#? While VB programmers tend to have more "business" experience
then
C programmers, if they learned to program the "Microsoft" way the code is
difficult to maintain and not preform well. Also, VB programms tend to be
on
the small side.

We booked 75k orders on our website last month. That number is expected to
double in 6 months. We have to think very carefully about how our code is
written and C programmers have more experience doing that.

All that said, I continue to use VB for small desktop apps & VB Script for
lower volume web sites. For us it was a choice between C# or Java (which
is a
much longer descussion)

[cmay]

>>So, in fact, while C# can do anything that VB.Net can, VB.Net can not
do

everything that C# can.

How about:

Late Binding

Multiple indexed properties

Ease of COM Interop

Optional Parameters

Edit and Continue functionality

User filtered Exception trapping

Better intellisense

Better syntax error recognition in IDE (background compile)

Select Case

With

Productivity.
When MS decides to allow VB.net to use unmanaged code, then what?

I guess if using unmanaged code is extremely important to your project,
then one would be foolish to pick VB.net over C#, but for the avg
developer, why wouldn't they choose vb.net and if they ever needed to
access unmanaged code, just write a C# DLL?
I think the VB/C# debate can be summed up like this
VB.NET -- "I am TOO a programmer! Please, won't some C++ developers
out there agree??"
C# -- "It's not a real programming language unless it uses brackets."
C++ -- "I'll never concede to be equal to anything"

[Rob Nicholson]

> We booked 75k orders on our website last month. That number is expected to

double in 6 months. We have to think very carefully about how our code is
written and C programmers have more experience doing that.

Isn't that really all about how you implement the problem, not the
underlying language. After all, you *could* write the whole thing in
assembler and it would work equally as well. Would take you a lot longer
though. In a large program, your problems are algorithmic, not syntactical -
for example, the most efficient way to store and retrieve your data from the
database or reducing the number of postbacks required.

However, I can see where are coming from historically. C is somewhere
between assembler and VB, sort of a mid-level language as opposed to a high
level like Pascal or low-level like assembler or even Forth. Therefore, C
programmers were "closer to the metal" which often gave them a better
understanding of the underlying architecture. And as much of the early APIs
were also written in C, the interface between the operating system and C was
a better fit. I'm thinking here of bit level operations and structures. VB's
early lack of pointers et al made it harder to interface with the operating
system.

C++ was first out of the gates with a popular class OO language so C++
programmers got a head start there as well.

So all these things together (closer to the metal, better interface to
API/OS, classes) made your C/C++ programmer a "better" programmer.

But in terms of C# versus VB.NET, then the differences really are small now
and come down to whether you prefer one syntax over another with a few
enhancements on either side.

I'm not sure though that there is any particular problem than couldn't be
coded in either language.

Rob.

[Kevin Spencer]

> But in terms of C# versus VB.NET, then the differences really are small

now and come down to whether you prefer one syntax over another with a few
enhancements on either side.

I'm not sure though that there is any particular problem than couldn't be
coded in either language.

Just off the top of my head, what if you need a pointer? I certainly do from
time to time.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"Rob Nicholson" <ro***********@ nospam-unforgettable.c om> wrote in message
news:e6******** ******@tk2msftn gp13.phx.gbl...

We booked 75k orders on our website last month. That number is expected
to
double in 6 months. We have to think very carefully about how our code is
written and C programmers have more experience doing that.

Isn't that really all about how you implement the problem, not the
underlying language. After all, you *could* write the whole thing in
assembler and it would work equally as well. Would take you a lot longer
though. In a large program, your problems are algorithmic, not
syntactical - for example, the most efficient way to store and retrieve
your data from the database or reducing the number of postbacks required.

However, I can see where are coming from historically. C is somewhere
between assembler and VB, sort of a mid-level language as opposed to a
high level like Pascal or low-level like assembler or even Forth.
Therefore, C programmers were "closer to the metal" which often gave them
a better understanding of the underlying architecture. And as much of the
early APIs were also written in C, the interface between the operating
system and C was a better fit. I'm thinking here of bit level operations
and structures. VB's early lack of pointers et al made it harder to
interface with the operating system.

C++ was first out of the gates with a popular class OO language so C++
programmers got a head start there as well.

So all these things together (closer to the metal, better interface to
API/OS, classes) made your C/C++ programmer a "better" programmer.

But in terms of C# versus VB.NET, then the differences really are small
now and come down to whether you prefer one syntax over another with a few
enhancements on either side.

I'm not sure though that there is any particular problem than couldn't be
coded in either language.

Rob.

[Kevin Spencer]

I'm afraid your arguments simply indict you and (by association) other VB
programmers, and may in fact add to the impression of VB programmers not
being too savvy. Why?

Late Binding
Is this a good thing? (Answer: no - Late Binding is something to be avoided)
Multiple indexed properties
You got me there. This can be achieved with C# however, using a different
syntax.
Ease of COM Interop
Is that a good thing? Regardless, both languages can use COM Interop, and
there is no difference in performance. You're talking about the ease of
writing the code there.
Optional Parameters
Optional Parameters is really a wrapper for overloading. It is not unique to
VB.
Edit and Continue functionality
What does this have to do with VB? This is a feature of the VS.Net IDE.
User filtered Exception trapping
Sorry. Each language implements this, just a bit differently.
Better intellisense
Again, you're mixing up Visual Studio.Net with Visual Basic.Net.
Better syntax error recognition in IDE (background compile)
This is getting embarassing (Visual Studio.Net again) Select Case
switch() in C#
With
A handy little tool for developers, but makes no difference in the app.
Productivity.

Huh?

BTW, I did not mention ALL of the language features that C# has which VB.Net
does not, only the most salient ones (ones which affect the performance of
the app, or which may be necessary, but are not available in VB). There are
some situations in which you can NOT do away with pointers. There are NO
situations in which you can NOT do away with, for example, the With
statement.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"cmay" <cm**@walshgrou p.com> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .

So, in fact, while C# can do anything that VB.Net can, VB.Net can not doeverything that C# can.

How about:

Late Binding

Multiple indexed properties

Ease of COM Interop

Optional Parameters

Edit and Continue functionality

User filtered Exception trapping

Better intellisense

Better syntax error recognition in IDE (background compile)

Select Case

With

Productivity.
When MS decides to allow VB.net to use unmanaged code, then what?

I guess if using unmanaged code is extremely important to your project,
then one would be foolish to pick VB.net over C#, but for the avg
developer, why wouldn't they choose vb.net and if they ever needed to
access unmanaged code, just write a C# DLL?
I think the VB/C# debate can be summed up like this
VB.NET -- "I am TOO a programmer! Please, won't some C++ developers
out there agree??"
C# -- "It's not a real programming language unless it uses brackets."
C++ -- "I'll never concede to be equal to anything"

[gerry]

just 2 cents from a coder who could not care less about the incessant vb vc
c# debate

"Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> wrote in message
news:un******** ********@TK2MSF TNGP10.phx.gbl. ..

I'm afraid your arguments simply indict you and (by association) other VB
programmers, and may in fact add to the impression of VB programmers not
being too savvy. Why?

Late Binding
Is this a good thing? (Answer: no - Late Binding is something to be

avoided)

well that is one opinion - and not always possible - see below.

Multiple indexed properties
You got me there. This can be achieved with C# however, using a different
syntax.

Ease of COM Interop

Is that a good thing? Regardless, both languages can use COM Interop, and
there is no difference in performance. You're talking about the ease of
writing the code there.

not true.
I have run across a few com components that just could not be used in any
reasonable fashion from c# but worked perfectly well with vb.
This being due to ill-designed com servers that expose everything as Objects
and c#'s ( lack of ) late binding. Of course you may consider wrapping an
untyped com object with a class that implements zillion InvokeMember()
calls as a reasonable solution - I personally don't

Optional Parameters
Optional Parameters is really a wrapper for overloading. It is not unique

to VB.

Edit and Continue functionality
What does this have to do with VB? This is a feature of the VS.Net IDE.

not really - if it was then all languages would support it.
Edit & Continue may be facilitated by the ide but is still up to the
language module to enable it.

User filtered Exception trapping
Sorry. Each language implements this, just a bit differently.

Better intellisense

Again, you're mixing up Visual Studio.Net with Visual Basic.Net.

ok so the ide displays the intellisense BUT it is entirely based on
information that comes from the langauge module
see last point.

Better syntax error recognition in IDE (background compile)
This is getting embarassing (Visual Studio.Net again)

same as last points - if you've ever implemented a langauge for use within
the vs.net ide via VSIP you would know that syntax recognition like
intellisense like edit & continue is entirely dependant upon the language
module - the ide is just a front end facilitator , if these aren't provided
by the language module, you won't get them.

Select Case

switch() in C#

With

A handy little tool for developers, but makes no difference in the app.

Productivity.

Huh?

BTW, I did not mention ALL of the language features that C# has which

VB.Net does not, only the most salient ones (ones which affect the performance of
the app, or which may be necessary, but are not available in VB). There are some situations in which you can NOT do away with pointers. There are NO
situations in which you can NOT do away with, for example, the With
statement.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
What You Seek Is What You Get.

"cmay" <cm**@walshgrou p.com> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .

So, in fact, while C# can do anything that VB.Net can, VB.Net can not

do

everything that C# can.

How about:

Late Binding

Multiple indexed properties

Ease of COM Interop

Optional Parameters

Edit and Continue functionality

User filtered Exception trapping

Better intellisense

Better syntax error recognition in IDE (background compile)

Select Case

With

Productivity.
When MS decides to allow VB.net to use unmanaged code, then what?

I guess if using unmanaged code is extremely important to your project,
then one would be foolish to pick VB.net over C#, but for the avg
developer, why wouldn't they choose vb.net and if they ever needed to
access unmanaged code, just write a C# DLL?
I think the VB/C# debate can be summed up like this
VB.NET -- "I am TOO a programmer! Please, won't some C++ developers
out there agree??"
C# -- "It's not a real programming language unless it uses brackets."
C++ -- "I'll never concede to be equal to anything"

[Kevin Spencer]

> not true.

I have run across a few com components that just could not be used in any
reasonable fashion from c# but worked perfectly well with vb.
This being due to ill-designed com servers that expose everything as
Objects
and c#'s ( lack of ) late binding. Of course you may consider wrapping an
untyped com object with a class that implements zillion InvokeMember()
calls as a reasonable solution - I personally don't
I have run across a few hills that were too steep to climb. Oops.
Correction. I have run a across a few hills that I could not climb. They
weren't too steep for everyyone to climb. How would I know that? All I know
is, I couldn't climb them. On the other hand, I don't live near any hills,
and climbing hills is not a good thing to do. So it really doesn't matter.
not really - if it was then all languages would support it.
Edit & Continue may be facilitated by the ide but is still up to the
language module to enable it.
Okay, so how do you edit and continue using the command-line compiler? How
do you edit and continue while debugging a VB.Net file you're composing in
Notepad? And how does Edit and Continue make your app run better? Or
perhaps, just maybe, this may be part of the "language module" that has
nothing to do with the language, but the IDE?
ok so the ide displays the intellisense BUT it is entirely based on
information that comes from the langauge module
see last point.
See MY last point.

Okay, let's for the sake of argument assume that you have pointed up a few
things you can do with VB.Net that you can't with C# (only for the sake of
argument). How many of these things can you not do without? How many of
these things affect the performance of your app? Answer: none. On the other
hand, let's say you want to write a custom image filter, to do blurring, or
sharpness, or contrast. And you're writing with VB.Net. No pointers. Now,
you're processing a 600X800 image. How long will it take to process the
whole image? Well, from personal experience I can tell you that it is an
order of magnitude slower to do without pointers. We're talking hundreds of
times slower. In fact, you could not sell such an app. The competition would
kill it.

So, in terms of real value (as compared with trivial conveniences), there is
nothing that VB offers that C# doesn't.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"gerry" <ge**@hotmail.c om> wrote in message
news:Oo******** ******@TK2MSFTN GP10.phx.gbl... just 2 cents from a coder who could not care less about the incessant vb
vc
c# debate

"Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> wrote in message
news:un******** ********@TK2MSF TNGP10.phx.gbl. ..

I'm afraid your arguments simply indict you and (by association) other VB
programmers, and may in fact add to the impression of VB programmers not
being too savvy. Why?

> Late Binding

Is this a good thing? (Answer: no - Late Binding is something to be

avoided)

well that is one opinion - and not always possible - see below.

> Multiple indexed properties

You got me there. This can be achieved with C# however, using a different
syntax.

> Ease of COM Interop

Is that a good thing? Regardless, both languages can use COM Interop, and
there is no difference in performance. You're talking about the ease of
writing the code there.

not true.
I have run across a few com components that just could not be used in any
reasonable fashion from c# but worked perfectly well with vb.
This being due to ill-designed com servers that expose everything as
Objects
and c#'s ( lack of ) late binding. Of course you may consider wrapping an
untyped com object with a class that implements zillion InvokeMember()
calls as a reasonable solution - I personally don't

> Optional Parameters

Optional Parameters is really a wrapper for overloading. It is not unique

to

VB.

> Edit and Continue functionality

What does this have to do with VB? This is a feature of the VS.Net IDE.

not really - if it was then all languages would support it.
Edit & Continue may be facilitated by the ide but is still up to the
language module to enable it.

> User filtered Exception trapping

Sorry. Each language implements this, just a bit differently.

> Better intellisense

Again, you're mixing up Visual Studio.Net with Visual Basic.Net.

ok so the ide displays the intellisense BUT it is entirely based on
information that comes from the langauge module
see last point.

> Better syntax error recognition in IDE (background compile)

This is getting embarassing (Visual Studio.Net again)

same as last points - if you've ever implemented a langauge for use within
the vs.net ide via VSIP you would know that syntax recognition like
intellisense like edit & continue is entirely dependant upon the language
module - the ide is just a front end facilitator , if these aren't
provided
by the language module, you won't get them.

> Select Case

switch() in C#

> With

A handy little tool for developers, but makes no difference in the app.

> Productivity.

Huh?

BTW, I did not mention ALL of the language features that C# has which

VB.Net

does not, only the most salient ones (ones which affect the performance
of
the app, or which may be necessary, but are not available in VB). There

are

some situations in which you can NOT do away with pointers. There are NO
situations in which you can NOT do away with, for example, the With
statement.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
What You Seek Is What You Get.

"cmay" <cm**@walshgrou p.com> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .

>>>So, in fact, while C# can do anything that VB.Net can, VB.Net can not
> do
>>>everything that C# can.
>
> How about:
>
> Late Binding
>
> Multiple indexed properties
>
> Ease of COM Interop
>
> Optional Parameters
>
> Edit and Continue functionality
>
> User filtered Exception trapping
>
> Better intellisense
>
> Better syntax error recognition in IDE (background compile)
>
> Select Case
>
> With
>
> Productivity.
>
>
> When MS decides to allow VB.net to use unmanaged code, then what?
>
>
>
> I guess if using unmanaged code is extremely important to your project,
> then one would be foolish to pick VB.net over C#, but for the avg
> developer, why wouldn't they choose vb.net and if they ever needed to
> access unmanaged code, just write a C# DLL?
>
>
> I think the VB/C# debate can be summed up like this
> VB.NET -- "I am TOO a programmer! Please, won't some C++ developers
> out there agree??"
> C# -- "It's not a real programming language unless it uses brackets."
> C++ -- "I'll never concede to be equal to anything"
>