The Demise of C#

[Guest]

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.

I'm a VB programmer who decided to go to C#. I saw in books how there
seemed to be almost a one-to-one correspondence between C# and VB.Net.
Certainly there's a line-to-line correspondence. I feel that Microsoft will
attempt to do away with VB.NET, they will attempt to slide people into C#.
Also, whether fair or not, it sounds more impress to know "C#", than to know
"VB", even if it's "VB.NET". As you can see in this discussion group, VB has
the reputation of being for, how can I put it, well, people who are a step
below the "pros". I'm not saying this is true, but this seems to be the word
out there.

For all the above rambling reasons, I learned C# at home, even though
I'm still doing VB6 at work (when will they EVER migrate????)

 

[Kevin Spencer]

Microsoft will never do away with VB.Net.

--
HTH,

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

 

[Rob Nicholson]

Certainly there's a line-to-line correspondence. I feel that Microsoft

will
attempt to do away with VB.NET, they will attempt to slide people into C#.

That'll take a long time. They tried to get rid of NT 4 and it's still got a
huge user base. They're trying to get rid of VB6 but there's still many,
many lines of code per day being written in it.

I'm still doing VB6 at work (when will they EVER migrate????)

QED

Cheers, Rob.

 

[cmay]

Wouldn't you think that the reason microsoft would choose C# is because
their developers were previously coding in C++?

C++ developers are not going to learn VB when C# is available.

 

[Kevin Spencer]

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.

--
HTH,

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

 

[Alvin Bruney [ASP.NET MVP]]

out of curiousity, why is your company still writing code in vb6. is it
mainly maintainance or is that new development?

 

[DotNet Coder]

Microsoft will never do away with VB.Net.

(As much as us C# developers would like them to... ;-) (OK, Just Kidding!
sheesh... lol)

On the whole subject, I came from a VB4~VB6 background. I did the whole ASP
thing, COM, COM+ etc using VB and was relatively happy until C# came around.
I have always enjoyed doing back-end systems as opposed to front-end GUIs
and I never realized just how much protection VB offered to the common
developer. Not to mention the fact of how much went on behind the scenes
without my knowledge. Nor do feel that I had a true understanding of what
was going on under the hood when it came to my VB applications. I was
pitifully oblivious to most of it, and I really didn't care. My code was
clean and optimized. It did exactly what it was supposed to and worked (most
of the time) flawlessly. Yet, I did not take the time to actually look at
*why* it worked the way it did or what the VB runtimes were doing in the
background.

I have now been using C# since BETA1 of .NET and I can honestly say that I
am ashamed to look back on some of my old code and code habits and think
"Man, I wrote THAT?!". The semantic differences between the two are simply
mind boggling, IMHO. (Just look at how VB.NET uses the "Friend" keyword. WTH
is up with that?!). (My flame here would be, WTH did MSFT not just use the
same keywords in both languages? I could have dealt with "public friend void
MyMethod()" or something like that. It's not like the Friend keyword existed
in VB6, so it wasn't for backwards compatibility.)

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
the CLR and the languages compiling to the same base, there are simply
things that you can do with C# that you cannot do *easily* (or at all, for
that matter) with VB.NET. Now, if you throw in the fact that VB *still*
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).

