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.

[Rob Nicholson]

> out of curiousity, why is your company still writing code in vb6. is it

mainly maintainance or is that new development?

For us, it's maintenence and enhancements to a large VB6 app. But it's going
to require maintenence for at least the next five years for some customers.
Classic case of "it's works, so don't fix it". There will be a lot of that
around.

Cheers, Rob.

[Rob Nicholson]

> MyMethod()" or something like that. It's not like the Friend keyword

existed in VB6, so it wasn't for backwards compatibility.)
But it was a case of using the same keyword as C++ wasn't it?
While I don't knock VB/VB.NET programmers, I do look at the language as a
"shortcut" language now a days. Even with .Net and all of MSFT's touting
of
Whilst I'd agree in teh VB6 vs. C++ discussion, VB.NET should really be
classed as a shortcut language. But even if it was - what's actually wrong
with that? :-) In every parts of our lives we try and use as many shortcuts
to make our life easier or to achieve something quicker.
abstracts the developer from the things that are happening under the hood,
you can start to see why I call it a shortcut language. (There was a post
in one of the other groups about why VB treats strings differently than C#
does. It goes to the fact of my reasoning).
But in 99% of the cases, this hiding is a good thing IMHO. After all, aren't
using objects and abstraction partly about trying to "hide" the underlying
mechanisms:

Window.SaveAsGI F("c:\wibble.gi f")

Is all about hiding the nasty intricies of GIF LZW (it is LZW isn't it?)
compression.
number compared to the VB developers that wanted it). As this rift
continues to grow, I see yet another period where you have C# developers
(much akin to the C/C++ developers during the VB4~VB6 era) doing more
enterprise-type applications and VB developers doing more
front-end/desktop applications. As long as MSFT doesn't decide to spilt up
the IDE again (Like VS6 and earlier), I think we can all get along. :-)

But I'd agrue that's still historical in that your back-end guys used C++ in
the past whereas your front-end programmers might have used VB6 and
therefore feel more at home with and C# and VB.NET respectively. It's not
because there are some things that VB.NET just can't do.

I used to do most of my programming in C++ but that was because I came from
a games programmer background and the C++ (or even C) compilers were the
first things to offer a viable alternative to assembler. History again.

But the last large project I worked on was in VB6 and I certainly don't
think it's a weaker product because of that. We're now writing a mid-sized
ASP.NET system using VB.NET and whilst we did think "shall we try C# a the
same time", the reasons were more that we fancied trying something new, not
that there was a sound business reason for doing so. In fact, quite the
opposite - it would have been slower to develop using C# due to the learning
curve.

And besides, good programmers can program in any langauge :-)

Cheers, Rob.

[Rob Nicholson]

> a programming language, and it has it's place. While it may not be as

powerful as C++ or C#, it's essential to the world. There is a very fine
line

Depends I think how you define "powerful". This web page has some arguments
both ways:

http://blogs.msdn.com/csharpfaq/arch.../11/87816.aspx

Interestingly, VB.NET is getting two of the C# advantages in the next
version: overloading (hmm, not sure that's an advantage, I've been
thoroughly confused by overloading on occasion) and unsigned support.

VB.NET vs. C# is a bit like English versus French. English doesn't care - it
absorbs and expands as required (like VB.NET) whereas C# tries to stay a bit
more pure (like French).

Cheers, Rob.

[Kevin Spencer]

> Interestingly, VB.NET is getting two of the C# advantages in the next

version: overloading (hmm, not sure that's an advantage, I've been
thoroughly confused by overloading on occasion) and unsigned support.

Overloading and unsigned support are nice, I suppose. However, you can get
along quite nicely without them. Not that I consider optional parameters to
be something desirable, but you can certainly use them with VB.Net to obtain
a semblance of overloading. On the other hand, if VB.Net were to support
pointers, without which some apps can't be written, I might think about
using it again. Still, as I'm already quite used to C#, I probably wouldn't
by now!

--
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:%2******** **********@tk2m sftngp13.phx.gb l...

