What's the point of C# and C++

[Michael C]

I wonder if you have ever used VB in the VS IDE, as most keywords are
inserted automatically and/or provided in context-aware IntelliSense
menus.

Yes I have, that's why I know you still need to do a lot of typing. The ones
I particularly dislike are DirectCast and public readonly property x as y. I
know you can use intellisense to shortcut these but isn't it easier just to
not type them as all?

Michael

 

[Michael C]

Hi Zach -

Over the years, the differences between VB.NET and C# have been slowly
wearing away. There are only a handful of applicable differences now, with
each language having some unique features the other doesn't. I think for
about 90% of projects, you'll never run into these differences.

But the features that C# are missing are not show stoppers. As an example,
in VB you can't use pointers so completely rules out manipulating bitmaps
(or other data) with the same speed as C#. On the other hand I can't think
of a single feature VB has that is a show stopper in C#. Most of the VB
features that people put forward are fairly trivial and can be done other
ways in C#.

The greatest complaint you hear is that VB.NET is much more verbose than
C#.
This is true, but in practice it doesn't matter much. Visual studio fills
in
the code block End X statements so you don't have to type them out.

You still type more in VB. It's the common stuff like dim and directcast
that get in the way.

The second complaint you hear is that VB.NET code is poorly written. I
think
this is unfair.

VB code *can* be poorly written but so can C# code. But the big difference
is that VB.net allows much greater scope for poorly written code especially
with the ability to turn option strict off.

The fact is that VB.NET's verbosity makes it more
approachable to new programmers. Of course these new programmers are going
to make mistakes and have lousy code. But there is nothing intrinsic about
C# that makes the resultant MSIL better.

That is true.

The whole argument is ridiculous. It's like saying that a novel written in
British English is intrinsically better than American English because it
refers to the car's storage area as a "boot" instead of a "trunk".

I disagree with that statement. A better example would be a technical
document written using roman numerials vs decimal.

I can't believe this is still a matter being discussed. This acutally came
up in a conversation I had at lunch recently. I was dining with a young
man
who knew C#. It was the only language he knew. He thought very lowly of
other languages, but when it came down to it, it was really a matter of
him
looking at VB code and being out of his comfort zone.

Just because one person likes c# just because they're comfortable with it
does make that true for everyone. I've certainly done a *lot* more VB than C
style programming over the years. Now that I've used C# since 2001 I realise
it fits much better with my style.

Anyway, that's what it comes down to, IMHO. Just a preference, nothing
more.

There's more to it than that for sure.

It's always a good idea to diversify and learn many languages so you can
fluff your resume a bit, though. Good luck with your training.

That's true although it's best not to put Microsoft Access on your resume
because they might just ask you to do some work in it!

Michael

 

[Cor Ligthert[MVP]]

Tom,

I never discuss about believe.

Lol

Cor

I don't believe that for 1 second. Not one. 50%. LOL.

 

[Cor Ligthert[MVP]]

Michael,

I found the reply from Mark very fine. Except the point verbose, because
that is simply not true anymore for the current versions of VB and C#, C#
has in my idea become more verbose than VB, because I know that I have so
much to type in C# what simply is not needed in VB (and I use C# often).

However, as you are writting something in VB then you are probably simple
doing the same things as in C# and types a lot which simple is not needed in
VB (anymore).

Trying to explain this in the line of Marks his reply. How many natural
languages do you speak, by instance as I speak Polish, then I aways use
words as (translated to English), "I", "you", "he". That is not needed in
Polish (like in Italian where I do that by the way the same), probably I do
that in English to with other words, however I don't know that.

Are you sure that you know enough from VB to make those judgements as you
do?

Cor

 

[Michael C]

Michael,

I found the reply from Mark very fine. Except the point verbose, because
that is simply not true anymore for the current versions of VB and C#, C#
has in my idea become more verbose than VB, because I know that I have so
much to type in C# what simply is not needed in VB (and I use C# often).

