The Demise of C#

[Guest]

Very nice book Carl. You should someday take find some free time and write an
article and have it published. That said I feel that VB.NET or C# or
DELPHI.NET or C++.NET have all one thing in common: they can be decompiled.
When you talk about decompilation you can talk about decompiling a VB.NET to
C#, C++.NET, DELPHI.NET and vis-versa. You can decompile your own code to
another language and check out the syntax change and so on... I am a VB, ASP,
C++, C#, JAVA, and you name it coder. In other words a consultant. You can
say I have done it all! The worst of all the code I have seen in my life was
obviously C++ code which even the scriptic Perl is easier to read. You see
Java, VB, C#, and other language alike is so much easier to follow and read.
Most companies I have written MFC or ATL programs and components did not
require any UML and as a matter of fact UML or RUP has become the biggest
topic nowadays and most company's hiring manager and team presume a C++ guys
has a very solid grasp on it while truth of the matter only system analysts
of the past did?! I really don't understand when a job presents a Web
Developer position to require 3 years of C# (they have this one close enough)
and preferably 5 years of C++ developement to include SQL programming of
stored procedure! Pathetic enough that I wrote a reply to this job
description and gently told them that they are Idiots!

Thanks for you little book,

~yamazed

 

[Guest]

I disagree with the above statement because VBScript and VB.NET have little
in common other then the name. That would be like saying that a person who
know JavaScript can program in Java.

I think you are missing the point of what Steve was saying.

Most ASP developers used VBScript as their language (you can also use
JScript). When these people, who are experienced web application developers,
began to work with .NET, most of them would likely choose to work with VB.NET
as their language of choice, where as C++ developers would likely select C#
as their language.

The point is not that prior experience w/ VBScript makes someone a better
VB.NET programmer.

The point is that prior experience creating web based applications will tend
to make someone a better ASP.NET developer.

 

[Guest]

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.

 

[Kevin Spencer]

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.

--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://SteveOrr.net


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.

 

[Guest]

why do you think C# is doomed/demised, etc?... it's just a language, a tool
and nothing more. it will continue to exist if Microsoft continues to support
it, just like VB6 or any other language. J# or J++ - now there's a doomed
pair!

i came from VB6/COM up through ASP/vbscript/javascript/html and when .Net
came out i considered taking the VB.Net route but doing C# was more
challenging and the code looked cleaner. i never considered pay. a good
VB.Net programmer can make just as much as a good C#'er. the jobs pay equally
well from what i've seen out there while recently looking for a job.

our field requires us to learn the new languages/tools as they are accepted
by the market. such is our lot. an experienced programmer picks up on trends
and tries not to learn a tool that will not last in the market place. limited
resources/time require this approach. one thing that a C# developer has over
a VB.Net'er is that C# is very close in syntax and implementation of Java. so
if C# tanks and Java trumps, i'll switch to Java. but by then, perhaps
"C-flat" will be out from Microsoft )

Cheers!

Live and Learn. But don't forget to LIVE!

 

[Kevin Spencer]

why do you think C# is doomed/demised, etc?... it's just a language, a

tool
and nothing more. it will continue to exist if Microsoft continues to
support
it, just like VB6 or any other language. J# or J++ - now there's a doomed
pair!

Did you read my message? While the title of it was a bit provocative, what I
was referring to was the demise of C# as a measuring stick to measure
developers. I don't expect it to disappear or fall into disfavor somehow.

--
HTH,

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

 

[Guest]

It would be nice if people started their thinking inside the box before
venturing outside!

If you are going to wite in any particular language, just as you might have
to be a programmer one day and an analyst the next, you have to put the hat
on for that role. For C++, C#, etc., you might need to be thinking in OO
terms, for scripting, in more process oriented terms, in SQL you think
differently again.

I think that VB.NET and C# are too close for comfort, and as a user of both,
my feeling is that one could be phased out - but hey, that's just my view. I
prefer C# (although I still like VB), but then I came from a C, C++
background. I only started using VB about 10 years ago because as a manager
on a project, I couldn't get C++ developers at the time, but had some decent
VB developers at my disposal. We still built a pretty good system in both VB4
and VB5.

But lets not forget that C# for all its goodness is still not C++, and isn't
targeted at low level system development. It would be interesting to know
where Micorosft think VB and C# will go - especially with relation to what
happens to VBA in Word, Access, Excel, etc.

I haven't used COBOL for 14 years, maybeee we should all convert to
COBOL.NET so I can ressurect some old skills (or not)

 

[Guest]