a programming language, and it has it's place. While it may not be as
powerful as C++ or C#, it's essential to the world. There is a very fine
line

Depends I think how you define "powerful". This web page has some
arguments both ways:

http://blogs.msdn.com/csharpfaq/arch.../11/87816.aspx

Interestingly, VB.NET is getting two of the C# advantages in the next
version: overloading (hmm, not sure that's an advantage, I've been
thoroughly confused by overloading on occasion) and unsigned support.

VB.NET vs. C# is a bit like English versus French. English doesn't care -
it absorbs and expands as required (like VB.NET) whereas C# tries to stay
a bit more pure (like French).

Cheers, Rob.

[DotNet Coder]

"Rob Nicholson" <ro***********@ nospam-unforgettable.c om> wrote in message
news:eu******** ******@TK2MSFTN GP15.phx.gbl...

MyMethod()" or something like that. It's not like the Friend keyword
existed in VB6, so it wasn't for backwards compatibility.)
But it was a case of using the same keyword as C++ wasn't it?

C++ had the Friend keyword? I never remember seeing that anywhere, then
again, my C++ is almost as good as my Greek (which in almost
non-existant)... lol

While I don't knock VB/VB.NET programmers, I do look at the language as a
"shortcut" language now a days. Even with .Net and all of MSFT's touting
of
Whilst I'd agree in teh VB6 vs. C++ discussion, VB.NET should really be
classed as a shortcut language. But even if it was - what's actually wrong
with that? :-) In every parts of our lives we try and use as many
shortcuts to make our life easier or to achieve something quicker.

True, but, I think that where you mention later in the post about VB.NET vs.
C# as English vs. French, that argument applies here. I have always noticed
that C/C++/C#/Java/etc developers are usually very touchy about code flow
(for lack of a better term and I am very much one of those types of
people)... "Don't have sloppy code. Don't have unreadable code.". While
shortcuts are great and all (even in C#), having a language like VB6 or
VB.NET, where you have to really hack around some things makes for totally
horrible code. Take for instance, optional parameters... Great concept, but
makes debugging hell, espesically when you inherit the code from someone
else. :-)

abstracts the developer from the things that are happening under the
hood, you can start to see why I call it a shortcut language. (There was
a post in one of the other groups about why VB treats strings differently
than C# does. It goes to the fact of my reasoning).
But in 99% of the cases, this hiding is a good thing IMHO. After all,
aren't using objects and abstraction partly about trying to "hide" the
underlying mechanisms:

Window.SaveAsGI F("c:\wibble.gi f")

Is all about hiding the nasty intricies of GIF LZW (it is LZW isn't it?)
compression.

Sure, but the problem here is that whilst hiding the uglies from the
developer, the developer isn't educated to the fact of WHY the code works.
The developer just KNOWS it works and goes about his or her job oblibious to
what is happening behind the scenes. Not only does hiding and abstraction
like this lead to bad patterns and practices, but it also just promotes more
and more crappy applications being released that don't play nicely out in
the real world. (Although, I have to say that this might be more of a
laziness or newbie problem, rather than the language itself.)

IMHO, I would like to see all developers take an in depth course on Windows
internals before ever writing a single line of code. lol :-)

number compared to the VB developers that wanted it). As this rift
continues to grow, I see yet another period where you have C# developers
(much akin to the C/C++ developers during the VB4~VB6 era) doing more
enterprise-type applications and VB developers doing more
front-end/desktop applications. As long as MSFT doesn't decide to spilt
up the IDE again (Like VS6 and earlier), I think we can all get along.
:-)
But I'd agrue that's still historical in that your back-end guys used C++
in the past whereas your front-end programmers might have used VB6 and
therefore feel more at home with and C# and VB.NET respectively. It's not
because there are some things that VB.NET just can't do.

Well, it did take 3+ versions of the framework to be released before VB.NET
got overloading. That was one thing VB.NET couldn't do ;-)
I used to do most of my programming in C++ but that was because I came
from a games programmer background and the C++ (or even C) compilers were
the first things to offer a viable alternative to assembler. History
again.