There are some cases where VB has the upper hand with regards to typing. The
obvious one is events in C# (creating your own custom events that is) which
can be quite a pain. I also quite like the handles keyword and I'm not sure
it breaks any "sacred oop" rules so could be part of C#. Considering what
they've done with linq I think the handles keyword could be part of C#. But
these features are not really that significant as I don't need to create my
own events all that often and generally the IDE does the hard word with
regards to replacing the handles keyword. Where the real difference is is
with the keywords you use every minute of the day, the big ones for me are
Dim, DirectCast, Public Readonly Property and Function (and possibly some
other common ones).

However, as you are writting something in VB then you are probably simple
doing the same things as in C# and types a lot which simple is not needed
in VB (anymore).

Surely the number of keys you push overall in VB is greater than in C#.

Trying to explain this in the line of Marks his reply. How many natural
languages do you speak, by instance as I speak Polish, then I aways use
words as (translated to English), "I", "you", "he". That is not needed in
Polish (like in Italian where I do that by the way the same), probably I
do that in English to with other words, however I don't know that.

Are you sure that you know enough from VB to make those judgements as you
do?

I did use VB4 to 6 for 10+ years and have been on a VB.net project for the
last 6 months.

Michael

 

[Armin Zingler]

Surely the number of keys you push overall in VB is greater than in C#.

Seems to be the main reason, why VB is casual... VB's IDE/intellisense is
often faster than I am able to think - which is not my personal problem.


In a professional environment, "safety first" rules. Unsafe code in C#,
which I consider the _only_ _main_ difference, is an additional feature,
indeed. However, the customer is not interested in features of the language
whereas he is very well interested in a stable application. I don't think
that unsafe code can make a contribution to that. The opposite is the case.


Armin

 

[Michael C]

Seems to be the main reason, why VB is casual... VB's IDE/intellisense is
often faster than I am able to think - which is not my personal problem.

On my work PC, which is a celeron 2.6 with 1gb ram, VB struggles.

In a professional environment, "safety first" rules. Unsafe code in C#,
which I consider the _only_ _main_ difference

There is certainly a lot more difference than that.

, is an additional feature, indeed. However, the customer is not interested
in features of the language whereas he is very well interested in a stable
application. I don't think that unsafe code can make a contribution to
that. The opposite is the case.

Pretty much every single part of windows and 99% of apps on the market are
written in 100% unsafe code. There is nothing to be afraid of and having the
option *when needed* is most definately a good thing.

Michael

 

[Herfried K. Wagner [MVP]]

Yes I have, that's why I know you still need to do a lot of typing. The
ones I particularly dislike are DirectCast and public readonly property x
as y. I know you can use intellisense to shortcut these but isn't it
easier just to not type them as all?

You could still define code snippets ('dc' expanding to 'DirectCast', for
example). In my code I rarely use 'DirectCast', and I consider rare
necessity to use 'DirectCast' a good architecture.

 

[Herfried K. Wagner [MVP]]

But the features that C# are missing are not show stoppers. As an example,
in VB you can't use pointers so completely rules out manipulating bitmaps
(or other data) with the same speed as C#. On the other hand I can't think
of a single feature VB has that is a show stopper in C#. Most of the VB
features that people put forward are fairly trivial and can be done other
ways in C#.

There are lots of things which cannot be done in C# but are supported by
C++/CLI. So why not use C++/CLI instead of C#?

Pointers are only necessary in very rare cases, and in these rare cases I'd
write a small C# library and add it to the solution.

 

[Armin Zingler]

On my work PC, which is a celeron 2.6 with 1gb ram, VB struggles.

Maybe with things that C# not even offers.

There is certainly a lot more difference than that.