I agree that C# programmers should not be worth more than VB.NET programmers
in any employers eyes.

Originally VB developers tended to be the core RAD /prototype developers and
C# developers came from the more technical school. Both schools have their
advantage. Technical developers don't tend to generate projects as fast but
have the level of understanding needed to deal with complex technology (ie.
security, threading issues, mutex, system internals). VB(traditional
visual) developers tend to be much better in a world of rapid development
where companies are not building mission critical systems.

I have always felt that the C syntax is much cleaner than the VB syntax and
I am not sure I would miss it much. At the same time, I like tools to be
more dedicated to my technical mindset and I don't like interfaces that dumb
down the process for me in order to better support RAD development. I
probably would have stuck to C++ but before C++/CLI it was a real mess.

I was originally very much against the visual school of development because
I felt that the ability to quickly develop code through visual means would
lead to heavily UI centric development rather than need-centric development
and constrain an industry that already is fairly poor at meeting it's
customers needs.

I think that perhaps a break in certification would be a better tool for
employers to judge their employees skill sets. It should be heavily
discouraged for employers to think that C# is better than VB.NET. The real
question is which langauge is going to provide for better coordination
between programmers in any endeavor.

Perhaps something like this.. (This is just a starting point)

MCAD for RAD (targetted for non-technical people
- current MCAD with a leaning on how to generate code using UI tools
- a lessened focus on the APIs and more focus on how do I do this
- focus on using existing tools rather than implementing new ones (ie.
ActiveX controlls, Datagrid controls, et al)

Microsoft Managment Software Development
- Basic lifecycle using MSF (stressing iterative, OOD, SOA, and Pattern
based development at a high level)
- How to hire and pick the appropriate people for the job at hand /
psychology of computer programming
- Project management
- Software Metrics - cost estimation, project monitoring through metrics
- How to apply software to business problems

MCSE
-MCAD for RAD req
-MMSD (exclude hiring req)
- Modeling problems using current methodologies
- How to taylor software lifecycle process to the current project

MCAD Technical
- How to implement secure code
- How to write code for multiprocessing environments (multithreading / mutex)
- How to write software components (COM, .NET, Enterprise services)
- Principle APIs knowledge for either Windows or Web development (.NET)
- XML/ data API knowledge
- Dealing with legacy code (COM, Win32)
- 64 bit portability issues
- One of a couple options:
MDBA
Server Family Knowledge (one product - comprehensive)
DDI knowledge / System internals
Legacy / Non-MS system interop
Test / Debug - kd, test harnesses, stubbing, test driven development, et al.

MCSE Enterprise
-MCAD Technical (Windows and Web)
-MMSD (exclude hiring req)
- Modeling problems using current methodologies
- How to taylor software lifecycle process to the current project

I guess my requirements are a bit high but I feel people need most of these
skills to do their jobs.

The relative target numbers (IMHO) assigning 1 to MCAD for RAD with 1/5
meaning there would be 1 for every 5 MCAD for RAD in an organization.

1 MCAD for RAD
1/5 MCSE
1/10 MMSD
1/10 MCAD Technical
1/50 MCSE Enterprise

 

[Kevin Spencer]

You make some good points, Shaun. However, I don't believe changing
certification requirements is going to change anything. There are already
plenty of people out there who have crammed for one or more certifications
and received them, and can't program their way out of a paper bag.

Still, you raise a good question, which is, how does an employer determine
the skill level of a prospective candidate? And that question is not easily
answered. I know how I evaluate developers, but I'm not sure I could
quantify it easily. It's a combination of experience and intuition.

--
HTH,

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

 

[Guest]

I agree that test crunching is a problem and I don't think there is really
any solution there. Still certifications are better than nothing. They can
be used to somewhat filter talent.

Ultimately, the only way to tell that someone is qualified is to have a
known quantity speak to the person in question. It is hard to fake knowledge
when you are talking to someone who knows the issues. People tend to be
unpredictable and are much harder to fake than tests. If it wasn't cost
prohibitive, the certification process might work better if it included
either short live interviews with people who knew the material, code reviews
or both. Some companies might be willing to pay for this information.

People don't seem to be good at judging the quality of technical expertise.

 

[Martin Dechev]

Hi,

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.

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.

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.

--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://SteveOrr.net


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.

 

[Guest]

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?

 

[Guest]

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.

 

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

 

[cmay]

So, in fact, while C# can do anything that VB.Net can, VB.Net can not
do
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]

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.

 

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

 

[gerry]

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

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?


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.

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


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 is really a wrapper for overloading. It is not unique to

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.

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


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.

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.

 

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