Also, with NET 2.0 looming, there is definitely a rift forming between the
languages (and not just in the IDE). The whole debate that was sparked with
E&C should be proof of that. I think I saw a total of 50 C# developers that
actually wanted E&C (ok, I'm exaggerating, but it was a ridiculously low
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.

HTH,
~d

 

[cmay]

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.


This sounds like a good argument. So you are saying that since the
vast majority of .net developers don't use C#'s unmanaged code ability,
it doesn't really matter right?

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?

Why do you get so angry when people talk about real world examples?
How many people write their C# apps in Notepad? I can understand that
you are not happy that VS.net gives VB developers some nice features
that C# developers don't have, but come on, VS.NET is the development
tool most people use. Can't I apply your earlier argument again: I
always write my code w/ VS.net, so it doesn't really matter.

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.

Just to prove I am not mean spirted or trolling, I will absolutely
concede this point. The things I list as VB.NET "HAVES" are nothing
that are going to make a development team say "For this project we HAVE
to use VB, we can't use C#".

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.

Actually, if it were an order of magnitude faster, it would be only be
10 +/- times faster. 100 times faster is 2 orders of magnitude.

In fact, you could not sell such an app. The competition would

kill it.

Yes, I agree. However, let me ask a few questions: If this app was so
performance intensive, why not write the whole product in unmanaged
code? Q2: How would your C# app perform against an app written in 95%
VB.NET, w/ 5% written in C# to do the unmanaged code? I'm guessing
pretty similar.

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

There is 1 difference that is not trivial, and that is productivity. I
know you argued that this was not due to VB.Net, but in fact was simply
a feature of VS. From an analitical standpoint, this may be right
(although the previous poster seemed pretty sure it was due to things
within the language module, but I don't know about that so I won't
pretend to) in practice you can develop many applications faster in
VB.net than C#. Part of the intellisense benefits of VB.NET simply
cannot be implemented in C# because of how ECMA script works. VB puts
the type after "As" so the IDE knows to provide you with intellisense.
This can't work the same in C# because you declare the type first.


Now, you are talking about real value vs trivial conveniences... How
about "this web application will take 100 days in VB.Net, or 130 days
in C#", or "to complete this project in time we need 3 VB.net
developers, or 4 C# developers". That is real value. I know you will
say that I am simply not good enough in C# and that is the only reason
why I feel vb.net is quicker to develop in, but I won't agree with that
argument.

The amount of time that the VS.Net IDE saves a developer who chooses VB
is something to be seriously considered. Is this added productivity
due to VBs use of "Dim"? No, of course not, and if I had to use
notepad and command line compiler (which I have done), I would not
suggest that VB is still more productive. But as long as I am working
in VS.Net, my choice to write as much code in VB.net will result in
more productivity.

 

[Guest]

I really dislike when people try to say a language is 'dying', especially
when I've worked so hard to become a respected developer in said language.
But the sad truth is I've wondered myself about the security of C#. It's
awsome, it's almost too awsome, but platform dependance has kept it from
growing like it ought. C# is like the evolution of C++, In My Opinion. The
..NET Framework has given us so much power that we never had before, at such
an introductory level. Sure, you can do everything in C# in many other
languages, but the simplicity and streamlined process is so improved in C#.
It truely is a marvel in engineering and thought.

I've knocked VB.NET/VB6 for a long time, but in all honesty, Visual Basic is
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
where Visual Basic loses power to C#, and I believe that line is getting
further and further away with everything the VB community does. They
certainly are a hearty bunch who know what they are doing. I don't think VB
is going anywhere.

 

[Guest]

I did not come from a pure C++ background. I chose C# because it was so much
cleaner and object oriented right from the start than C++. I liked how it was
so adaptable to GUI implementation, and how the Visual Studio IDE made
development much easier. I hate sloppy code, and I dispise RAD Tools, but C#
was just so well done that I couldn't help but be drawn to it.

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.VisualBasic NameSpace. This
doesn't mean that you can't do those things with C#. In fact, the
Microsoft.VisualBasic 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.Replace().

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.

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

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.

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. "MustInherit", "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
"MustInherit"
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...

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
--------------------------------------------------


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.




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/forumvbcode/post10017013.aspx
http://www.eggheadcafe.com/articles/adonet_source_code_generator.asp



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.SaveAsGIF("c:\wibble.gif")

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/archive/2004/03/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.

 

[DotNet Coder]

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

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.

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.SaveAsGIF("c:\wibble.gif")

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

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...

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 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.

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
ThreadAbortException When bCatchError = true and GlobalInfo.ServerName
<> "Development" ... 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.

switch() in C#


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]

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.