No, there is no major difference. I don't discuss few keystrokes. I favor
readable code over typing less. Don't tell me VB code is harder to read
(isn't it for casual programmers?). Due to intellisense and all
automatically inserted code structures, I don't have to type a lot anymore
anyway, so this isn't an issue at all. Maybe you should have a look at the
current version. Intellisense in VB has become great, I'd even say perfect.
I really don't know what could be improved.

Pretty much every single part of windows and 99% of apps on the market are
written in 100% unsafe code. There is nothing to be afraid of and having
the option *when needed* is most definately a good thing.

Ok, then we don't need safe code and the whole managed story because
everything else has worked well in the past. Tell it to MSFT. The fact is,
that it did cause a lot of problems. Maybe you've forgotten them, I did not.
Obviously you don't get the point. My customer is not interested in having
unsafe code. He is more interested in having a stable application. This can
not be achieved better by using unsafe code. In addition, in my job, I don't
have to use (unsafe) pointers at all. And I don't know any programmer who
needs them. I do know some of them. So, it is not only sufficient saying
that there is a feature, you also don't have to forget the weighting. So, if
even the major difference is not a big one in practice, there's almost
nothing left.

If I really needed fast bit twiddling, I'd write a C++ DLL. I wouldn't know
why to use C# _only for this purpose_. So, VB offers an overwhelming
productivity, and C++ gives me all low level stuff that I need. I don't see
a reason to use C# - unless you say C#'s unsafe code is more powerful than
C++'s. That would be an absurdity again from you.

It's just ridiculous saying VB is made for casual programmers. This is
trolling. I couldn't earn my money better, faster, easier in C#. Don't
forget that both languages compile to IL code, therefore it's humbug saying
there's a big difference.

There's nothing else I have to add.


Armin

 

[Armin Zingler]

There are lots of things which cannot be done in C# but are
supported by C++/CLI. So why not use C++/CLI instead of C#?

Because C++/CLI programming is horrible. Really. C++ was not made for
this. I mean, it is clearly noticable that it wasn't. Lately, I put a lot of
code back into a VB project and left only the necessary parts in the C++
DLL.

Pointers are only necessary in very rare cases, and in these rare
cases I'd write a small C# library and add it to the solution.

Or a C++ library because C#'s low level features are, for sure, not better
than C++'s.


Armin

 

[Tom Dacon]

Interesting. I notice that a very large number of the complaints in this
thread are about the behavior of the IDE, not the features of the languages.
Are we missing the OP's point, perhaps - although I'm far, far from agreeing
with it. If I had wanted to roll a grenade down the table I couldn't have
crafted a better one than his

Tom Dacon
Dacon Software Consulting

 

[Mark S. Milley]

Hi Michael -

But the features that C# are missing are not show stoppers. As an example,
in VB you can't use pointers so completely rules out manipulating bitmaps
(or other data) with the same speed as C#.

I have made plenty of applications that have image manipulation needs, and I
have found the graphics classes and routines built into the framework more
than adequate. These drawing routines are available and work at the same
speed whether you are using VB.NET, C#, Cobol for .NET or any other .NET
language. I wouldn't make the assumption that I could create a faster bitmap
routine than the folks at MS in VB.NET, C#, or any other language. This is
not me being an MS fan boy; I can just face the reality that there are a lot
of things that I am good at and can do well, and for other things I'll trust
that the folks at MS have the time, resources, and energy to devote to
researching the best bitmap manipulation approaches.

If you honestly feel that you can manipulate images faster than the routines
built into the framework, then I'll conceed the point. Personally, I have
better things to do with my time, like making sure my applications are
completed on time and under budget.

You still type more in VB. It's the common stuff like dim and directcast
that get in the way.

I meant to mention that I personally find the verbosity beneficial,
especially when revisiting code I haven't looked at in years, or trying to
interpret someone else code--it is inherently self-documenting. Figuring out
which in a long series of what the end brackets are ending which block of
code can be a chore: "which of these five brackets to I have to insert this
line into? Let me scroll up..." I always laugh when I see constructs like
this in "less verbose" C# code:

}//end if

VB code *can* be poorly written but so can C# code. But the big difference
is that VB.net allows much greater scope for poorly written code
especially with the ability to turn option strict off.

Sure, but as per the default installation of VB.NET it's turned ON. You can
also force case-sensitivity, for you folks who claim this is an advantage of
C#. You can also turn these options on or off per file. Honestly, I never
understood this argument--you are saying that having more options is a bad
thing; personally, I feel that this flexibility is just another strength of
VB.