But the last large project I worked on was in VB6 and I certainly don't
think it's a weaker product because of that. We're now writing a mid-sized
ASP.NET system using VB.NET and whilst we did think "shall we try C# a the
same time", the reasons were more that we fancied trying something new,
not that there was a sound business reason for doing so. In fact, quite
the opposite - it would have been slower to develop using C# due to the
learning curve.

And besides, good programmers can program in any langauge :-)
Totally agreed on that one :)

Cheers, Rob.

Enjoy!
~d

[cmay]

Another quick reply...

Kevin Spencer wrote:

Is this a good thing? (Answer: no - Late Binding is something to be avoided)
Aside from the places where you are working with some COM interop
function that really makes you need late binding, I have to say that I
whole heartily agree with you.

One of my pet peves is when I am going through some code that another
programmer wrote and they have functions that don't have their return
type specified, or when doing some "quick dirty" function they dim a
variable w/o a type "Dim i". It doesn't fall under this same category,
but it also drives me nuts when VB developers don't declare
functions/subs as public or private, or when they have class level
variables that are declared with "Dim" as opposed to "Private" or
"Public". Maybe I'm a C# guy at heart? :)

Optional Parameters

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

unique to VB.

This is totally true, that the functionality of optional parameters can
be 100% acheived in C# via overloading, but this is actually a case of
the VB *language* having something C# doesn't. A function w/ 15
optional parameters would take a lot longer to write in C# than in VB,
and that would hold true if you were coding in VS.NET or notepad. Now
does a function with 15 optional parameters ring of a good design....
probably not, but there are cases where having a bunch optional
parameters CAN be a good idea.

User filtered Exception trapping

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

I didn't think C# could do this, are you sure? What I am talking about
is the ability in VB.Net to trap a specific error, but only enter the
Catch block if some other condition is met, e.g. Catch ex as
ThreadAbortExce ption When bCatchError = true and GlobalInfo.Serv erName
<> "Developmen t" ... or whatever). If the When condition is not met,
the exception is passed down to the next level, where you might trap it
as a general exception like Catch ex as Exception. I don't think you
can do this in C#, but I am not 100% sure.

Select Case

switch() in C#

With

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

app.
It's my understanding that C# requires the switched var to be a int or
string, while in VB it can be a lot of other types. Also, and probably
more important, is that in C# the expression used in the Case has to be
a compile time value, e.g. case 123, but in VB it can be a variable
Case Me.SomeValue.

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.

Until I read this last paragraph I had actually forgotten about some of
the initial well know differences between the first releases of the 2
products.

I think at one point you couldn't do short circuiting in VB.net... or
maybe it was that they were going to short circut by default, but then
decided against it cause it would break VB6 code? Eitherway, I use the
OrElse and AndAlso quite a bit but think its pretty stupid to have to.
I also forgot about stuff like the "=" overriding that you can do in
C#, which I think you still can't do in VB.

Regarding pointers: agreed. If the project needs pointers, you better
be using C#. No argument.

[cmay]

Derek,

What did you do before you did C# work?
What led you to select C# over VB.Net?

I don't want to get into an argument over your choice or anything, I'm
just curious. :)

Chris

[Rob Nicholson]

> C++ had the Friend keyword? I never remember seeing that anywhere, then

again, my C++ is almost as good as my Greek (which in almost
non-existant)... lol
Yes, I'm pretty sure it had. When it popped up in VB.NET it was a complete
surprise so it must have been C++. Not used anything else!
IMHO, I would like to see all developers take an in depth course on
Windows internals before ever writing a single line of code. lol :-)
Well yes of course that would be ideal :-) But I don't know about you, but I
don't live in an ideal world. I have to deliver to some pretty tight
deadlines! Now maybe if you worked in a pure research environment, then that
would be okay.
Well, it did take 3+ versions of the framework to be released before
VB.NET got overloading. That was one thing VB.NET couldn't do ;-)

Yeah, but I think I said elsewhere, I'm not sure overloading is a good idea
<grin>