Just because one person likes c# just because they're comfortable with it
does make that true for everyone. I've certainly done a *lot* more VB than
C style programming over the years. Now that I've used C# since 2001 I
realise it fits much better with my style.

That's fine. I've programmed in C#, as well as other syntactically similar
languages such as Java, Javascript, and PHP, and I wish to respectfully
disagree.

Again, I feel this argument is ridiculous, because, ultimately, the bulk of
what we do is calls to the framework. People tend to have go into heated
debates on this subject, when they are comparing apples to apples. I would
understand the level of hostility if we were discussing Java vs. .NET,
ASP.NET vs PHP, or Flash vs Silverlight, but really, we're all users of the
..NET Framework here. This debate is unproductive, and when it comes down to
it, it is a choice that is often made for us; made by the company that we
work for, made by the team we are on, made by the programmer who's code we
are maintaining. Nobody is threatening to take the language away from the
other side.

Again, to answer the asker's original questions, I feel that it's in
everyone's best interest to learn both of the major .NET languages so that
you can easily integrate with any team.

Happy Coding,

-Mark

 

[Rory Becker]

Hello Cor Ligthert[MVP],

I found the reply from Mark very fine. Except the point verbose,
because that is simply not true anymore for the current versions of VB
and C#, C# has in my idea become more verbose than VB, because I know
that I have so much to type in C# what simply is not needed in VB (and
I use C# often).

Something people oftem forget when comparing the verboseness of the languages
is that most of the symbols in c# require the use of the Shift key in order
to place them on the screen.

A small point but it adds to the awkwardness for me.

 

[Lord Fauntleroy]

The reason both exist is that they are aimed at different markets. C# is
more aimed at someone who is programming day in and day out while VB is
more aimed at your casual programmer.

VB is aimed at your casual programmer? Damn, I should tell the clients that
pay my consulting fees that I am a casual programmer. HA HA. VB is a great
language and compiles just as fast as C#. Granted you can do some things in
C# that you can't do in VB, but for business programming, VB is the way to
go.

In some cases VB is easier to use than C#

but there a lot of disadvantages with VB. While it has some minor
timesaving examples these are fairly insignificant when you need to use
pointers and are stuck in a VB project (pointers are useful for high speed
bitmap and video stream manipulation. Donet can keep up a fairly high
frame rate and manipulare video in real time).

Most businesses don't use video manipulation so C# isn't needed. You have
no clue what you are talking about. I have many clients that use VB.NET and
they are very successful at using VB. Maybe you just can't learn VB.


Personally for me just having to type all

the keywords that are required in vb is enough to make me prefer c#. eg
function, sub, dim, as, directcast, not, I must type these 1000+ times a
day and am really sick of typing them, especially directcast.

Wow - VB has lots of keywords and C# or C++ doesn't. Let me write that
down.

 

[Michael C]

It's not that you act like a child because you say something that he
doesn't want to hear, it's that you are an IDIOT who has no clue what goes
on in the background.

When you call someone an idiot in capital letters you should really make
sure you're not proving yourself one. VB compiles in the backgroud after
every change you make so that it can show you errors as you type them. C#
does not show errors until you do a build. This makes C# run faster in the
IDE and is a fact.

VB and C# compile and run in .NET at the same speed.

That is true but that is NOT what I said.

Michael

 

[Michael C]

You could still define code snippets ('dc' expanding to 'DirectCast', for
example). In my code I rarely use 'DirectCast', and I consider rare
necessity to use 'DirectCast' a good architecture.

How do you get away with that? For example, every time you read from a data
reader you need to use DirectCast. I'm sure there are literally hundreds of
other examples where you need directcast also.

Michael

 

[Michael C]

VB is aimed at your casual programmer? Damn, I should tell the clients
that pay my consulting fees that I am a casual programmer. HA HA.

I really don't want to turn this into any more of a mud throwing match that
it already is but you VB guys are pretty suprising. The number of immature
and illogical responses here is quite amazing. Just because you use it for
business apps and get paid for it does not somehow mean that MS are not
aiming it more at the casual programmer.

VB is a great language and compiles just as fast as C#.

I never said otherwise, what I said was the IDE runs slower because VB
continuously compiles in the background with every change you make.

Granted you can do some things in C# that you can't do in VB,

That's right and you'd be suprised when these needs arise.

but for business programming, VB is the way to go.

That's just a statement of your opinion really.

Most businesses don't use video manipulation so C# isn't needed.

While that might be true all of the businesses I've work for have used
bitmap manipulation (dental, education and telecoms). The fact that you
missed this in your reply indicates you understand that.

You have no clue what you are talking about.

Very childish.

I have many clients that use VB.NET and they are very successful at using
VB.

I never said people don't use VB, I said that MS aimed C# more at the
professional and VB more at the casual programmer.

Maybe you just can't learn VB.

I've done 10+ years with VB before moving to C# in 2001. I was the only
programmer in the world who could subclass in VB3 with pure VB3 code. Even
the experts said this was impossible.

Wow - VB has lots of keywords and C# or C++ doesn't. Let me write that
down.

Another mature response.

Michael

 

[Michael C]

Maybe with things that C# not even offers.

Things like the forms designer can be very slow with delays of 1 minute on
some complex forms.

No, there is no major difference. I don't discuss few keystrokes. I favor
readable code over typing less. Don't tell me VB code is harder to read
(isn't it for casual programmers?).

Initially VB code might be easier to read, especially when you first dive
into someone elses code. Once you've gained a small amount of familiarity
with the project C# is much easier to read (there's less reading .

Due to intellisense and all
automatically inserted code structures, I don't have to type a lot anymore
anyway, so this isn't an issue at all. Maybe you should have a look at the
current version. Intellisense in VB has become great, I'd even say
perfect.
I really don't know what could be improved.

I'm quite suprised to hear you say that. While the intellisense in C# could
have some improvements, I find the VB intellisense inferior for several
reasons. Here's what I wrote in another thread:

1) Whenever you select a control name, eg txtWhatever, the intellisense
always goes to the first event handler, eg txtWhatever_KeyDown. In all my
years of programming I've never called an event so always have to scroll up
one.
2) Instead of moving to the required item in the list, the list gets smaller
as I type. If I mistype a single characters then the list usually
disappears. I then have to backspace until the list reappears and select the
item I want. In comparison the list in C# does not get smaller and does not
disappear so usually when I mistype I can see the item I want in the list
and select it.
3) Because of 2 when you push backspace intellisense appears.
4) Intellisense seems to popup more often when it is not wanted and I find
myself pushing esc all day. In comparison intellisense in c# seems to appear
more in line with when I want it. I'd have to be in front of my work PC to
fully work out what's going on here.
5) when I type "public readonly property" the
intellisense shows readonly and property but for some reason they are not
selected and I have to down arrow 1 to select each of these. This is
annoying consider both keywords are not required in C# at all.

Ok, then we don't need safe code and the whole managed story because
everything else has worked well in the past. Tell it to MSFT. The fact is,
that it did cause a lot of problems. Maybe you've forgotten them, I did
not.
Obviously you don't get the point. My customer is not interested in having
unsafe code. He is more interested in having a stable application. This
can
not be achieved better by using unsafe code. In addition, in my job, I
don't
have to use (unsafe) pointers at all. And I don't know any programmer who
needs them. I do know some of them. So, it is not only sufficient saying
that there is a feature, you also don't have to forget the weighting. So,
if even the major difference is not a big one in practice, there's almost
nothing left.

Just because you don't know people who use these features does not mean no
one uses them. My customers don't necessarily want unsafe code but they want
speed in certain areas. In order to do the high speed stuff such as video or
bitmap manipulation you will always need to go to unsafe code.

BTW, I think you're misunderstanding the point of safe code. It's there so
that users can restrict an untrusted app from doing things they don't want
it to do. ie it's there for security. It doesn't magically make your app
less buggy, you can still write buggy safe or unsafe code.

If I really needed fast bit twiddling, I'd write a C++ DLL. I wouldn't
know
why to use C# _only for this purpose_. So, VB offers an overwhelming
productivity, and C++ gives me all low level stuff that I need. I don't
see
a reason to use C# - unless you say C#'s unsafe code is more powerful than
C++'s. That would be an absurdity again from you.