1 + 1 = 2

or does it?....

Cheers, Rob.

[cmay]

Just to take it a little further for discussion...

Do you think the ability to work with low level functionality was
something that was ADDED to C#, maybe because those developing the
framework needed it, or MS thought that C++ programmers would be turned
off if they were totally locked out of unmanaged code. Or, do you
think it was NOT INCLUDED with VB.Net because they figured (and
probably correctly) that most people using VB.Net would not be writing
unmanaged code (because they would be using C#) ?

In other words do you think that unmanaged code was a special gift from
MS to C#, or do you think unmanaged code is totally available in .NET
apps, but MS didn't do the work necessary to make it accessible to
VB.Net?

Chris
Kevin Spencer wrote:

I wouldn't think so. As I mentioned, the CLR is full of managed classes that have low-level functionality inside them. I would strongly suspect that some of them use pointers (in fact, a class is technically a pointer to a structure). You can't work with pointers using VB. Therefore, I strongly suspect that the choice of C# was for more practical reasons than developer preference.

[Kevin Spencer]

Hi Chris,

Imagine a programming platform that did NOT give you the ability to do
low-level coding. What good would it be? Sure, it would do quite a bit, but
not everything. And then where would you be? You'd have to write your whole
app in unmanaged code, like C++. That would not be a good selling point for
the platform. Programmers are generally control freaks by nature (at least
the good ones). You don't want to take control away from them. They will
just go somewhere that they can have control.

C# is a superset (extension) of C++, which is a superset of C. Therefore,
everything that is in C is in C++, and everything that is in C++ is in C#.
Any "flavor" of C will have all the components of C.

On the other hand, VB has NEVER supported low-level functionality. VB was
written for people who need to throw something together quick and dirty. It
was never intended as a full-fledged programming language. VB.Net is really
the first version of VB to take a stab at it. But one of the "missions" of
VB is to hide all the inner complexity of applications from developers, to
handle all that technical stuff for them. I believe Microsoft made a gallant
effort there, in terms of elevating the language, but they did have to think
about all those shade-tree VB developers out there who wouldn't know a
pointer from a hole in the ground. Pointers in particular are a difficult
subject to grasp, especially if you don't know how data is stored in memory,
what a variable is, what a data type is, etc. And they are dangerous. So, my
guess is, Microsoft made a compromise, in the interest of losing as few
customers as possible, while elevating existing VB developers to a more
powerful level, understanding data types, using true OOP, etc. Even so, it
seems that many VB people are drowning in the influx of new information. And
let's face it, some people are just too lazy for their own good.

Microsoft has had to walk a virtual tightrope as a result of VB. I can't
fault them for their efforts. As I said, VB wasn't originally designed as a
"true" programming language, more like a "macro" language. Unfortunately,
the rest of the world didn't seem to listen. It became very popular, and
became used in all kinds of professional applications. Now we have an entire
segment of the developer world that uses VB for just about everything. And
that is a problem. Microsoft has had to gradually elevate the language and
its capabilities over the years as a result. I just hope they don't stop!

--
HTH,

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

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

Just to take it a little further for discussion...

Do you think the ability to work with low level functionality was
something that was ADDED to C#, maybe because those developing the
framework needed it, or MS thought that C++ programmers would be turned
off if they were totally locked out of unmanaged code. Or, do you
think it was NOT INCLUDED with VB.Net because they figured (and
probably correctly) that most people using VB.Net would not be writing
unmanaged code (because they would be using C#) ?

In other words do you think that unmanaged code was a special gift from
MS to C#, or do you think unmanaged code is totally available in .NET
apps, but MS didn't do the work necessary to make it accessible to
VB.Net?

Chris
Kevin Spencer wrote:

I wouldn't think so. As I mentioned, the CLR is full of managed

classes that

have low-level functionality inside them. I would strongly suspect

that some

of them use pointers (in fact, a class is technically a pointer to a

structure). You can't work with pointers using VB. Therefore, I

strongly

suspect that the choice of C# was for more practical reasons than

developer

preference.