Please don't put words into my mouth. While you can use C++ for these sort
of things, why would you go to all that extra trouble when you can do it in
the same code with all the speed benefits of C++?

It's just ridiculous saying VB is made for casual programmers. This is
trolling.

It appears trolling = someone saying what you don't want to hear. You're the
one being childish and throwing insults.

I couldn't earn my money better, faster, easier in C#.

You probably could. A lot of VBers seem to think that shifting to C# is
going to be extremely difficult. We switched at a company where I was
working and it took pretty much 1 single day for everyone to move over (this
was right at the start of the .net thing so we didn't have much code). Given
that the languages are similar the difference isn't going to be much but
with the quicker IDE and better intellisense and larger number of features
you would actually work quicker in C#.

Don't
forget that both languages compile to IL code, therefore it's humbug
saying
there's a big difference.

I never said there was a big difference. I said there was more difference
that you suggested (you suggested there was almost no difference if I
remember correctly).

There's nothing else I have to add.

Fair enough.

Michael

 

[Michael C]

I have made plenty of applications that have image manipulation needs, and
I have found the graphics classes and routines built into the framework
more than adequate. These drawing routines are available and work at the
same speed whether you are using VB.NET, C#, Cobol for .NET or any other
.NET language. I wouldn't make the assumption that I could create a faster
bitmap routine than the folks at MS in VB.NET, C#, or any other language.
This is not me being an MS fan boy; I can just face the reality that there
are a lot of things that I am good at and can do well, and for other
things I'll trust that the folks at MS have the time, resources, and
energy to devote to researching the best bitmap manipulation approaches.

The graphics classes are excellent, I agree. But they don't do everything
and I'm suprised you could use them extensively and not run into the need to
do bitmap manipulation directly. For example, there is no facility to run a
simple filter on a bitmap (eg, sharpen or blur).

If you honestly feel that you can manipulate images faster than the
routines built into the framework, then I'll conceed the point.
Personally, I have better things to do with my time, like making sure my
applications are completed on time and under budget.

In some cases doing something myself will be slower but yes, there are cases
where it will be faster. This is not due to a fault in the MS libraries,
they might just have more options built in that I can eliminate in my code.

I meant to mention that I personally find the verbosity beneficial,
especially when revisiting code I haven't looked at in years, or trying to
interpret someone else code--it is inherently self-documenting. Figuring
out which in a long series of what the end brackets are ending which block
of code can be a chore: "which of these five brackets to I have to insert
this line into?

I can't argue that can't sometimes be a problem but it's fairly rare and
often is due to the programmer putting too much code in a single routine.

Let me scroll up..." I always laugh when I see constructs like this in
"less verbose" C# code:

}//end if

I'm not sure why you'd laugh at that. It's great not having to type End If
but in the cases where a comment can help, well, why not have one?

Sure, but as per the default installation of VB.NET it's turned ON. You
can also force case-sensitivity, for you folks who claim this is an
advantage of C#.

Cool, I didn't know that.

You can also turn these options on or off per file. Honestly, I never
understood this argument--you are saying that having more options is a bad
thing;

Abso-flucking-lutely!! Yes, less options is quite often a really really good
thing. In many cases having a greater amount of restriction is what makes
something so great. If you compare ASP code to VB.net then vb.net code is
much more strict. This is a very good and makes vb.net code more robust that
asp code (given that a programmer of equal skill was using both). C# takes
this a step further.

personally, I feel that this flexibility is just another strength of VB.

I disagree, greater restriction is often better.

That's fine. I've programmed in C#, as well as other syntactically similar
languages such as Java, Javascript, and PHP, and I wish to respectfully
disagree.

You disagree that C# suits my style better?

Again, I feel this argument is ridiculous, because, ultimately, the bulk
of what we do is calls to the framework.

While that is true, as programmers we spent many hours using the IDE.
According you your arguement you can achieve the same result with notepad so
why not use that?

Michael