extreme basics: The Demise of C#

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.When it comes to ASP.NET development, I'd think VB developers stand the
better chance of being more experienced, since classic ASP used VBScript.
C++ programmers, while they might be smart people, don't necessarily know
anything about web development, so C++ experience wouldn't necessarily
impress me when interviewing for a web developer. C++ experience would
probably only excite me if I was hiring a developer for creating low level
software such drivers.

Then again, I've always been more of a VB guy so perhaps I'm biased. But my
experience tells me you don't need to be from C land to be a solid
developer. That's really little more than a stereotype, and prospective
employees shouldn't be evaluated based on assumptions and stereotypes.

--
That's my two cents,
Steve C. Orr, MCSD, MVP
http://SteveOrr.net

"Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
news:%23XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
> seeing many posts about what language to use with ASP.Net. The consensus
> was that employers paid more for C# programmers, and it seems that C#
> became the darling of the ASP.Net crowd.
> In the meantime, I have observed an interesting phenomenon. Originally,
> employers hired programmers who used C# because it was based on C, and the
> prevailing opinion was (and may still be) that C# developers were better
> because they must have known and/or practiced C or C++ at some time, which
> would make them better programmers overall. C and C++ are hard-core
> programming languages compared to VB.
> However, now that nearly everyone has jumped on the C# bandwagon, it seems
> to me that the distinction between the languages has nearly disappeared,
> at least in terms of evaluating programmers for hire. There seem to be
> almost as many clueless C# developers out there as VB.Net developers. Many
> C# developers today are basically VB.Net developers using a different
> syntax. I wonder if the employers have become aware of this trend?
> --
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> Neither a follower nor a lender be.
Two random thoughts on this:

..NET is simply too intimidating for many of the incompetent VB developers
(which is not all VB developers). They had their fun with VB6 - but .NET is
simply too much for the incompetent ones - regardless of .NET languagage (C#
or VB.NET). This point is beyond my opinion - as over the past couple of
years various industry journals have documented how Microsoft is trying to
dumb down VB.NET in an effort to get more people to migrate to .NET (because
the VB6 crowd didn't come running as initially hoped for by Microsoft). Just
look at the features they're adding to VB.NET.

IMHO, the incompetence you are seeing more of is people jumping to Web
development from desktop/thick client application development. Take any
"hard core" C++ developer awash in all his/her OOP glory: If this person has
never developed for the Web and has instead spent a career doing low-level
programming (device drivers, etc), and throw them into a Web Application,
they'll probably be asking a lot of dumb questions - of the same sort you
are currently attributing to the VB6 crowd. IMHO, it's the application type
(Web vs desktop), not the prior language.

FWIW

-Smithers

I also agree that a solid understanding of HTML, HTTP, and the web are very
important to ASP.Net (critically important, actually).

> But my
> experience tells me you don't need to be from C land to be a solid
> developer.

I agree here as well, with one caveat: You don't need to know C to be a
solid developer, but it sure helps! I could elaborate on why, but again, I'm
really not interested in a debate about languages!

> prospective employees shouldn't be evaluated based on assumptions and
> stereotypes.

I've always agreed with that point!

Actually, I wasn't trying to dredge up the old argument about which language
is "better." I was actually remarking on the trend toward hiring developers
who know C#, and whether it was valid or not any more.

My point is NOT that a VB developer is necessarily not as strong as a C#
developer. However, at one point there was at least some statistical
evidence that C# developers were more likely to be skilled than VB
developers, due to their background, hence the trend. You know the old
adage: The race is not always to the swift, nor the battle to the strong,
but that's how you bet. I just don't believe that the language is useful any
more as a general (statistical) measuring stick.

And I'm wondering what the hiring trend is these days, whether it has
adjusted with the times. My guess would be "not yet." Corporate types are
generally slow to catch up.

--
HTH,

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

"Steve C. Orr [MVP, MCSD]" <Steve@dotnet.itags.org.Orr.net> wrote in message
news:e$HQ6qSGFHA.2932@dotnet.itags.org.TK2MSFTNGP15.phx.gbl...
> When it comes to ASP.NET development, I'd think VB developers stand the
> better chance of being more experienced, since classic ASP used VBScript.
> C++ programmers, while they might be smart people, don't necessarily know
> anything about web development, so C++ experience wouldn't necessarily
> impress me when interviewing for a web developer. C++ experience would
> probably only excite me if I was hiring a developer for creating low level
> software such drivers.
> Then again, I've always been more of a VB guy so perhaps I'm biased. But
> my experience tells me you don't need to be from C land to be a solid
> developer. That's really little more than a stereotype, and prospective
> employees shouldn't be evaluated based on assumptions and stereotypes.
> --
> That's my two cents,
> Steve C. Orr, MCSD, MVP
> http://SteveOrr.net
>
> "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> news:%23XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
>> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
>> seeing many posts about what language to use with ASP.Net. The consensus
>> was that employers paid more for C# programmers, and it seems that C#
>> became the darling of the ASP.Net crowd.
>>
>> In the meantime, I have observed an interesting phenomenon. Originally,
>> employers hired programmers who used C# because it was based on C, and
>> the prevailing opinion was (and may still be) that C# developers were
>> better because they must have known and/or practiced C or C++ at some
>> time, which would make them better programmers overall. C and C++ are
>> hard-core programming languages compared to VB.
>>
>> However, now that nearly everyone has jumped on the C# bandwagon, it
>> seems to me that the distinction between the languages has nearly
>> disappeared, at least in terms of evaluating programmers for hire. There
>> seem to be almost as many clueless C# developers out there as VB.Net
>> developers. Many C# developers today are basically VB.Net developers
>> using a different syntax. I wonder if the employers have become aware of
>> this trend?
>>
>> --
>>
>> Kevin Spencer
>> Microsoft MVP
>> .Net Developer
>> Neither a follower nor a lender be.
>>
>>
> When it comes to ASP.NET development, I'd think VB developers stand the
> better chance of being more experienced, since classic ASP used VBScript.
> C++ programmers, while they might be smart people, don't necessarily know

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.

"Steve C. Orr [MVP, MCSD]" <Steve@dotnet.itags.org.Orr.net> wrote in message
news:e$HQ6qSGFHA.2932@dotnet.itags.org.TK2MSFTNGP15.phx.gbl...
> When it comes to ASP.NET development, I'd think VB developers stand the
> better chance of being more experienced, since classic ASP used VBScript.
> C++ programmers, while they might be smart people, don't necessarily know
> anything about web development, so C++ experience wouldn't necessarily
> impress me when interviewing for a web developer. C++ experience would
> probably only excite me if I was hiring a developer for creating low level
> software such drivers.
> Then again, I've always been more of a VB guy so perhaps I'm biased. But
my
> experience tells me you don't need to be from C land to be a solid
> developer. That's really little more than a stereotype, and prospective
> employees shouldn't be evaluated based on assumptions and stereotypes.
> --
> That's my two cents,
> Steve C. Orr, MCSD, MVP
> http://SteveOrr.net
>
> "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> news:%23XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
> > About 2 years ago, and as recently as perhaps 1 year ago, I can recall
> > seeing many posts about what language to use with ASP.Net. The consensus
> > was that employers paid more for C# programmers, and it seems that C#
> > became the darling of the ASP.Net crowd.
> > In the meantime, I have observed an interesting phenomenon. Originally,
> > employers hired programmers who used C# because it was based on C, and
the
> > prevailing opinion was (and may still be) that C# developers were better
> > because they must have known and/or practiced C or C++ at some time,
which
> > would make them better programmers overall. C and C++ are hard-core
> > programming languages compared to VB.
> > However, now that nearly everyone has jumped on the C# bandwagon, it
seems
> > to me that the distinction between the languages has nearly disappeared,
> > at least in terms of evaluating programmers for hire. There seem to be
> > almost as many clueless C# developers out there as VB.Net developers.
Many
> > C# developers today are basically VB.Net developers using a different
> > syntax. I wonder if the employers have become aware of this trend?
> > --
> > Kevin Spencer
> > Microsoft MVP
> > .Net Developer
> > Neither a follower nor a lender be.
Okay, I write this message with the full knowledge that I am going to piss a
large number of people off. So I fully expect some flaming to happen.

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

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

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

"Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
news:#XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
> seeing many posts about what language to use with ASP.Net. The consensus
was
> that employers paid more for C# programmers, and it seems that C# became
the
> darling of the ASP.Net crowd.
> In the meantime, I have observed an interesting phenomenon. Originally,
> employers hired programmers who used C# because it was based on C, and the
> prevailing opinion was (and may still be) that C# developers were better
> because they must have known and/or practiced C or C++ at some time, which
> would make them better programmers overall. C and C++ are hard-core
> programming languages compared to VB.
> However, now that nearly everyone has jumped on the C# bandwagon, it seems
> to me that the distinction between the languages has nearly disappeared,
at
> least in terms of evaluating programmers for hire. There seem to be almost
> as many clueless C# developers out there as VB.Net developers. Many C#
> developers today are basically VB.Net developers using a different syntax.
I
> wonder if the employers have become aware of this trend?
> --
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> Neither a follower nor a lender be.
There are plenty of clueless C++, VB, et al, developer.

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

"Kevin Spencer" wrote:

As a long-time VB person who fumbles with C#, I'm one of those "VB.Net
developers using a different syntax."

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/for...st10017013.aspx
http://www.eggheadcafe.com/articles...e_generator.asp

It wasn't because they saw C# as superior to VB.NET in any way.

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

"Robbe Morris [C# MVP]" <info@dotnet.itags.org.turnkeytools.com> wrote in message
news:OyR3DzTGFHA.1528@dotnet.itags.org.TK2MSFTNGP09.phx.gbl...
> When I saw that when deciding whether to continue on with VB.NET
> (I was an old VB 6 and a C# coder), I went with C#.
> I figured if the Microsoft guys saw fit to use C#, maybe I should too.
> There must be a reason they picked it.
> --
> 2005 Microsoft MVP C#
> Robbe Morris
> http://www.robbemorris.com
> http://www.mastervb.net/home/ng/for...st10017013.aspx
> http://www.eggheadcafe.com/articles...e_generator.asp
>
> "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> news:%23XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
>> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
>> seeing many posts about what language to use with ASP.Net. The consensus
>> was that employers paid more for C# programmers, and it seems that C#
>> became the darling of the ASP.Net crowd.
>>
>> In the meantime, I have observed an interesting phenomenon. Originally,
>> employers hired programmers who used C# because it was based on C, and
>> the prevailing opinion was (and may still be) that C# developers were
>> better because they must have known and/or practiced C or C++ at some
>> time, which would make them better programmers overall. C and C++ are
>> hard-core programming languages compared to VB.
>>
>> However, now that nearly everyone has jumped on the C# bandwagon, it
>> seems to me that the distinction between the languages has nearly
>> disappeared, at least in terms of evaluating programmers for hire. There
>> seem to be almost as many clueless C# developers out there as VB.Net
>> developers. Many C# developers today are basically VB.Net developers
>> using a different syntax. I wonder if the employers have become aware of
>> this trend?
>>
>> --
>>
>> Kevin Spencer
>> Microsoft MVP
>> .Net Developer
>> Neither a follower nor a lender be.
>>
>>
I believe they did. (can of worms here)

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

--
Regards
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
----------------

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

This may be true today, but it's equally important to look at where the
languages are going. It seems to me that in the 2.0 release, we are
starting to see a divergence, albeit slight, between the two language which
i expect will be a continuing trend. I agree that refactoring is only a
tool which can easily be done as an addon, but that the C# IDE supports it
and the VB.Net one doesn't suggests that the VB.Net team sees the needs of
its developers as being different than those of C# developers. Other
features such as My, Iterators and enhanced nullable types which are either
in one language or another (anonymous functions in vb.net??) are all signs
that MS is moving away from having the languages simply be "different
syntax".

As far as the crappiness of VB programmers which was touched on by others,
my personal opinion is that the programming language doesn't make the
quality, it's the person behind the keyboard. A bad programmer will
programming equally bad using whichever language. I think the belief that
there are simply more bad VB programmers out there is highly speculative and
even if true, an HR departement would be foolish to ignore the fact that
there are plenty of good programmers in either language. Having said that,
VB.Net does make it a little easier to be sloppy (option explicit and
strict, on error resume next, ...), but I'm sure that if someone wanted to
they could come up, item for item, of a list of things C# allows which could
be argued it shouldn't.

Karl
--
MY ASP.Net tutorials
http://www.openmymind.net/

"Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
news:%23XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
> seeing many posts about what language to use with ASP.Net. The consensus
was
> that employers paid more for C# programmers, and it seems that C# became
the
> darling of the ASP.Net crowd.
> In the meantime, I have observed an interesting phenomenon. Originally,
> employers hired programmers who used C# because it was based on C, and the
> prevailing opinion was (and may still be) that C# developers were better
> because they must have known and/or practiced C or C++ at some time, which
> would make them better programmers overall. C and C++ are hard-core
> programming languages compared to VB.
> However, now that nearly everyone has jumped on the C# bandwagon, it seems
> to me that the distinction between the languages has nearly disappeared,
at
> least in terms of evaluating programmers for hire. There seem to be almost
> as many clueless C# developers out there as VB.Net developers. Many C#
> developers today are basically VB.Net developers using a different syntax.
I
> wonder if the employers have become aware of this trend?
> --
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> Neither a follower nor a lender be.
> There is nothing that you can do in C# that you cannot do in VB.NET.

I'm afraid that's simply untrue. You can't use unmanaged code in VB,
pointers, and several other less important items. Yes, it may be a rare
occasion that you need to, but believe it or not, I've worked on several
projects over the past year which process very large (200 - 500 MB) images,
and there's no substitute for pointers in a situation like that. In fact,
even with the use of pointers, I have one app that takes several hours to
process a single image.

--
HTH,

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

"Peter Rilling" <peter@dotnet.itags.org.nospam.rilling.net> wrote in message
news:O6eVNATGFHA.3728@dotnet.itags.org.TK2MSFTNGP14.phx.gbl...
> Okay, I write this message with the full knowledge that I am going to piss
> a
> large number of people off. So I fully expect some flaming to happen.
> As languages evolve, there becomes less and less that differentiates them.
> There is nothing that you can do in C# that you cannot do in VB.NET.
> I came from a VB development background and moved to C# about five years
> ago. I do not necessarily think that companies look for C# people because
> of the tie-in with C++, but rather that C# develops have more of an OOP
> sense about them. C++ and C# are object oriented languages and therefore
> those people tend to think in object design. VB used to be thought of a
> toy
> and only used for RAD development. There was little emphasis placed on
> proper coding styles. It was more of a "let's get it done" mentality
> rather
> then "let's design something for expandability and maintainability". Keep
> in mind that until VB.NET was released, the concept of classes was shoddy
> at
> best and certainly did not have inheritance or polymorphism, which means
> that VB was NEVER an object oriented languages.
> Remember that when the GUI first came out it was also thought of as a toy.
> Why would real computer uses use a graphical interface, was the mantra of
> my
> command-line gurus.
> "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> news:#XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
>> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
>> seeing many posts about what language to use with ASP.Net. The consensus
> was
>> that employers paid more for C# programmers, and it seems that C# became
> the
>> darling of the ASP.Net crowd.
>>
>> In the meantime, I have observed an interesting phenomenon. Originally,
>> employers hired programmers who used C# because it was based on C, and
>> the
>> prevailing opinion was (and may still be) that C# developers were better
>> because they must have known and/or practiced C or C++ at some time,
>> which
>> would make them better programmers overall. C and C++ are hard-core
>> programming languages compared to VB.
>>
>> However, now that nearly everyone has jumped on the C# bandwagon, it
>> seems
>> to me that the distinction between the languages has nearly disappeared,
> at
>> least in terms of evaluating programmers for hire. There seem to be
>> almost
>> as many clueless C# developers out there as VB.Net developers. Many C#
>> developers today are basically VB.Net developers using a different
>> syntax.
> I
>> wonder if the employers have become aware of this trend?
>>
>> --
>>
>> Kevin Spencer
>> Microsoft MVP
>> .Net Developer
>> Neither a follower nor a lender be.
>>
>>
> There are plenty of clueless C++, VB, et al, developer.

True. But that's like saying there are plenty of terrorists in Iraq.
Statistically speaking, they are still in the minority.

Employers often make decisions based on statistics or trends. While it is
impossible to predict an individual outcome, statistics provide a calculated
risk factor, which, in the past, affected their decisions with regard to
hiring .Net programmers that did not know C#. Statistically, C# programmers
were paid more, and hired more.

My observation was simply that with the blooming popularity of C#, and the
enormous number of VB.Net developers learning the syntax, language could
potentially no longer be a statistical factor to employers, and probably
should NOT be. And I was wondering what the trends are.

--
HTH,

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

"Cowboy (Gregory A. Beamer) - MVP" <NoSpamMgbworld@dotnet.itags.org.comcast.netNoSpamM> wrote
in message news:9610584B-5609-44D4-8B28-05BF390FD70B@dotnet.itags.org.microsoft.com...
> There are plenty of clueless C++, VB, et al, developer.
>
> --
> Gregory A. Beamer
> MVP; MCP: +I, SE, SD, DBA
> ***************************
> Think Outside the Box!
> ***************************
> "Kevin Spencer" wrote:
>> 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 don't know what employers are aware of, but they do seem to request C#
>more than VB.NET.

Now, THAT's what I was asking about! :)

> As a long-time VB person who fumbles with C#, I'm one of those "VB.Net
> developers using a different syntax."

Somehow, Ken, I have a hard time imaginging you "fumbling." ;-)

--
HTH,

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

"Ken Cox [Microsoft MVP]" <BANSPAMken_cox@dotnet.itags.org.sympatico.ca> wrote in message
news:%23ESiLFTGFHA.3664@dotnet.itags.org.TK2MSFTNGP15.phx.gbl...
>I don't know what employers are aware of, but they do seem to request C#
>more than VB.NET.
> As a long-time VB person who fumbles with C#, I'm one of those "VB.Net
> developers using a different syntax."
>
> "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> news:%23XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
>> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
>> seeing many posts about what language to use with ASP.Net. The consensus
>> was that employers paid more for C# programmers, and it seems that C#
>> became the darling of the ASP.Net crowd.
>>
>> In the meantime, I have observed an interesting phenomenon. Originally,
>> employers hired programmers who used C# because it was based on C, and
>> the prevailing opinion was (and may still be) that C# developers were
>> better because they must have known and/or practiced C or C++ at some
>> time, which would make them better programmers overall. C and C++ are
>> hard-core programming languages compared to VB.
>>
>> However, now that nearly everyone has jumped on the C# bandwagon, it
>> seems to me that the distinction between the languages has nearly
>> disappeared, at least in terms of evaluating programmers for hire. There
>> seem to be almost as many clueless C# developers out there as VB.Net
>> developers. Many C# developers today are basically VB.Net developers
>> using a different syntax. I wonder if the employers have become aware of
>> this trend?
>>
>> --
>>
>> Kevin Spencer
>> Microsoft MVP
>> .Net Developer
>> Neither a follower nor a lender be.
>>
>
> This may be true today, but it's equally important to look at where the
> languages are going. It seems to me that in the 2.0 release, we are
> starting to see a divergence, albeit slight, between the two language
> which
> i expect will be a continuing trend. I agree that refactoring is only a
> tool which can easily be done as an addon, but that the C# IDE supports it
> and the VB.Net one doesn't suggests that the VB.Net team sees the needs of
> its developers as being different than those of C# developers. Other
> features such as My, Iterators and enhanced nullable types which are
> either
> in one language or another (anonymous functions in vb.net??) are all signs
> that MS is moving away from having the languages simply be "different
> syntax".

Very interesting point, Karl. Unfortunately, I think you may be right. I
only say unfortunately because I saw VB.Net as a chance to elevate existing
VB programmers to a deeper understanding of programming, which makes one a
better programmer overall. I have long resented the "dumbing down" of
programming that VB provided, allowing people to manipulate data that they
didn't have to understand. It sounds like Microsoft is backing away from
that bold move, and going back to the old "let the programmers be ignorant"
philosophy, which, IMHO, has resulted in a lot of poor programmers, and a
lot of poor programming.

> As far as the crappiness of VB programmers which was touched on by others,
> my personal opinion is that the programming language doesn't make the
> quality, it's the person behind the keyboard.

Absolutely. My point was that this is statistically more true today than
several years ago.

--
HTH,

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

"Karl Seguin" <karl REMOVE @dotnet.itags.org. REMOVE openmymind REMOVEMETOO . ANDME net>
wrote in message news:uRNRvVaGFHA.4004@dotnet.itags.org.tk2msftngp13.phx.gbl...
> "Many C# developers today are basically VB.Net developers using a
> different
> syntax"
> This may be true today, but it's equally important to look at where the
> languages are going. It seems to me that in the 2.0 release, we are
> starting to see a divergence, albeit slight, between the two language
> which
> i expect will be a continuing trend. I agree that refactoring is only a
> tool which can easily be done as an addon, but that the C# IDE supports it
> and the VB.Net one doesn't suggests that the VB.Net team sees the needs of
> its developers as being different than those of C# developers. Other
> features such as My, Iterators and enhanced nullable types which are
> either
> in one language or another (anonymous functions in vb.net??) are all signs
> that MS is moving away from having the languages simply be "different
> syntax".
> As far as the crappiness of VB programmers which was touched on by others,
> my personal opinion is that the programming language doesn't make the
> quality, it's the person behind the keyboard. A bad programmer will
> programming equally bad using whichever language. I think the belief that
> there are simply more bad VB programmers out there is highly speculative
> and
> even if true, an HR departement would be foolish to ignore the fact that
> there are plenty of good programmers in either language. Having said
> that,
> VB.Net does make it a little easier to be sloppy (option explicit and
> strict, on error resume next, ...), but I'm sure that if someone wanted
> to
> they could come up, item for item, of a list of things C# allows which
> could
> be argued it shouldn't.
> Karl
> --
> MY ASP.Net tutorials
> http://www.openmymind.net/
>
> "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> news:%23XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
>> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
>> seeing many posts about what language to use with ASP.Net. The consensus
> was
>> that employers paid more for C# programmers, and it seems that C# became
> the
>> darling of the ASP.Net crowd.
>>
>> In the meantime, I have observed an interesting phenomenon. Originally,
>> employers hired programmers who used C# because it was based on C, and
>> the
>> prevailing opinion was (and may still be) that C# developers were better
>> because they must have known and/or practiced C or C++ at some time,
>> which
>> would make them better programmers overall. C and C++ are hard-core
>> programming languages compared to VB.
>>
>> However, now that nearly everyone has jumped on the C# bandwagon, it
>> seems
>> to me that the distinction between the languages has nearly disappeared,
> at
>> least in terms of evaluating programmers for hire. There seem to be
>> almost
>> as many clueless C# developers out there as VB.Net developers. Many C#
>> developers today are basically VB.Net developers using a different
>> syntax.
> I
>> wonder if the employers have become aware of this trend?
>>
>> --
>>
>> Kevin Spencer
>> Microsoft MVP
>> .Net Developer
>> Neither a follower nor a lender be.
>>
>>
> Somehow, Ken, I have a hard time imagining you "fumbling." ;-)

Ha! See my previous answers to C# questions! <grin
> It wasn't because they saw C# as superior to VB.NET in any way.

No, it wasn't because they saw C# as superior. However, I'm sure it was
because C# could do things at lower levels that VB.Net could not. There is a
lot of unmanaged code at the bottom of the .Net platform.

--
HTH,

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

"Steve C. Orr [MVP, MCSD]" <Steve@dotnet.itags.org.Orr.net> wrote in message
news:OT3v22TGFHA.3928@dotnet.itags.org.TK2MSFTNGP09.phx.gbl...
> The main reasons they went with C# is because they were experienced with
> C++ (becuase C++ was more powerful than VB6) so it was more of a natural
> progression for them, and the other reason was because C# was the "new"
> language and they wanted to eat their own dog food to ensure C# would
> become capable of all that they'd envisioned and all they needed.
> It wasn't because they saw C# as superior to VB.NET in any way.
> --
> I hope this helps,
> Steve C. Orr, MCSD, MVP
> http://SteveOrr.net
>
> "Robbe Morris [C# MVP]" <info@dotnet.itags.org.turnkeytools.com> wrote in message
> news:OyR3DzTGFHA.1528@dotnet.itags.org.TK2MSFTNGP09.phx.gbl...
>> When I saw that when deciding whether to continue on with VB.NET
>> (I was an old VB 6 and a C# coder), I went with C#.
>>
>> I figured if the Microsoft guys saw fit to use C#, maybe I should too.
>> There must be a reason they picked it.
>>
>> --
>> 2005 Microsoft MVP C#
>> Robbe Morris
>> http://www.robbemorris.com
>> http://www.mastervb.net/home/ng/for...st10017013.aspx
>> http://www.eggheadcafe.com/articles...e_generator.asp
>>
>>
>>
>> "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
>> news:%23XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
>>> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
>>> seeing many posts about what language to use with ASP.Net. The consensus
>>> was that employers paid more for C# programmers, and it seems that C#
>>> became the darling of the ASP.Net crowd.
>>>
>>> In the meantime, I have observed an interesting phenomenon. Originally,
>>> employers hired programmers who used C# because it was based on C, and
>>> the prevailing opinion was (and may still be) that C# developers were
>>> better because they must have known and/or practiced C or C++ at some
>>> time, which would make them better programmers overall. C and C++ are
>>> hard-core programming languages compared to VB.
>>>
>>> However, now that nearly everyone has jumped on the C# bandwagon, it
>>> seems to me that the distinction between the languages has nearly
>>> disappeared, at least in terms of evaluating programmers for hire. There
>>> seem to be almost as many clueless C# developers out there as VB.Net
>>> developers. Many C# developers today are basically VB.Net developers
>>> using a different syntax. I wonder if the employers have become aware of
>>> this trend?
>>>
>>> --
>>>
>>> Kevin Spencer
>>> Microsoft MVP
>>> .Net Developer
>>> Neither a follower nor a lender be.
>>>
>>>
>>
>>
Kevin, you should check out the OutpuCache directive...hahahahha j/k :)

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/

"Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
news:eqWoataGFHA.3504@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
> > There is nothing that you can do in C# that you cannot do in VB.NET.
> I'm afraid that's simply untrue. You can't use unmanaged code in VB,
> pointers, and several other less important items. Yes, it may be a rare
> occasion that you need to, but believe it or not, I've worked on several
> projects over the past year which process very large (200 - 500 MB)
images,
> and there's no substitute for pointers in a situation like that. In fact,
> even with the use of pointers, I have one app that takes several hours to
> process a single image.
> --
> HTH,
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> Neither a follower nor a lender be.
> "Peter Rilling" <peter@dotnet.itags.org.nospam.rilling.net> wrote in message
> news:O6eVNATGFHA.3728@dotnet.itags.org.TK2MSFTNGP14.phx.gbl...
> > Okay, I write this message with the full knowledge that I am going to
piss
> > a
> > large number of people off. So I fully expect some flaming to happen.
> > As languages evolve, there becomes less and less that differentiates
them.
> > There is nothing that you can do in C# that you cannot do in VB.NET.
> > I came from a VB development background and moved to C# about five years
> > ago. I do not necessarily think that companies look for C# people
because
> > of the tie-in with C++, but rather that C# develops have more of an OOP
> > sense about them. C++ and C# are object oriented languages and
therefore
> > those people tend to think in object design. VB used to be thought of a
> > toy
> > and only used for RAD development. There was little emphasis placed on
> > proper coding styles. It was more of a "let's get it done" mentality
> > rather
> > then "let's design something for expandability and maintainability".
Keep
> > in mind that until VB.NET was released, the concept of classes was
shoddy
> > at
> > best and certainly did not have inheritance or polymorphism, which means
> > that VB was NEVER an object oriented languages.
> > Remember that when the GUI first came out it was also thought of as a
toy.
> > Why would real computer uses use a graphical interface, was the mantra
of
> > my
> > command-line gurus.
> > "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> > news:#XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
> >> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
> >> seeing many posts about what language to use with ASP.Net. The
consensus
> > was
> >> that employers paid more for C# programmers, and it seems that C#
became
> > the
> >> darling of the ASP.Net crowd.
> >>
> >> In the meantime, I have observed an interesting phenomenon. Originally,
> >> employers hired programmers who used C# because it was based on C, and
> >> the
> >> prevailing opinion was (and may still be) that C# developers were
better
> >> because they must have known and/or practiced C or C++ at some time,
> >> which
> >> would make them better programmers overall. C and C++ are hard-core
> >> programming languages compared to VB.
> >>
> >> However, now that nearly everyone has jumped on the C# bandwagon, it
> >> seems
> >> to me that the distinction between the languages has nearly
disappeared,
> > at
> >> least in terms of evaluating programmers for hire. There seem to be
> >> almost
> >> as many clueless C# developers out there as VB.Net developers. Many C#
> >> developers today are basically VB.Net developers using a different
> >> syntax.
> > I
> >> wonder if the employers have become aware of this trend?
> >>
> >> --
> >>
> >> Kevin Spencer
> >> Microsoft MVP
> >> .Net Developer
> >> Neither a follower nor a lender be.
> >>
> >>
On Wed, 23 Feb 2005 08:44:41 -0500, "Kevin Spencer"
<kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote:

>Very interesting point, Karl. Unfortunately, I think you may be right. I
>only say unfortunately because I saw VB.Net as a chance to elevate existing
>VB programmers to a deeper understanding of programming, which makes one a
>better programmer overall. I have long resented the "dumbing down" of
>programming that VB provided, allowing people to manipulate data that they
>didn't have to understand. It sounds like Microsoft is backing away from
>that bold move, and going back to the old "let the programmers be ignorant"
>philosophy, which, IMHO, has resulted in a lot of poor programmers, and a
>lot of poor programming.

The technology has enabled a lot of people to jump into programming
without learning, training, or understanding what is happening
underneath the surface. Some people would argue this is a 'good
thing', but during the gold rush of the bubble years I saw a huge
influx of people into application development roles that were there
only because it paid better than being a hair dresser.

The person who cuts my hair is licensed and trained. The worst hair
cut might cost $30 and a few months of wearing a hat.

--
Scott
http://www.OdeToCode.com/blogs/scott/
Alright, you got me, ALMOST nothing. :}

"Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
news:eqWoataGFHA.3504@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
> > There is nothing that you can do in C# that you cannot do in VB.NET.
> I'm afraid that's simply untrue. You can't use unmanaged code in VB,
> pointers, and several other less important items. Yes, it may be a rare
> occasion that you need to, but believe it or not, I've worked on several
> projects over the past year which process very large (200 - 500 MB)
images,
> and there's no substitute for pointers in a situation like that. In fact,
> even with the use of pointers, I have one app that takes several hours to
> process a single image.
> --
> HTH,
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> Neither a follower nor a lender be.
> "Peter Rilling" <peter@dotnet.itags.org.nospam.rilling.net> wrote in message
> news:O6eVNATGFHA.3728@dotnet.itags.org.TK2MSFTNGP14.phx.gbl...
> > Okay, I write this message with the full knowledge that I am going to
piss
> > a
> > large number of people off. So I fully expect some flaming to happen.
> > As languages evolve, there becomes less and less that differentiates
them.
> > There is nothing that you can do in C# that you cannot do in VB.NET.
> > I came from a VB development background and moved to C# about five years
> > ago. I do not necessarily think that companies look for C# people
because
> > of the tie-in with C++, but rather that C# develops have more of an OOP
> > sense about them. C++ and C# are object oriented languages and
therefore
> > those people tend to think in object design. VB used to be thought of a
> > toy
> > and only used for RAD development. There was little emphasis placed on
> > proper coding styles. It was more of a "let's get it done" mentality
> > rather
> > then "let's design something for expandability and maintainability".
Keep
> > in mind that until VB.NET was released, the concept of classes was
shoddy
> > at
> > best and certainly did not have inheritance or polymorphism, which means
> > that VB was NEVER an object oriented languages.
> > Remember that when the GUI first came out it was also thought of as a
toy.
> > Why would real computer uses use a graphical interface, was the mantra
of
> > my
> > command-line gurus.
> > "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> > news:#XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
> >> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
> >> seeing many posts about what language to use with ASP.Net. The
consensus
> > was
> >> that employers paid more for C# programmers, and it seems that C#
became
> > the
> >> darling of the ASP.Net crowd.
> >>
> >> In the meantime, I have observed an interesting phenomenon. Originally,
> >> employers hired programmers who used C# because it was based on C, and
> >> the
> >> prevailing opinion was (and may still be) that C# developers were
better
> >> because they must have known and/or practiced C or C++ at some time,
> >> which
> >> would make them better programmers overall. C and C++ are hard-core
> >> programming languages compared to VB.
> >>
> >> However, now that nearly everyone has jumped on the C# bandwagon, it
> >> seems
> >> to me that the distinction between the languages has nearly
disappeared,
> > at
> >> least in terms of evaluating programmers for hire. There seem to be
> >> almost
> >> as many clueless C# developers out there as VB.Net developers. Many C#
> >> developers today are basically VB.Net developers using a different
> >> syntax.
> > I
> >> wonder if the employers have become aware of this trend?
> >>
> >> --
> >>
> >> Kevin Spencer
> >> Microsoft MVP
> >> .Net Developer
> >> Neither a follower nor a lender be.
> >>
> >>
You're certainly entitled to your wrong opinion.
:)

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

"Alvin Bruney" <www.lulu.com/owc> wrote in message
news:%23RAhe3UGFHA.4004@dotnet.itags.org.tk2msftngp13.phx.gbl...
>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
> ----------------
I hardly ever post my thoughts on message boards but on this one I can't help
it.

Before I piss off everyone, this is not a bashing trip for me. This is my
observation based on interaction with both camps. Almost always the argument
is about "skill". Competence percentages tend to be consistent across all
professions (hard to believe until to really think about it). VB guys are not
less competent because there isolated from pointers, call stacks, and window
messages. If you explained it all for them they'd be shocked that you need to
deal with all that to make a form!

Typical C++ programmer:

?Never really was a C++ programmer but a hybrid of C and C++ techniques.
OOP was treated as a handy technique to simplify some code here and there.
This is would be especially apparent at the presentation layer where most of
their code tends to be procedural rather than at the business layer where the
boss or an architect specified object models for them.
?Avoids COM since it's such a "pain" to implement. Just give him the header
files and he's good.
?Tends not to be savvy in higher level application solutions like SQL,
popular web technologies, and office automation preferring to stick with
system level work, text files, named pipes, and proprietary protocols.

Typical VB programmer:

?Generally doesn't have a firm grasp of the internals of their. This gives
them the "deer in the headlights" look when you talk about memory addresses,
byte streams, registers, etc.
?Generally doesn't have a firm grasp of *ALL* the OOP concepts. I've got to
warn you here VB has always been pseudo OOP in consumption. This primes a lot
of experienced VB6 guys for "Fill in the blanks OOP".
?Generally has limited experience with win32, SSPI, Sockets, Named Pipes,
reading RFCs (they don't regret that), and other non COM based technologies
except probably HTML/ASP/IIS/VBScript/JavaScript.
?Don't care what IDispatch or IUnknown is so long as the check the box and
get their grubby little hands on it.

C++ guy to DOT.NET:

?Managed memory!
?Substantially reduced UI development efforts.
?Reduction of the amount of code required
?A whole bunch of improvements on existing capabilities
?Better documentation ?

VB6 guy to DOT.NET:

?True inheritance. After this polymorphism is a 30 second concept.
?A revelation on what a callback is. (So that's why we don't have control
arrays now)
?Threading (Whoa! VB guys thread pooling, probably not mainstream till next
year.)
?Structured error handling. (On Error GOTO something better than this )

Drawing the Line:

VB guys not only gained OOP but are forced to grasp it to be any good. OOP
is not a hard concept to grasp. It makes great sense, makes for easier
management of you code, and IS what VB guys have been doing for the last 7
years ("Form1.Name" = class property).

C++ guys have had OOP and know what it is. This does not necessarily
translate into "hit the ground running" because I find most don't "think" OOP
design and spend a fair amount of time trying to layout their code. They do
however have a marked advantage here.

While not necessary VB guys should learn threading. This is a big one. Not
so much the concepts but the practices. This is where C++ guys have a huge
advantage. I don't expect to see much more in the VB mainstream than a
couple of UI threads to get a form up faster for now.

C++ guys get an awesome object library and set of documentation. VB guys
have had this for a while. This is where the tides turn and why I think the
division is almost down the middle. C++ guys can write it all and do about
every time. Their doc's are lousy they prefer includes to binary objects, and
they tend to work through a problem than around it (often the only solution
for a VB guy).

A C++ gets DOT.NET. He does hello world, learns the types, the callback
techniques, everything's an object, and starts coding (you get the idea).
First class he writes needs to store some data, build an array. Need sorting,
build another array. Want to expose it as enumerable, write an enumerator
based on sorting array. Need to fetch some HTML page, search Google for C#
Sockets, and so on. I regularly see this. It's not a question of skill, I
think probably some very good C++ guys fall victim to this. The fact is C++
guys tend not to be object consumers but code consumers. Since the include
concept is essentially gone, they drop it from their mindset and move on.
Since their used to lame documentation they don't get in depth with the
dot.net docs so their slow to grasp all of the "do it for you components" the
framework exposes.

These issues don't hold true for VB guys. When you give them the framework a
lot of their code will still work. Enough for them to start doing something
(which is how they got started in VB the first time). Once they get a light
grasp of the IDE and the syntax they dive into the documentation. This is
because VB programmers have been object consumers the whole time, have always
had to read the component docs, and they KNOW that there are going to be a
lot of cool "components" in here! They don't write collections they INHERIT
them. They know what objects are available and what makes the different from
each other. They know what's easy because they make their living by taking
the easiest route to delivery. Yes, a VB guy has to grasp OOP, but that's
easier for them than you may think. They get to look behind the curtain and
it starts makes sense. Since their damn near expert at consuming commercial
components they just start saying "How would I like to consume this object"
and then go and build great interfaces.

I really don't believe that either camp has an advantage with regards to
good design and architecture. I'm always stunned to sit in a developer
meeting for 2 hours to discuss a 5 minute design concept only to do it again
next week for those that didn't get it the first time.

I think that the dot.net frame work is much more like an improved version of
VB than C++. I also think that the OOP hurdle for VB guys is no more
substantial than the retraining of one's mindset is for a C++ guy.

Skill is not the key attribute for a developer. It's about productivity and
all that it encompasses. It's about delivering the product in an unreasonable
amount of time with a minimal number of bugs that meets the barely defined
spec and all of the customer's unstated expectations (I should find a
different trade). You can say a lower level language requires more "Skill"
and so a programmer in that language is more "Skilled". Of course if I hear
you I'm going to beat you in the parking lot with an assembly manual. If one
VB guy delivers a 2 tier solution to market that meets customer expectation
in the time it takes for three C++ developers to scratch out the data access
layer, object model and transport layer for the same project who's more
skilled? Doesn't happen? I see it happen all the time. C++ is expensive, both
in staff and in development time. Development shops didn't want to manage two
language teams and so went with all C++ to play it safe. DOT.NET levels much
that. So, my advice to the two camps is this….

C++ guys, stop, be nice and explain to the idiot what encapsulation means.
After all you wouldn't want him to read about it a book somewhere. He might
just prototype your end of the project before you (for spite) since his
collection takes 20 lines instead of 120 you wrote.

VB guys, let it go. You'll be working side by side now and bragging about
how you've always had this and that and you can believe the hoops they used
to jump through doesn't make you any friends. Besides, you just might need
them to help identify your first race condition.

GOOD GOD, IT'S A BOOK!
Without going into whether C# or VB is better I think Kevin is right about
employer perception of C# Vs VB programmers. C# does bring an association
with other traditionally OOP languages like C/C++ and may therefore give rise
to differences in pay.

I think in some respects you are driven by market trends and when that's not
really an issue you choose what you are comfortable with. Coming from a web
development background I have been sujected to languages like Perl, PHP, VB,
JavaScript, Java, C/C++ etc. Out of those listed the only radically different
syntax is that of VB so the advent of C# for .NET was a more natural
progression for me (which seemed more like Java syntax than C++). VB
developers will, I'm sure, feel more comfortable heading down the VB .NET
road. But, if you want a better pay packet from your employer then I guess
you have to survive a little discomfort for a while and learn C#.

Perhaps it is down to us as the developers to educate employers in this area
and/or encourage them to invest in Visual Studio .NET allowing multiple
language development - although a bit messy.

Geoff

"Kevin Spencer" wrote:

Perhaps I have an advantage given what you've talked about, and some others
may have as well. I originally learned C, and while I was studying C++ and
OOP I got involved in web application development with ASP, and switched
over to VBScript. Having learned VBScript, it was a hop, skip, and jump to
VB, which I learned and used as well. When .Net came out, I learned VB.Net
first, and then C#. C# was a breeze after mastering C some time ago. So, as
a result, I feel that I had the best of both worlds in terms of the
"conditioning" that you spoke of. I was already familiar with low-level
concepts from C, had studied OOP, ended up getting my feet wet with VB's
pseudo-OOP, and made the transition to working with true OOP very easily. So
I seem to have avoided the pitfalls of both camps, while gaining from each
in the process.

--
HTH,

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

"Carl On VB.NET" <Carl On VB.NET@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:4C153F42-7D6D-4D52-AE2E-14BD239C9B1F@dotnet.itags.org.microsoft.com...
>I hardly ever post my thoughts on message boards but on this one I can't
>help
> it.
> Before I piss off everyone, this is not a bashing trip for me. This is my
> observation based on interaction with both camps. Almost always the
> argument
> is about "skill". Competence percentages tend to be consistent across all
> professions (hard to believe until to really think about it). VB guys are
> not
> less competent because there isolated from pointers, call stacks, and
> window
> messages. If you explained it all for them they'd be shocked that you need
> to
> deal with all that to make a form!
> Typical C++ programmer:
> . Never really was a C++ programmer but a hybrid of C and C++ techniques.
> OOP was treated as a handy technique to simplify some code here and there.
> This is would be especially apparent at the presentation layer where most
> of
> their code tends to be procedural rather than at the business layer where
> the
> boss or an architect specified object models for them.
> . Avoids COM since it's such a "pain" to implement. Just give him the
> header
> files and he's good.
> . Tends not to be savvy in higher level application solutions like SQL,
> popular web technologies, and office automation preferring to stick with
> system level work, text files, named pipes, and proprietary protocols.
> Typical VB programmer:
> . Generally doesn't have a firm grasp of the internals of their. This
> gives
> them the "deer in the headlights" look when you talk about memory
> addresses,
> byte streams, registers, etc.
> . Generally doesn't have a firm grasp of *ALL* the OOP concepts. I've got
> to
> warn you here VB has always been pseudo OOP in consumption. This primes a
> lot
> of experienced VB6 guys for "Fill in the blanks OOP".
> . Generally has limited experience with win32, SSPI, Sockets, Named Pipes,
> reading RFCs (they don't regret that), and other non COM based
> technologies
> except probably HTML/ASP/IIS/VBScript/JavaScript.
> . Don't care what IDispatch or IUnknown is so long as the check the box
> and
> get their grubby little hands on it.
> C++ guy to DOT.NET:
> . Managed memory!
> . Substantially reduced UI development efforts.
> . Reduction of the amount of code required
> . A whole bunch of improvements on existing capabilities
> . Better documentation ?
> VB6 guy to DOT.NET:
> . True inheritance. After this polymorphism is a 30 second concept.
> . A revelation on what a callback is. (So that's why we don't have control
> arrays now)
> . Threading (Whoa! VB guys thread pooling, probably not mainstream till
> next
> year.)
> . Structured error handling. (On Error GOTO something better than this )
> Drawing the Line:
> VB guys not only gained OOP but are forced to grasp it to be any good. OOP
> is not a hard concept to grasp. It makes great sense, makes for easier
> management of you code, and IS what VB guys have been doing for the last 7
> years ("Form1.Name" = class property).
> C++ guys have had OOP and know what it is. This does not necessarily
> translate into "hit the ground running" because I find most don't "think"
> OOP
> design and spend a fair amount of time trying to layout their code. They
> do
> however have a marked advantage here.
> While not necessary VB guys should learn threading. This is a big one. Not
> so much the concepts but the practices. This is where C++ guys have a huge
> advantage. I don't expect to see much more in the VB mainstream than a
> couple of UI threads to get a form up faster for now.
> C++ guys get an awesome object library and set of documentation. VB guys
> have had this for a while. This is where the tides turn and why I think
> the
> division is almost down the middle. C++ guys can write it all and do about
> every time. Their doc's are lousy they prefer includes to binary objects,
> and
> they tend to work through a problem than around it (often the only
> solution
> for a VB guy).
> A C++ gets DOT.NET. He does hello world, learns the types, the callback
> techniques, everything's an object, and starts coding (you get the idea).
> First class he writes needs to store some data, build an array. Need
> sorting,
> build another array. Want to expose it as enumerable, write an enumerator
> based on sorting array. Need to fetch some HTML page, search Google for C#
> Sockets, and so on. I regularly see this. It's not a question of skill, I
> think probably some very good C++ guys fall victim to this. The fact is
> C++
> guys tend not to be object consumers but code consumers. Since the include
> concept is essentially gone, they drop it from their mindset and move on.
> Since their used to lame documentation they don't get in depth with the
> dot.net docs so their slow to grasp all of the "do it for you components"
> the
> framework exposes.
> These issues don't hold true for VB guys. When you give them the framework
> a
> lot of their code will still work. Enough for them to start doing
> something
> (which is how they got started in VB the first time). Once they get a
> light
> grasp of the IDE and the syntax they dive into the documentation. This is
> because VB programmers have been object consumers the whole time, have
> always
> had to read the component docs, and they KNOW that there are going to be a
> lot of cool "components" in here! They don't write collections they
> INHERIT
> them. They know what objects are available and what makes the different
> from
> each other. They know what's easy because they make their living by taking
> the easiest route to delivery. Yes, a VB guy has to grasp OOP, but that's
> easier for them than you may think. They get to look behind the curtain
> and
> it starts makes sense. Since their damn near expert at consuming
> commercial
> components they just start saying "How would I like to consume this
> object"
> and then go and build great interfaces.
> I really don't believe that either camp has an advantage with regards to
> good design and architecture. I'm always stunned to sit in a developer
> meeting for 2 hours to discuss a 5 minute design concept only to do it
> again
> next week for those that didn't get it the first time.
> I think that the dot.net frame work is much more like an improved version
> of
> VB than C++. I also think that the OOP hurdle for VB guys is no more
> substantial than the retraining of one's mindset is for a C++ guy.
> Skill is not the key attribute for a developer. It's about productivity
> and
> all that it encompasses. It's about delivering the product in an
> unreasonable
> amount of time with a minimal number of bugs that meets the barely defined
> spec and all of the customer's unstated expectations (I should find a
> different trade). You can say a lower level language requires more "Skill"
> and so a programmer in that language is more "Skilled". Of course if I
> hear
> you I'm going to beat you in the parking lot with an assembly manual. If
> one
> VB guy delivers a 2 tier solution to market that meets customer
> expectation
> in the time it takes for three C++ developers to scratch out the data
> access
> layer, object model and transport layer for the same project who's more
> skilled? Doesn't happen? I see it happen all the time. C++ is expensive,
> both
> in staff and in development time. Development shops didn't want to manage
> two
> language teams and so went with all C++ to play it safe. DOT.NET levels
> much
> that. So, my advice to the two camps is this..
> C++ guys, stop, be nice and explain to the idiot what encapsulation means.
> After all you wouldn't want him to read about it a book somewhere. He
> might
> just prototype your end of the project before you (for spite) since his
> collection takes 20 lines instead of 120 you wrote.
> VB guys, let it go. You'll be working side by side now and bragging about
> how you've always had this and that and you can believe the hoops they
> used
> to jump through doesn't make you any friends. Besides, you just might need
> them to help identify your first race condition.
> GOOD GOD, IT'S A BOOK!
Good points, Geoff!

And thanks for avoiding the "other" issue! ;-)

--
HTH,

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

"Geoff Willings" <Geoff Willings@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:98107D00-415A-4CE7-BD5F-3F32EB29891C@dotnet.itags.org.microsoft.com...
> Without going into whether C# or VB is better I think Kevin is right about
> employer perception of C# Vs VB programmers. C# does bring an association
> with other traditionally OOP languages like C/C++ and may therefore give
> rise
> to differences in pay.
> I think in some respects you are driven by market trends and when that's
> not
> really an issue you choose what you are comfortable with. Coming from a
> web
> development background I have been sujected to languages like Perl, PHP,
> VB,
> JavaScript, Java, C/C++ etc. Out of those listed the only radically
> different
> syntax is that of VB so the advent of C# for .NET was a more natural
> progression for me (which seemed more like Java syntax than C++). VB
> developers will, I'm sure, feel more comfortable heading down the VB .NET
> road. But, if you want a better pay packet from your employer then I
> guess
> you have to survive a little discomfort for a while and learn C#.
> Perhaps it is down to us as the developers to educate employers in this
> area
> and/or encourage them to invest in Visual Studio .NET allowing multiple
> language development - although a bit messy.
> Geoff
> "Kevin Spencer" wrote:
>> 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.
>>
>>
>
On 23 Feb 2005, "Karl Seguin" <karl REMOVE @dotnet.itags.org. REMOVE openmymind
REMOVEMETOO . ANDME net> postulated in news:uRNRvVaGFHA.4004
@dotnet.itags.org.tk2msftngp13.phx.gbl:

> "Many C# developers today are basically VB.Net developers using a
different
> syntax"
> This may be true today, but it's equally important to look at where
the
> languages are going. It seems to me that in the 2.0 release, we
are
> starting to see a divergence, albeit slight, between the two
language which
> i expect will be a continuing trend. I agree that refactoring is
only a
> tool which can easily be done as an addon, but that the C# IDE
supports it
> and the VB.Net one doesn't suggests that the VB.Net team sees the
needs of
> its developers as being different than those of C# developers.
Other
> features such as My, Iterators and enhanced nullable types which
are either
> in one language or another (anonymous functions in vb.net??) are
all signs
> that MS is moving away from having the languages simply be
"different
> syntax".
> As far as the crappiness of VB programmers which was touched on by
others,
> my personal opinion is that the programming language doesn't make
the
> quality, it's the person behind the keyboard. A bad programmer
will
> programming equally bad using whichever language. I think the
belief that
> there are simply more bad VB programmers out there is highly
speculative and
> even if true, an HR departement would be foolish to ignore the fact
that
> there are plenty of good programmers in either language. Having
said that,
> VB.Net does make it a little easier to be sloppy (option explicit
and
> strict, on error resume next, ...), but I'm sure that if someone
wanted to
> they could come up, item for item, of a list of things C# allows
which could
> be argued it shouldn't.
> Karl

I wouldn't say the divergence between the languages is slight. For
instance, will VB.NET support generics?

C# is competing with Java for a major share of the Enterprise
development pie. The visionaries at M$ research thought it was worth
the rampup costs to introduce a new language to get the state-of-the-
art features needed to take the sdk to a new level of security and
interoperability. In other words, dot net needed C# and C# needed dot
net.

I'm not sure what Visual Basic.net is moving towards, but the
development of VB.Net serves a couple of strategic purposes for M$.
First, it satisfies the many legacy developers out there that have
built an entire industry around VB coders and VB applications. VB.NET
gives the VB contingent new legs to carry them for years down the
line.

VB.NET also provides case-study data on creating dot net languages.
It gives credibility to the point that dot net is not C#-centric, as
the Win32 is C++ centric, and in this way demonstrates to the
language community the flexibility and viability of the dot net
platform as a target machine.

JMHO.

-- ipgrunt
The most important thing is to hire someone smart. The interview should
determine that persons raw smarts - syntax, languages, and tools can be
learned quickly. The key component is whether that person can think through
a problem and be able to express that thought process/algorithm in code.

If an employer/interviewer does not have the interview experience or does
not invest time into exploring ways to get to the bottom of that question and
they rely simply on a checkboxed list of langauges/years, then they will
likely miss out on that really smart developer or hire someone who just got
by with C/C++.

If someone says - I want to hire a C programmer even if it's a web job
because that means they are smart, that means they are trying filter to the
smartest people with the very least amount of work and probing on their side.
They have equated that one factor to their decision.

Even though I don't agree with that simple filter, we have to ask ourselves
why. Here are some possibilities:
* Their is a higher bar to entry in C, C++. You have to understand more
about the system, memory, etc... and have to be very detail oriented and
skilled to write native code that performs well and doesn't crash (both of
which aren't always achieved by C++). You are more likely to get a computer
scientist here - once again, algortighms should define that and not the
language but it's a shortcut assumption.
* Out of the box: what happens when components or the framework doesn't
give you a neatly packaged API to solve your current problem? It is more
likely that a native programmer will quickly pinvoke his way into a solution
where a RAD developer will search the web for a prewritten component (pros
and cons to that - different discussion).
* the most obvious is if they have a large C/C++ code base :)

I would characterize it on another dimension - I would differentiate RAD vs.
shrink wrapped developer. You will find two different mind sets here. If
you get a developer who is used to doing 2 year projects to develop well
designed and extensible shrink wrapped projects - putting them on a 2 week
RAD IT project will be tough - and vice versa. You will typically find
larger companies wanting experience in shipping products having gone through
full ship cycles etc ... and consulting companies looking for more RAD
developers on short cycle projects. Historically, shipping products have
used C/C++/Win32 where RAD was VB - thus the stereotypes.

Bryan
bryanmac@dotnet.itags.org.microsoft.com

"Kevin Spencer" wrote:

If you're hiring someone, the focus should be on a problem like "I have this
huge amount of data here and the client needs to interact in this fashion -
how would you design the access patterns?" etc... Analyzing problems like
that while probing and taking the access pattern constraints into
consideration shows smarts, experience and thus value to your organization.

As a developer who is trying to study and find what makes them valuable, I
would focus on design patterns, data access patterns, data structures and
algorithms in the language of your choice. Those are core tenants and
valuable knowledge you can take forward no matter where the industry goes and
what particular language a company is looking for.

"Bryan MacFarlane" wrote:

> The most important thing is to hire someone smart. The interview should
> determine that persons raw smarts - syntax, languages, and tools can be
> learned quickly. The key component is whether that person can think through
> a problem and be able to express that thought process/algorithm in code.
> If an employer/interviewer does not have the interview experience or does
> not invest time into exploring ways to get to the bottom of that question and
> they rely simply on a checkboxed list of langauges/years, then they will
> likely miss out on that really smart developer or hire someone who just got
> by with C/C++.
> If someone says - I want to hire a C programmer even if it's a web job
> because that means they are smart, that means they are trying filter to the
> smartest people with the very least amount of work and probing on their side.
> They have equated that one factor to their decision.
> Even though I don't agree with that simple filter, we have to ask ourselves
> why. Here are some possibilities:
> * Their is a higher bar to entry in C, C++. You have to understand more
> about the system, memory, etc... and have to be very detail oriented and
> skilled to write native code that performs well and doesn't crash (both of
> which aren't always achieved by C++). You are more likely to get a computer
> scientist here - once again, algortighms should define that and not the
> language but it's a shortcut assumption.
> * Out of the box: what happens when components or the framework doesn't
> give you a neatly packaged API to solve your current problem? It is more
> likely that a native programmer will quickly pinvoke his way into a solution
> where a RAD developer will search the web for a prewritten component (pros
> and cons to that - different discussion).
> * the most obvious is if they have a large C/C++ code base :)
> I would characterize it on another dimension - I would differentiate RAD vs.
> shrink wrapped developer. You will find two different mind sets here. If
> you get a developer who is used to doing 2 year projects to develop well
> designed and extensible shrink wrapped projects - putting them on a 2 week
> RAD IT project will be tough - and vice versa. You will typically find
> larger companies wanting experience in shipping products having gone through
> full ship cycles etc ... and consulting companies looking for more RAD
> developers on short cycle projects. Historically, shipping products have
> used C/C++/Win32 where RAD was VB - thus the stereotypes.
> Bryan
> bryanmac@dotnet.itags.org.microsoft.com
>
> "Kevin Spencer" wrote:
> > 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.
Does it matter which language its written in?
The CLR cares not.

"Kevin Spencer" wrote:

> Also - by focusing on language the point is being missed. The key to a good
> application is the algorithm - analyzing the client/server communication
> pattern, having optimized algorithms to avoid going back to the server,
> optimizing caching patterns etc... the key benfit to .net is the framework
> because it makes you really productive and allows you to think about the
> algorithm - time doing that is always better than hunting for memory leaks,
> hard to repro crashes, etc...

Complete agreement here, it's the algorithm that counts the most. (operating
from a stereotype,) Are employers tempted to conclude that C/C++/C#
developers more likely to develop better algorithms than their VB/VB.NET
counterparts?

I'm not really interested in going down the road of this language is better
than that, blah blah. Certainly, smart people exist who code in both
languages. Yet, in the spirit of Kevin's original post, how accurate is the
above question?

> If you're hiring someone, the focus should be on a problem like "I have this
> huge amount of data here and the client needs to interact in this fashion -
> how would you design the access patterns?" etc... Analyzing problems like
> that while probing and taking the access pattern constraints into
> consideration shows smarts, experience and thus value to your organization.
> As a developer who is trying to study and find what makes them valuable, I
> would focus on design patterns, data access patterns, data structures and
> algorithms in the language of your choice. Those are core tenants and
> valuable knowledge you can take forward no matter where the industry goes and
> what particular language a company is looking for.
> "Bryan MacFarlane" wrote:
> > The most important thing is to hire someone smart. The interview should
> > determine that persons raw smarts - syntax, languages, and tools can be
> > learned quickly. The key component is whether that person can think through
> > a problem and be able to express that thought process/algorithm in code.
> > If an employer/interviewer does not have the interview experience or does
> > not invest time into exploring ways to get to the bottom of that question and
> > they rely simply on a checkboxed list of langauges/years, then they will
> > likely miss out on that really smart developer or hire someone who just got
> > by with C/C++.
> > If someone says - I want to hire a C programmer even if it's a web job
> > because that means they are smart, that means they are trying filter to the
> > smartest people with the very least amount of work and probing on their side.
> > They have equated that one factor to their decision.
> > Even though I don't agree with that simple filter, we have to ask ourselves
> > why. Here are some possibilities:
> > * Their is a higher bar to entry in C, C++. You have to understand more
> > about the system, memory, etc... and have to be very detail oriented and
> > skilled to write native code that performs well and doesn't crash (both of
> > which aren't always achieved by C++). You are more likely to get a computer
> > scientist here - once again, algortighms should define that and not the
> > language but it's a shortcut assumption.
> > * Out of the box: what happens when components or the framework doesn't
> > give you a neatly packaged API to solve your current problem? It is more
> > likely that a native programmer will quickly pinvoke his way into a solution
> > where a RAD developer will search the web for a prewritten component (pros
> > and cons to that - different discussion).
> > * the most obvious is if they have a large C/C++ code base :)
> > I would characterize it on another dimension - I would differentiate RAD vs.
> > shrink wrapped developer. You will find two different mind sets here. If
> > you get a developer who is used to doing 2 year projects to develop well
> > designed and extensible shrink wrapped projects - putting them on a 2 week
> > RAD IT project will be tough - and vice versa. You will typically find
> > larger companies wanting experience in shipping products having gone through
> > full ship cycles etc ... and consulting companies looking for more RAD
> > developers on short cycle projects. Historically, shipping products have
> > used C/C++/Win32 where RAD was VB - thus the stereotypes.
> > Bryan
> > bryanmac@dotnet.itags.org.microsoft.com
> > "Kevin Spencer" wrote:
> > > 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.
> > >
> Complete agreement here, it's the algorithm that counts the most.
> (operating
> from a stereotype,) Are employers tempted to conclude that C/C++/C#
> developers more likely to develop better algorithms than their VB/VB.NET
> counterparts?

Here's the basics of the issue: VB is much easier to learn and work with
than C, or C++. It does a lot of the work for the programmer, doesn't
require the developer to know what a data type is, uses variants, avoids
pointers, manages its own memory, etc. So, while it is remotely possible
that someone could learn C and/or C++ without a good grasp of the
fundamental principles involved, it is not likely. C is not forgiving at
all. On the other hand, it is entirely possible for someone to learn VB
without understanding what a data type is, or much of anything about what
the app is actually doing under the covers, so to speak.

Okay, note here that I've made no qualitative statements about either
language family. So far, we're just dealing with facts, not opinions. In
fact, neither language family is superior. You can write applications that
do the same things regardless of language. You might be able to write a C
app that runs a good bit faster, due to the late binding inherent in VB, but
it would still perform the same operations. And you can write a good or bad
app with either language family.

However, the skill of a programmer is based upon the cumulative knowledge of
programming that the developer holds. This skill can only be obtained by
study and discipline over time. IOW, it takes a lot of work to become a good
programmer. We also know that different people have different levels of
self-discipline. Some people are over-achievers, some are under-achievers,
and some are average. So, assuming that an individual wanted to become a
programmer, it could be postulated that the individual would pick a language
to learn that was in keeping with his/her level of self-discipline. A lazy
person would not want to work as hard to get results. Which language family
would a less-disciplined individual be more likely to learn in the
beginning? Again, it's a statistical thing, and can't be used to predict
individual results, but trends.

Until recent years, a C or C++ developer would be logically preferred (if
affordable). However, with the advent of .Net and VB.Net in particular, and
the changes that have been made to the language, bringing it up to par
(nearly) with C#, the choice is not as simple. Now, a person that wants to
learn programming with .Net can choose either language to start with, and
have a good career with it. But the perception is probably still there. As a
result, most new developers seem to lean towards learning C#, as it
ostensibly pays more.

On the other hand, current VB developers are learning C# as well, in hopes
of making more money. As a result, we now have a lot of developers that
program with C# syntax, but have not improved their skills, only learned a
different syntax. In other words, the language is no longer a valid
statistical test of the skill level of the developer.

--
HTH,

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

"eric db" <ericdb@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:7324BA38-32AC-44CE-8EB7-78F5FC0B4B41@dotnet.itags.org.microsoft.com...
> "Bryan MacFarlane" wrote:
>> Also - by focusing on language the point is being missed. The key to a
>> good
>> application is the algorithm - analyzing the client/server communication
>> pattern, having optimized algorithms to avoid going back to the server,
>> optimizing caching patterns etc... the key benfit to .net is the
>> framework
>> because it makes you really productive and allows you to think about the
>> algorithm - time doing that is always better than hunting for memory
>> leaks,
>> hard to repro crashes, etc...
>>
> Complete agreement here, it's the algorithm that counts the most.
> (operating
> from a stereotype,) Are employers tempted to conclude that C/C++/C#
> developers more likely to develop better algorithms than their VB/VB.NET
> counterparts?
> I'm not really interested in going down the road of this language is
> better
> than that, blah blah. Certainly, smart people exist who code in both
> languages. Yet, in the spirit of Kevin's original post, how accurate is
> the
> above question?
> e
>
>> If you're hiring someone, the focus should be on a problem like "I have
>> this
>> huge amount of data here and the client needs to interact in this
>> fashion -
>> how would you design the access patterns?" etc... Analyzing problems
>> like
>> that while probing and taking the access pattern constraints into
>> consideration shows smarts, experience and thus value to your
>> organization.
>>
>> As a developer who is trying to study and find what makes them valuable,
>> I
>> would focus on design patterns, data access patterns, data structures and
>> algorithms in the language of your choice. Those are core tenants and
>> valuable knowledge you can take forward no matter where the industry goes
>> and
>> what particular language a company is looking for.
>>
>> "Bryan MacFarlane" wrote:
>>
>> > The most important thing is to hire someone smart. The interview
>> > should
>> > determine that persons raw smarts - syntax, languages, and tools can be
>> > learned quickly. The key component is whether that person can think
>> > through
>> > a problem and be able to express that thought process/algorithm in
>> > code.
>>> > If an employer/interviewer does not have the interview experience or
>> > does
>> > not invest time into exploring ways to get to the bottom of that
>> > question and
>> > they rely simply on a checkboxed list of langauges/years, then they
>> > will
>> > likely miss out on that really smart developer or hire someone who just
>> > got
>> > by with C/C++.
>>> > If someone says - I want to hire a C programmer even if it's a web job
>> > because that means they are smart, that means they are trying filter to
>> > the
>> > smartest people with the very least amount of work and probing on their
>> > side.
>> > They have equated that one factor to their decision.
>>> > Even though I don't agree with that simple filter, we have to ask
>> > ourselves
>> > why. Here are some possibilities:
>> > * Their is a higher bar to entry in C, C++. You have to understand
>> > more
>> > about the system, memory, etc... and have to be very detail oriented
>> > and
>> > skilled to write native code that performs well and doesn't crash (both
>> > of
>> > which aren't always achieved by C++). You are more likely to get a
>> > computer
>> > scientist here - once again, algortighms should define that and not the
>> > language but it's a shortcut assumption.
>> > * Out of the box: what happens when components or the framework
>> > doesn't
>> > give you a neatly packaged API to solve your current problem? It is
>> > more
>> > likely that a native programmer will quickly pinvoke his way into a
>> > solution
>> > where a RAD developer will search the web for a prewritten component
>> > (pros
>> > and cons to that - different discussion).
>> > * the most obvious is if they have a large C/C++ code base :)
>>> > I would characterize it on another dimension - I would differentiate
>> > RAD vs.
>> > shrink wrapped developer. You will find two different mind sets here.
>> > If
>> > you get a developer who is used to doing 2 year projects to develop
>> > well
>> > designed and extensible shrink wrapped projects - putting them on a 2
>> > week
>> > RAD IT project will be tough - and vice versa. You will typically find
>> > larger companies wanting experience in shipping products having gone
>> > through
>> > full ship cycles etc ... and consulting companies looking for more RAD
>> > developers on short cycle projects. Historically, shipping products
>> > have
>> > used C/C++/Win32 where RAD was VB - thus the stereotypes.
>>> > Bryan
>> > bryanmac@dotnet.itags.org.microsoft.com
>>>>> > "Kevin Spencer" wrote:
>>> > > 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.
>> >> >>
Kevin wrote: "...current VB developers are learning C# as well, in hopes
of making more money. As a result, we now have a lot of developers that
program with C# syntax, but have not improved their skills, only learned a
different syntax. In other words, the language is no longer a valid
statistical test of the skill level of the developer."

I agree that learning a new language will always dampen progressive
development both on a personal level and consequently for an organisation.
However, part of "moving with the times" whether with software or a
programming language requires a steep learning curve.

So, sometimes you have to look at it more as time invested rather than
wasted since the progressive development will pick up again pretty quickly.
It's the age old "once you've done one OOP language you can pick up another
one faster than...something thats pretty fast".

Is migration from VB to C# seen as "moving with the times"? Yes pretty much.

Is it really? Probably not.

What do you do about it? Put your head between your knees and start praying
that the migration goes smoothly.

What are the draw backs? It takes time.

What is the outcome? Over time you will "hopefully" have more skilled
developers with a broader understanding of OOP from different perspectives.
It's pretty much like re-learning what you already know to drum it home.

I was never sure about a language being an indication of the developers
skill level though.

As for the Demise of C#...hmm i think it is too popular a syntax to get rid
of. As for VB programmers, well thats pretty popular too so the same applies.

As for pay, well there are still plenty of large software manufacturers who
only use VB with .NET, which is pretty annoying when you want to integrate
with their software as a C# developer and all their manuals are in VB. Ah ha
now we have found a use for knowing both VB and C# ... integration work...the
bain of my life!!!!
> As for the Demise of C#...hmm i think it is too popular a syntax to get
> rid
> of. As for VB programmers, well thats pretty popular too so the same
> applies.

I think you misunderstood my title. "The Demise of C#" in this respect is in
the context of the demise of C# as a standard of skill measurement. I
certainly don't think C# or VB.Net is going away.

--
HTH,

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

"Geoff Willings" <GeoffWillings@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:0E0EC8A2-253B-47D2-A4FE-00A65C2E4C3A@dotnet.itags.org.microsoft.com...
> Kevin wrote: "...current VB developers are learning C# as well, in hopes
> of making more money. As a result, we now have a lot of developers that
> program with C# syntax, but have not improved their skills, only learned a
> different syntax. In other words, the language is no longer a valid
> statistical test of the skill level of the developer."
> I agree that learning a new language will always dampen progressive
> development both on a personal level and consequently for an organisation.
> However, part of "moving with the times" whether with software or a
> programming language requires a steep learning curve.
> So, sometimes you have to look at it more as time invested rather than
> wasted since the progressive development will pick up again pretty
> quickly.
> It's the age old "once you've done one OOP language you can pick up
> another
> one faster than...something thats pretty fast".
> Is migration from VB to C# seen as "moving with the times"? Yes pretty
> much.
> Is it really? Probably not.
> What do you do about it? Put your head between your knees and start
> praying
> that the migration goes smoothly.
> What are the draw backs? It takes time.
> What is the outcome? Over time you will "hopefully" have more skilled
> developers with a broader understanding of OOP from different
> perspectives.
> It's pretty much like re-learning what you already know to drum it home.
> I was never sure about a language being an indication of the developers
> skill level though.
> As for the Demise of C#...hmm i think it is too popular a syntax to get
> rid
> of. As for VB programmers, well thats pretty popular too so the same
> applies.
> As for pay, well there are still plenty of large software manufacturers
> who
> only use VB with .NET, which is pretty annoying when you want to integrate
> with their software as a C# developer and all their manuals are in VB. Ah
> ha
> now we have found a use for knowing both VB and C# ... integration
> work...the
> bain of my life!!!!
Hi,

Nowadays I see more and more people talking about design patterns and
architecturing system along with C++... The fact is about every C++ person I
have worked since the release of .NET doing C# (or VB.NET) have no clue what
design patterns are. C# is an OO environment and understanding how to
implement Polymorphism is more prevalent to someone that has programmed using
C++ or Java; although at times this isn't always true :-) I know not a lot of
people programming out there that does not use "abstract classes" or use
"interfaces" or program their classes to implement the concepts of OO and
most importantly Polymorphism. In fact the truth is obviously most Web
Developers which used to program with VB/ASP/vbScript could write a dorn
javaScript script or DHTML interface. Well I guess I am stereotyping those
developers but more and more jobs given to those programmers trying to move
to the OO world of .NET are missing the powerful usage of .NET and create
program that are some what unreausable due to lack of architecting a proper
design. C++ or Java programmer on the other hand do come in with a stronger
knowledge in those area... The real power of .NET is being able to implement
Interoperability of legacy code which in most cases are written in C++ and
therefore a lot harder to rewrite in another language which on the other hand
if an API or COM+ DLL was written in VB could with some hard work be
re-engineered in another language such as C#.

Finally in my opinion today a job has to be broken down into different parts
not only developers and a project manager (which in most cases doesn't know
anything about programming in general) but rather an architect, a developer,
and a enterprise manager (who cares what he know about "delegates").

~yamazed

"Kevin Spencer" wrote:

Too right - if I was looking for a senior developer (as opposed to maybe a
contactor to come in and do some short term work), then their skills at
solving problems and designing algorithms would be way above any specific
language knowledge. I want to know they understand databases, user interface
architecture etc. that whether they know C# better than VB.NET.

In fact, I would *expect* a competent program to be able to pick up a new
language in a very short time. Learning a new environment or object
library - that's what takes the time.

Rob.
> Finally in my opinion today a job has to be broken down into different
> parts
> not only developers and a project manager (which in most cases doesn't
> know
> anything about programming in general) but rather an architect, a
> developer,
> and a enterprise manager (who cares what he know about "delegates").

The system architects and analysts have a far more profound effect on the
deliverability and functionality of a system that the code with certain
exceptions (such as tight 3D algorithms). The same applies to most walks of
life - you pay an architect to design your house or extension far more than
the people who come in an build the thing.

Designing a good system is a blend of experience and programming skills.
Hey, I love programming but I get a far bigger kick out of coming up with a
neat and innovative solution/algoritm.

Get the design correct and the code should fall out of the other end
naturally. Same with database design.

Rob.
Get the design correct and the code should fall out of the other end
> naturally. Same with database design.

A great introduction to this can be found at:
http://www.dofactory.com/Patterns/Patterns.aspx

The more you learn these concept and implement them into your design and
coding practices the closer you are to move to an Architectural position...
Database design is a little different but if you have a solid understanding
with UML (meaning dividing all different entities from an Enterprise) then
you should have any trouble building a database skelaton from scratch...

~yamazed

"Rob Nicholson" wrote:

> > Finally in my opinion today a job has to be broken down into different
> > parts
> > not only developers and a project manager (which in most cases doesn't
> > know
> > anything about programming in general) but rather an architect, a
> > developer,
> > and a enterprise manager (who cares what he know about "delegates").
> The system architects and analysts have a far more profound effect on the
> deliverability and functionality of a system that the code with certain
> exceptions (such as tight 3D algorithms). The same applies to most walks of
> life - you pay an architect to design your house or extension far more than
> the people who come in an build the thing.
> Designing a good system is a blend of experience and programming skills.
> Hey, I love programming but I get a far bigger kick out of coming up with a
> neat and innovative solution/algoritm.
> Get the design correct and the code should fall out of the other end
> naturally. Same with database design.
> Rob.
>
>
this is an age old debate/delimma. I have seens and read many post like it
before .

However i thin kits rather a moot point. if somoene is typing, or has typed
-> or .

Most developers who have had any time or experience with and OO lagauge can
make the transistion between/to another languauge wit relative ease( and
about 3 months to gain speed back ). For me I learned C# because my job
needed me to, as things progressed and i moved on to other
positions/companies i have had to learn VB( this langauge is horrid IMHO ) .
same crap. in the past i used C, and C++ mostly for school but these too are
also the same BS. You have to keep i mind the same things when building and
application ( web, forms, or console ) . the only diffrences are mem
management, garbage collection, and syntax for the most part.

I dunno mayb it jsut me but, the debate of 1 langauge over another is
somewhat just rhetoric these days. Especially when dealing with JRE, and/or
CLR code.

"Robbe Morris [C# MVP]" wrote:

> 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/for...st10017013.aspx
> http://www.eggheadcafe.com/articles...e_generator.asp
>
> "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> news:%23XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
> > About 2 years ago, and as recently as perhaps 1 year ago, I can recall
> > seeing many posts about what language to use with ASP.Net. The consensus
> > was that employers paid more for C# programmers, and it seems that C#
> > became the darling of the ASP.Net crowd.
> > In the meantime, I have observed an interesting phenomenon. Originally,
> > employers hired programmers who used C# because it was based on C, and the
> > prevailing opinion was (and may still be) that C# developers were better
> > because they must have known and/or practiced C or C++ at some time, which
> > would make them better programmers overall. C and C++ are hard-core
> > programming languages compared to VB.
> > However, now that nearly everyone has jumped on the C# bandwagon, it seems
> > to me that the distinction between the languages has nearly disappeared,
> > at least in terms of evaluating programmers for hire. There seem to be
> > almost as many clueless C# developers out there as VB.Net developers. Many
> > C# developers today are basically VB.Net developers using a different
> > syntax. I wonder if the employers have become aware of this trend?
> > --
> > Kevin Spencer
> > Microsoft MVP
> > .Net Developer
> > Neither a follower nor a lender be.
>
> Many C# developers today are basically VB.Net developers using a different
> syntax. I wonder if the employers have become aware of this trend?

Possibly one reason for the C# demand has been the adoption of C# as an
internal standard in some cases (yes, we all know the interoperate etc, but
some companies set an internal standard mandating one or other language).
Anyone else seeing this, or is it just me?

So the manager that OK's the hiring, or the person that writes the job
description asks the team what's required - the team replies "Must know C#",
because that's the standard. The team would look at anyone that knows .NET
regardless of language, and is a good programmer, but the original
requirements say C#. At our company, everyone from sales to managers to
developers gets a days basic training on .NET that gives them the message
(among other info) that the language is not a divisive choice for .NET
development - but perhaps the message has not got though.
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

"Carl On VB.NET" wrote:

> I hardly ever post my thoughts on message boards but on this one I can't help
> it.
> Before I piss off everyone, this is not a bashing trip for me. This is my
> observation based on interaction with both camps. Almost always the argument
> is about "skill". Competence percentages tend to be consistent across all
> professions (hard to believe until to really think about it). VB guys are not
> less competent because there isolated from pointers, call stacks, and window
> messages. If you explained it all for them they'd be shocked that you need to
> deal with all that to make a form!
> Typical C++ programmer:
> ?Never really was a C++ programmer but a hybrid of C and C++ techniques.
> OOP was treated as a handy technique to simplify some code here and there.
> This is would be especially apparent at the presentation layer where most of
> their code tends to be procedural rather than at the business layer where the
> boss or an architect specified object models for them.
> ?Avoids COM since it's such a "pain" to implement. Just give him the header
> files and he's good.
> ?Tends not to be savvy in higher level application solutions like SQL,
> popular web technologies, and office automation preferring to stick with
> system level work, text files, named pipes, and proprietary protocols.
> Typical VB programmer:
> ?Generally doesn't have a firm grasp of the internals of their. This gives
> them the "deer in the headlights" look when you talk about memory addresses,
> byte streams, registers, etc.
> ?Generally doesn't have a firm grasp of *ALL* the OOP concepts. I've got to
> warn you here VB has always been pseudo OOP in consumption. This primes a lot
> of experienced VB6 guys for "Fill in the blanks OOP".
> ?Generally has limited experience with win32, SSPI, Sockets, Named Pipes,
> reading RFCs (they don't regret that), and other non COM based technologies
> except probably HTML/ASP/IIS/VBScript/JavaScript.
> ?Don't care what IDispatch or IUnknown is so long as the check the box and
> get their grubby little hands on it.
> C++ guy to DOT.NET:
> ?Managed memory!
> ?Substantially reduced UI development efforts.
> ?Reduction of the amount of code required
> ?A whole bunch of improvements on existing capabilities
> ?Better documentation ?
> VB6 guy to DOT.NET:
> ?True inheritance. After this polymorphism is a 30 second concept.
> ?A revelation on what a callback is. (So that's why we don't have control
> arrays now)
> ?Threading (Whoa! VB guys thread pooling, probably not mainstream till next
> year.)
> ?Structured error handling. (On Error GOTO something better than this )
> Drawing the Line:
> VB guys not only gained OOP but are forced to grasp it to be any good. OOP
> is not a hard concept to grasp. It makes great sense, makes for easier
> management of you code, and IS what VB guys have been doing for the last 7
> years ("Form1.Name" = class property).
> C++ guys have had OOP and know what it is. This does not necessarily
> translate into "hit the ground running" because I find most don't "think" OOP
> design and spend a fair amount of time trying to layout their code. They do
> however have a marked advantage here.
> While not necessary VB guys should learn threading. This is a big one. Not
> so much the concepts but the practices. This is where C++ guys have a huge
> advantage. I don't expect to see much more in the VB mainstream than a
> couple of UI threads to get a form up faster for now.
> C++ guys get an awesome object library and set of documentation. VB guys
> have had this for a while. This is where the tides turn and why I think the
> division is almost down the middle. C++ guys can write it all and do about
> every time. Their doc's are lousy they prefer includes to binary objects, and
> they tend to work through a problem than around it (often the only solution
> for a VB guy).
> A C++ gets DOT.NET. He does hello world, learns the types, the callback
> techniques, everything's an object, and starts coding (you get the idea).
> First class he writes needs to store some data, build an array. Need sorting,
> build another array. Want to expose it as enumerable, write an enumerator
> based on sorting array. Need to fetch some HTML page, search Google for C#
> Sockets, and so on. I regularly see this. It's not a question of skill, I
> think probably some very good C++ guys fall victim to this. The fact is C++
> guys tend not to be object consumers but code consumers. Since the include
> concept is essentially gone, they drop it from their mindset and move on.
> Since their used to lame documentation they don't get in depth with the
> dot.net docs so their slow to grasp all of the "do it for you components" the
> framework exposes.
> These issues don't hold true for VB guys. When you give them the framework a
> lot of their code will still work. Enough for them to start doing something
> (which is how they got started in VB the first time). Once they get a light
> grasp of the IDE and the syntax they dive into the documentation. This is
> because VB programmers have been object consumers the whole time, have always
> had to read the component docs, and they KNOW that there are going to be a
> lot of cool "components" in here! They don't write collections they INHERIT
> them. They know what objects are available and what makes the different from
> each other. They know what's easy because they make their living by taking
> the easiest route to delivery. Yes, a VB guy has to grasp OOP, but that's
> easier for them than you may think. They get to look behind the curtain and
> it starts makes sense. Since their damn near expert at consuming commercial
> components they just start saying "How would I like to consume this object"
> and then go and build great interfaces.
> I really don't believe that either camp has an advantage with regards to
> good design and architecture. I'm always stunned to sit in a developer
> meeting for 2 hours to discuss a 5 minute design concept only to do it again
> next week for those that didn't get it the first time.
> I think that the dot.net frame work is much more like an improved version of
> VB than C++. I also think that the OOP hurdle for VB guys is no more
> substantial than the retraining of one's mindset is for a C++ guy.
> Skill is not the key attribute for a developer. It's about productivity and
> all that it encompasses. It's about delivering the product in an unreasonable
> amount of time with a minimal number of bugs that meets the barely defined
> spec and all of the customer's unstated expectations (I should find a
> different trade). You can say a lower level language requires more "Skill"
> and so a programmer in that language is more "Skilled". Of course if I hear
> you I'm going to beat you in the parking lot with an assembly manual. If one
> VB guy delivers a 2 tier solution to market that meets customer expectation
> in the time it takes for three C++ developers to scratch out the data access
> layer, object model and transport layer for the same project who's more
> skilled? Doesn't happen? I see it happen all the time. C++ is expensive, both
> in staff and in development time. Development shops didn't want to manage two
> language teams and so went with all C++ to play it safe. DOT.NET levels much
> that. So, my advice to the two camps is this….
> C++ guys, stop, be nice and explain to the idiot what encapsulation means.
> After all you wouldn't want him to read about it a book somewhere. He might
> just prototype your end of the project before you (for spite) since his
> collection takes 20 lines instead of 120 you wrote.
> VB guys, let it go. You'll be working side by side now and bragging about
> how you've always had this and that and you can believe the hoops they used
> to jump through doesn't make you any friends. Besides, you just might need
> them to help identify your first race condition.
> GOOD GOD, IT'S A BOOK!

"Peter Rilling" wrote:

> > When it comes to ASP.NET development, I'd think VB developers stand the
> > better chance of being more experienced, since classic ASP used VBScript.
> > C++ programmers, while they might be smart people, don't necessarily know
> 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.
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...

"Alvin Bruney" wrote:

> I believe they did. (can of worms here)
> I really don't see a reason for VB.NET given the fact that it certainly
> isn't VB with .NET classes. Eventually, VB.NET will have to morph into
> something else. Programmers who need to learn VB.NET coming from VB classic
> are better off learning C#.
> --
> Regards
> Alvin Bruney
> [Shameless Author Plug]
> The Microsoft Office Web Components Black Book with .NET
> available at www.lulu.com/owc
> ----------------
>
> "Steve C. Orr [MVP, MCSD]" <Steve@dotnet.itags.org.Orr.net> wrote in message
> news:OT3v22TGFHA.3928@dotnet.itags.org.TK2MSFTNGP09.phx.gbl...
> > The main reasons they went with C# is because they were experienced with
> > C++ (becuase C++ was more powerful than VB6) so it was more of a natural
> > progression for them, and the other reason was because C# was the "new"
> > language and they wanted to eat their own dog food to ensure C# would
> > become capable of all that they'd envisioned and all they needed.
> > It wasn't because they saw C# as superior to VB.NET in any way.
> > --
> > I hope this helps,
> > Steve C. Orr, MCSD, MVP
> > http://SteveOrr.net
> > "Robbe Morris [C# MVP]" <info@dotnet.itags.org.turnkeytools.com> wrote in message
> > news:OyR3DzTGFHA.1528@dotnet.itags.org.TK2MSFTNGP09.phx.gbl...
> >> When I saw that when deciding whether to continue on with VB.NET
> >> (I was an old VB 6 and a C# coder), I went with C#.
> >>
> >> I figured if the Microsoft guys saw fit to use C#, maybe I should too.
> >> There must be a reason they picked it.
> >>
> >> --
> >> 2005 Microsoft MVP C#
> >> Robbe Morris
> >> http://www.robbemorris.com
> >> http://www.mastervb.net/home/ng/for...st10017013.aspx
> >> http://www.eggheadcafe.com/articles...e_generator.asp
> >>
> >>
> >>
> >> "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> >> news:%23XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
> >>> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
> >>> seeing many posts about what language to use with ASP.Net. The consensus
> >>> was that employers paid more for C# programmers, and it seems that C#
> >>> became the darling of the ASP.Net crowd.
> >>>
> >>> In the meantime, I have observed an interesting phenomenon. Originally,
> >>> employers hired programmers who used C# because it was based on C, and
> >>> the prevailing opinion was (and may still be) that C# developers were
> >>> better because they must have known and/or practiced C or C++ at some
> >>> time, which would make them better programmers overall. C and C++ are
> >>> hard-core programming languages compared to VB.
> >>>
> >>> However, now that nearly everyone has jumped on the C# bandwagon, it
> >>> seems to me that the distinction between the languages has nearly
> >>> disappeared, at least in terms of evaluating programmers for hire. There
> >>> seem to be almost as many clueless C# developers out there as VB.Net
> >>> developers. Many C# developers today are basically VB.Net developers
> >>> using a different syntax. I wonder if the employers have become aware of
> >>> this trend?
> >>>
> >>> --
> >>>
> >>> Kevin Spencer
> >>> Microsoft MVP
> >>> .Net Developer
> >>> Neither a follower nor a lender be.
> >>>
> >>>
> >>
> >>
>
> 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.

"cmay" <cmay@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:638B4953-D8C4-4E89-9A75-BDF18EF6359C@dotnet.itags.org.microsoft.com...
> Funny... I don't really see a need for C# :)
> There are a few things that C# can do that VB.NET can't, and there are
> things that VB.Net does that C# can't do without added in a bunch of
> VB.NET
> references. But the reason for the very few things that VB.NET can't do
> isn't any limitation of the language. What I mean by that is, MS could,
> if
> they wanted to, add all the extra stuff C# does to vb.net if they cared to
> do
> so. There isn't anything really holding them back from doing that. In
> fact!
> C# is starting to get a lot of the nice features of VB.NET, such as "With"
> blocks.
> Now, I'll be clear that I use both VB.NET and C#, but I clearly prefer
> VB.NET, save a few things that bug me.
> My 2 major annoyances with VB.net, as compared to C# are:
> 1) XML Comments -- I have the XML comments add-in, but it doesn't tie
> into
> the intellisense. It would be nice if my comments showed up in my own
> intellisense function calls in vb.net just like they do in C#.
> 2) The "Dumbifying" of terms. "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...
>
> "Alvin Bruney" wrote:
>> I believe they did. (can of worms here)
>>
>> I really don't see a reason for VB.NET given the fact that it certainly
>> isn't VB with .NET classes. Eventually, VB.NET will have to morph into
>> something else. Programmers who need to learn VB.NET coming from VB
>> classic
>> are better off learning C#.
>>
>> --
>> Regards
>> Alvin Bruney
>> [Shameless Author Plug]
>> The Microsoft Office Web Components Black Book with .NET
>> available at www.lulu.com/owc
>> ----------------
>>
>>
>> "Steve C. Orr [MVP, MCSD]" <Steve@dotnet.itags.org.Orr.net> wrote in message
>> news:OT3v22TGFHA.3928@dotnet.itags.org.TK2MSFTNGP09.phx.gbl...
>> > The main reasons they went with C# is because they were experienced
>> > with
>> > C++ (becuase C++ was more powerful than VB6) so it was more of a
>> > natural
>> > progression for them, and the other reason was because C# was the "new"
>> > language and they wanted to eat their own dog food to ensure C# would
>> > become capable of all that they'd envisioned and all they needed.
>>> > It wasn't because they saw C# as superior to VB.NET in any way.
>>> > --
>> > I hope this helps,
>> > Steve C. Orr, MCSD, MVP
>> > http://SteveOrr.net
>>>> > "Robbe Morris [C# MVP]" <info@dotnet.itags.org.turnkeytools.com> wrote in message
>> > news:OyR3DzTGFHA.1528@dotnet.itags.org.TK2MSFTNGP09.phx.gbl...
>> >> When I saw that when deciding whether to continue on with VB.NET
>> >> (I was an old VB 6 and a C# coder), I went with C#.
>> >>
>> >> I figured if the Microsoft guys saw fit to use C#, maybe I should too.
>> >> There must be a reason they picked it.
>> >>
>> >> --
>> >> 2005 Microsoft MVP C#
>> >> Robbe Morris
>> >> http://www.robbemorris.com
>> >> http://www.mastervb.net/home/ng/for...st10017013.aspx
>> >> http://www.eggheadcafe.com/articles...e_generator.asp
>> >>
>> >>
>> >>
>> >> "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
>> >> news:%23XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
>> >>> About 2 years ago, and as recently as perhaps 1 year ago, I can
>> >>> recall
>> >>> seeing many posts about what language to use with ASP.Net. The
>> >>> consensus
>> >>> was that employers paid more for C# programmers, and it seems that C#
>> >>> became the darling of the ASP.Net crowd.
>> >>>
>> >>> In the meantime, I have observed an interesting phenomenon.
>> >>> Originally,
>> >>> employers hired programmers who used C# because it was based on C,
>> >>> and
>> >>> the prevailing opinion was (and may still be) that C# developers were
>> >>> better because they must have known and/or practiced C or C++ at some
>> >>> time, which would make them better programmers overall. C and C++ are
>> >>> hard-core programming languages compared to VB.
>> >>>
>> >>> However, now that nearly everyone has jumped on the C# bandwagon, it
>> >>> seems to me that the distinction between the languages has nearly
>> >>> disappeared, at least in terms of evaluating programmers for hire.
>> >>> There
>> >>> seem to be almost as many clueless C# developers out there as VB.Net
>> >>> developers. Many C# developers today are basically VB.Net developers
>> >>> using a different syntax. I wonder if the employers have become aware
>> >>> of
>> >>> this trend?
>> >>>
>> >>> --
>> >>>
>> >>> Kevin Spencer
>> >>> Microsoft MVP
>> >>> .Net Developer
>> >>> Neither a follower nor a lender be.
>> >>>
>> >>>
>> >>
>> >>
>>>>
>>
>
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" wrote:

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.

"MajorRugburn" <MajorRugburn@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:88D9830C-7B3C-4FC3-9EA4-2AD36A7507FD@dotnet.itags.org.microsoft.com...
> 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" wrote:
>> 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.
>>
>>
>
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)

"Kevin Spencer" wrote:

> > 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.
> "MajorRugburn" <MajorRugburn@dotnet.itags.org.discussions.microsoft.com> wrote in message
> news:88D9830C-7B3C-4FC3-9EA4-2AD36A7507FD@dotnet.itags.org.microsoft.com...
> > 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" wrote:
> >> 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 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" wrote:

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.

"Shaun Bedingfield" <Shaun Bedingfield@dotnet.itags.org.discussions.microsoft.com> wrote in
message news:1AD26051-CE27-433A-B2F7-FE18C2B95341@dotnet.itags.org.microsoft.com...
>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" wrote:
>> 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 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.

"Kevin Spencer" wrote:

> 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.
> "Shaun Bedingfield" <Shaun Bedingfield@dotnet.itags.org.discussions.microsoft.com> wrote in
> message news:1AD26051-CE27-433A-B2F7-FE18C2B95341@dotnet.itags.org.microsoft.com...
> >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" wrote:
> >> 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.
> >>
> >>
> >>
>
Hi,

"Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
news:OvwcpTPIFHA.2924@dotnet.itags.org.TK2MSFTNGP15.phx.gbl...
> > There are a few things that C# can do that VB.NET can't, and there are
> > things that VB.Net does that C# can't do without added in a bunch of
> > VB.NET
> > references.
> I'm afraid that's just not true. The only things that C# can't do without
a
> bunch of VB.Net References is use the Microsoft.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.
> "cmay" <cmay@dotnet.itags.org.discussions.microsoft.com> wrote in message
> news:638B4953-D8C4-4E89-9A75-BDF18EF6359C@dotnet.itags.org.microsoft.com...
> > Funny... I don't really see a need for C# :)
> > There are a few things that C# can do that VB.NET can't, and there are
> > things that VB.Net does that C# can't do without added in a bunch of
> > VB.NET
> > references. But the reason for the very few things that VB.NET can't do
> > isn't any limitation of the language. What I mean by that is, MS could,
> > if
> > they wanted to, add all the extra stuff C# does to vb.net if they cared
to
> > do
> > so. There isn't anything really holding them back from doing that. In
> > fact!
> > C# is starting to get a lot of the nice features of VB.NET, such as
"With"
> > blocks.
> > Now, I'll be clear that I use both VB.NET and C#, but I clearly prefer
> > VB.NET, save a few things that bug me.
> > My 2 major annoyances with VB.net, as compared to C# are:
> > 1) XML Comments -- I have the XML comments add-in, but it doesn't tie
> > into
> > the intellisense. It would be nice if my comments showed up in my own
> > intellisense function calls in vb.net just like they do in C#.
> > 2) The "Dumbifying" of terms. "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...
> > "Alvin Bruney" wrote:
> >> I believe they did. (can of worms here)
> >>
> >> I really don't see a reason for VB.NET given the fact that it certainly
> >> isn't VB with .NET classes. Eventually, VB.NET will have to morph into
> >> something else. Programmers who need to learn VB.NET coming from VB
> >> classic
> >> are better off learning C#.
> >>
> >> --
> >> Regards
> >> Alvin Bruney
> >> [Shameless Author Plug]
> >> The Microsoft Office Web Components Black Book with .NET
> >> available at www.lulu.com/owc
> >> ----------------
> >>
> >>
> >> "Steve C. Orr [MVP, MCSD]" <Steve@dotnet.itags.org.Orr.net> wrote in message
> >> news:OT3v22TGFHA.3928@dotnet.itags.org.TK2MSFTNGP09.phx.gbl...
> >> > The main reasons they went with C# is because they were experienced
> >> > with
> >> > C++ (becuase C++ was more powerful than VB6) so it was more of a
> >> > natural
> >> > progression for them, and the other reason was because C# was the
"new"
> >> > language and they wanted to eat their own dog food to ensure C# would
> >> > become capable of all that they'd envisioned and all they needed.
> >> >> > It wasn't because they saw C# as superior to VB.NET in any way.
> >> >> > --
> >> > I hope this helps,
> >> > Steve C. Orr, MCSD, MVP
> >> > http://SteveOrr.net
> >> >> >> > "Robbe Morris [C# MVP]" <info@dotnet.itags.org.turnkeytools.com> wrote in message
> >> > news:OyR3DzTGFHA.1528@dotnet.itags.org.TK2MSFTNGP09.phx.gbl...
> >> >> When I saw that when deciding whether to continue on with VB.NET
> >> >> (I was an old VB 6 and a C# coder), I went with C#.
> >> >>
> >> >> I figured if the Microsoft guys saw fit to use C#, maybe I should
too.
> >> >> There must be a reason they picked it.
> >> >>
> >> >> --
> >> >> 2005 Microsoft MVP C#
> >> >> Robbe Morris
> >> >> http://www.robbemorris.com
> >> >> http://www.mastervb.net/home/ng/for...st10017013.aspx
> >> >> http://www.eggheadcafe.com/articles...e_generator.asp
> >> >>
> >> >>
> >> >>
> >> >> "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> >> >> news:%23XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
> >> >>> About 2 years ago, and as recently as perhaps 1 year ago, I can
> >> >>> recall
> >> >>> seeing many posts about what language to use with ASP.Net. The
> >> >>> consensus
> >> >>> was that employers paid more for C# programmers, and it seems that
C#
> >> >>> became the darling of the ASP.Net crowd.
> >> >>>
> >> >>> In the meantime, I have observed an interesting phenomenon.
> >> >>> Originally,
> >> >>> employers hired programmers who used C# because it was based on C,
> >> >>> and
> >> >>> the prevailing opinion was (and may still be) that C# developers
were
> >> >>> better because they must have known and/or practiced C or C++ at
some
> >> >>> time, which would make them better programmers overall. C and C++
are
> >> >>> hard-core programming languages compared to VB.
> >> >>>
> >> >>> However, now that nearly everyone has jumped on the C# bandwagon,
it
> >> >>> seems to me that the distinction between the languages has nearly
> >> >>> disappeared, at least in terms of evaluating programmers for hire.
> >> >>> There
> >> >>> seem to be almost as many clueless C# developers out there as
VB.Net
> >> >>> developers. Many C# developers today are basically VB.Net
developers
> >> >>> using a different syntax. I wonder if the employers have become
aware
> >> >>> of
> >> >>> this trend?
> >> >>>
> >> >>> --
> >> >>>
> >> >>> Kevin Spencer
> >> >>> Microsoft MVP
> >> >>> .Net Developer
> >> >>> Neither a follower nor a lender be.
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >> >>
> >>
> >>
C# shops also hope to draw from the pool of Java developers as well as OOP
developers. The Jave devs have network/web experience already.

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

"Peter Rilling" wrote:

> Okay, I write this message with the full knowledge that I am going to piss a
> large number of people off. So I fully expect some flaming to happen.
> As languages evolve, there becomes less and less that differentiates them.
> There is nothing that you can do in C# that you cannot do in VB.NET.
> I came from a VB development background and moved to C# about five years
> ago. I do not necessarily think that companies look for C# people because
> of the tie-in with C++, but rather that C# develops have more of an OOP
> sense about them. C++ and C# are object oriented languages and therefore
> those people tend to think in object design. VB used to be thought of a toy
> and only used for RAD development. There was little emphasis placed on
> proper coding styles. It was more of a "let's get it done" mentality rather
> then "let's design something for expandability and maintainability". Keep
> in mind that until VB.NET was released, the concept of classes was shoddy at
> best and certainly did not have inheritance or polymorphism, which means
> that VB was NEVER an object oriented languages.
> Remember that when the GUI first came out it was also thought of as a toy.
> Why would real computer uses use a graphical interface, was the mantra of my
> command-line gurus.
> "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> news:#XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
> > About 2 years ago, and as recently as perhaps 1 year ago, I can recall
> > seeing many posts about what language to use with ASP.Net. The consensus
> was
> > that employers paid more for C# programmers, and it seems that C# became
> the
> > darling of the ASP.Net crowd.
> > In the meantime, I have observed an interesting phenomenon. Originally,
> > employers hired programmers who used C# because it was based on C, and the
> > prevailing opinion was (and may still be) that C# developers were better
> > because they must have known and/or practiced C or C++ at some time, which
> > would make them better programmers overall. C and C++ are hard-core
> > programming languages compared to VB.
> > However, now that nearly everyone has jumped on the C# bandwagon, it seems
> > to me that the distinction between the languages has nearly disappeared,
> at
> > least in terms of evaluating programmers for hire. There seem to be almost
> > as many clueless C# developers out there as VB.Net developers. Many C#
> > developers today are basically VB.Net developers using a different syntax.
> I
> > wonder if the employers have become aware of this trend?
> > --
> > Kevin Spencer
> > Microsoft MVP
> > .Net Developer
> > Neither a follower nor a lender be.
>
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)
> So why C#? While VB programmers tend to have more "business" experience
> then
> C programmers, if they learned to program the "Microsoft" way the code is
> difficult to maintain and not preform well. Also, VB programms tend to be
> on
> the small side.

Oh, so you're a "heightist," eh? Don't like small people? ;-)

--
HTH,

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

"Ken G." <Ken G.@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:B6C94583-E8CC-4159-A2B2-279F220770C3@dotnet.itags.org.microsoft.com...
> Durring the 30 odd years I've been in this business the question of which
> language to use has come up many times. My obersavation, for what its
> worth,
> is that the more that a language/development tool dose for you the less
> the
> programmer thinks about what they are doing. This can lead to code that is
> harder to maintain and has performance issues. This is not always the
> case,
> one can write bad code in any language.
> As for VB vs C#, while most ASP pages are programmed in VB Script, there
> isn't really a choice. All though I use VB Script alot, I prefer a more
> "robust" language.
> We are in the process of converting our website from ASP using VB Script
> to
> .NET using C#.
> So why C#? While VB programmers tend to have more "business" experience
> then
> C programmers, if they learned to program the "Microsoft" way the code is
> difficult to maintain and not preform well. Also, VB programms tend to be
> on
> the small side.
> We booked 75k orders on our website last month. That number is expected to
> double in 6 months. We have to think very carefully about how our code is
> written and C programmers have more experience doing that.
> All that said, I continue to use VB for small desktop apps & VB Script for
> lower volume web sites. For us it was a choice between C# or Java (which
> is a
> much longer descussion)
>>So, in fact, while C# can do anything that VB.Net can, VB.Net can not
do
>>everything that C# can.

How about:

Late Binding

Multiple indexed properties

Ease of COM Interop

Optional Parameters

Edit and Continue functionality

User filtered Exception trapping

Better intellisense

Better syntax error recognition in IDE (background compile)

Select Case

With

Productivity.

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

I guess if using unmanaged code is extremely important to your project,
then one would be foolish to pick VB.net over C#, but for the avg
developer, why wouldn't they choose vb.net and if they ever needed to
access unmanaged code, just write a C# DLL?

I think the VB/C# debate can be summed up like this
VB.NET -- "I am TOO a programmer! Please, won't some C++ developers
out there agree??"
C# -- "It's not a real programming language unless it uses brackets."
C++ -- "I'll never concede to be equal to anything"
> 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.
> But in terms of C# versus VB.NET, then the differences really are small
> now and come down to whether you prefer one syntax over another with a few
> enhancements on either side.
> I'm not sure though that there is any particular problem than couldn't be
> coded in either language.

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

--
HTH,

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

"Rob Nicholson" <rob.nicholson@dotnet.itags.org.nospam-unforgettable.com> wrote in message
news:e6dtqsQJFHA.2704@dotnet.itags.org.tk2msftngp13.phx.gbl...
>> We booked 75k orders on our website last month. That number is expected
>> to
>> double in 6 months. We have to think very carefully about how our code is
>> written and C programmers have more experience doing that.
> Isn't that really all about how you implement the problem, not the
> underlying language. After all, you *could* write the whole thing in
> assembler and it would work equally as well. Would take you a lot longer
> though. In a large program, your problems are algorithmic, not
> syntactical - for example, the most efficient way to store and retrieve
> your data from the database or reducing the number of postbacks required.
> However, I can see where are coming from historically. C is somewhere
> between assembler and VB, sort of a mid-level language as opposed to a
> high level like Pascal or low-level like assembler or even Forth.
> Therefore, C programmers were "closer to the metal" which often gave them
> a better understanding of the underlying architecture. And as much of the
> early APIs were also written in C, the interface between the operating
> system and C was a better fit. I'm thinking here of bit level operations
> and structures. VB's early lack of pointers et al made it harder to
> interface with the operating system.
> C++ was first out of the gates with a popular class OO language so C++
> programmers got a head start there as well.
> So all these things together (closer to the metal, better interface to
> API/OS, classes) made your C/C++ programmer a "better" programmer.
> But in terms of C# versus VB.NET, then the differences really are small
> now and come down to whether you prefer one syntax over another with a few
> enhancements on either side.
> I'm not sure though that there is any particular problem than couldn't be
> coded in either language.
> Rob.
I'm afraid your arguments simply indict you and (by association) other VB
programmers, and may in fact add to the impression of VB programmers not
being too savvy. Why?

> Late Binding

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

> Multiple indexed properties

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

> Ease of COM Interop

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

> Optional Parameters

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

> Edit and Continue functionality

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

> User filtered Exception trapping

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

> Better intellisense

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

> Better syntax error recognition in IDE (background compile)

This is getting embarassing (Visual Studio.Net again)
> Select Case

switch() in C#

> With

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

> Productivity.

Huh?

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

--
HTH,

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

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

"Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
news:unpN%238XJFHA.3336@dotnet.itags.org.TK2MSFTNGP10.phx.gbl...
> I'm afraid your arguments simply indict you and (by association) other VB
> programmers, and may in fact add to the impression of VB programmers not
> being too savvy. Why?
> > Late Binding
> Is this a good thing? (Answer: no - Late Binding is something to be
avoided)

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

> > Multiple indexed properties
> You got me there. This can be achieved with C# however, using a different
> syntax.
> > Ease of COM Interop
> Is that a good thing? Regardless, both languages can use COM Interop, and
> there is no difference in performance. You're talking about the ease of
> writing the code there.

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

> > Optional Parameters
> Optional Parameters is really a wrapper for overloading. It is not unique
to
> VB.
> > Edit and Continue functionality
> What does this have to do with VB? This is a feature of the VS.Net IDE.

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

> > User filtered Exception trapping
> Sorry. Each language implements this, just a bit differently.
> > Better intellisense
> Again, you're mixing up Visual Studio.Net with Visual Basic.Net.

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

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

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

> > Select Case
> switch() in C#
> > With
> A handy little tool for developers, but makes no difference in the app.
> > Productivity.
> Huh?
> BTW, I did not mention ALL of the language features that C# has which
VB.Net
> does not, only the most salient ones (ones which affect the performance of
> the app, or which may be necessary, but are not available in VB). There
are
> some situations in which you can NOT do away with pointers. There are NO
> situations in which you can NOT do away with, for example, the With
> statement.
> --
> HTH,
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> What You Seek Is What You Get.
> "cmay" <cmay@dotnet.itags.org.walshgroup.com> wrote in message
> news:1110415830.837026.229630@dotnet.itags.org.z14g2000cwz.googlegr oups.com...
> >>>So, in fact, while C# can do anything that VB.Net can, VB.Net can not
> > do
> >>>everything that C# can.
> > How about:
> > Late Binding
> > Multiple indexed properties
> > Ease of COM Interop
> > Optional Parameters
> > Edit and Continue functionality
> > User filtered Exception trapping
> > Better intellisense
> > Better syntax error recognition in IDE (background compile)
> > Select Case
> > With
> > Productivity.
> > When MS decides to allow VB.net to use unmanaged code, then what?
> > I guess if using unmanaged code is extremely important to your project,
> > then one would be foolish to pick VB.net over C#, but for the avg
> > developer, why wouldn't they choose vb.net and if they ever needed to
> > access unmanaged code, just write a C# DLL?
> > I think the VB/C# debate can be summed up like this
> > VB.NET -- "I am TOO a programmer! Please, won't some C++ developers
> > out there agree??"
> > C# -- "It's not a real programming language unless it uses brackets."
> > C++ -- "I'll never concede to be equal to anything"
> not true.
> I have run across a few com components that just could not be used in any
> reasonable fashion from c# but worked perfectly well with vb.
> This being due to ill-designed com servers that expose everything as
> Objects
> and c#'s ( lack of ) late binding. Of course you may consider wrapping an
> untyped com object with a class that implements zillion InvokeMember()
> calls as a reasonable solution - I personally don't

I have run across a few hills that were too steep to climb. Oops.
Correction. I have run a across a few hills that I could not climb. They
weren't too steep for everyyone to climb. How would I know that? All I know
is, I couldn't climb them. On the other hand, I don't live near any hills,
and climbing hills is not a good thing to do. So it really doesn't matter.

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

Okay, so how do you edit and continue using the command-line compiler? How
do you edit and continue while debugging a VB.Net file you're composing in
Notepad? And how does Edit and Continue make your app run better? Or
perhaps, just maybe, this may be part of the "language module" that has
nothing to do with the language, but the IDE?

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

See MY last point.

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

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

--
HTH,

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

"gerry" <germ@dotnet.itags.org.hotmail.com> wrote in message
news:OoN$ecYJFHA.3084@dotnet.itags.org.TK2MSFTNGP10.phx.gbl...
> just 2 cents from a coder who could not care less about the incessant vb
> vc
> c# debate
> "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> news:unpN%238XJFHA.3336@dotnet.itags.org.TK2MSFTNGP10.phx.gbl...
>> I'm afraid your arguments simply indict you and (by association) other VB
>> programmers, and may in fact add to the impression of VB programmers not
>> being too savvy. Why?
>>
>> > Late Binding
>>
>> Is this a good thing? (Answer: no - Late Binding is something to be
> avoided)
> well that is one opinion - and not always possible - see below.
>>
>> > Multiple indexed properties
>>
>> You got me there. This can be achieved with C# however, using a different
>> syntax.
>>
>> > Ease of COM Interop
>>
>> Is that a good thing? Regardless, both languages can use COM Interop, and
>> there is no difference in performance. You're talking about the ease of
>> writing the code there.
> not true.
> I have run across a few com components that just could not be used in any
> reasonable fashion from c# but worked perfectly well with vb.
> This being due to ill-designed com servers that expose everything as
> Objects
> and c#'s ( lack of ) late binding. Of course you may consider wrapping an
> untyped com object with a class that implements zillion InvokeMember()
> calls as a reasonable solution - I personally don't
>>
>> > Optional Parameters
>>
>> Optional Parameters is really a wrapper for overloading. It is not unique
> to
>> VB.
>>
>> > Edit and Continue functionality
>>
>> What does this have to do with VB? This is a feature of the VS.Net IDE.
> not really - if it was then all languages would support it.
> Edit & Continue may be facilitated by the ide but is still up to the
> language module to enable it.
>>
>> > User filtered Exception trapping
>>
>> Sorry. Each language implements this, just a bit differently.
>>
>> > Better intellisense
>>
>> Again, you're mixing up Visual Studio.Net with Visual Basic.Net.
> ok so the ide displays the intellisense BUT it is entirely based on
> information that comes from the langauge module
> see last point.
>>
>> > Better syntax error recognition in IDE (background compile)
>>
>> This is getting embarassing (Visual Studio.Net again)
> same as last points - if you've ever implemented a langauge for use within
> the vs.net ide via VSIP you would know that syntax recognition like
> intellisense like edit & continue is entirely dependant upon the language
> module - the ide is just a front end facilitator , if these aren't
> provided
> by the language module, you won't get them.
>> > Select Case
>>
>> switch() in C#
>>
>> > With
>>
>> A handy little tool for developers, but makes no difference in the app.
>>
>> > Productivity.
>>
>> Huh?
>>
>> BTW, I did not mention ALL of the language features that C# has which
> VB.Net
>> does not, only the most salient ones (ones which affect the performance
>> of
>> the app, or which may be necessary, but are not available in VB). There
> are
>> some situations in which you can NOT do away with pointers. There are NO
>> situations in which you can NOT do away with, for example, the With
>> statement.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> .Net Developer
>> What You Seek Is What You Get.
>>
>> "cmay" <cmay@dotnet.itags.org.walshgroup.com> wrote in message
>> news:1110415830.837026.229630@dotnet.itags.org.z14g2000cwz.googlegr oups.com...
>> >>>So, in fact, while C# can do anything that VB.Net can, VB.Net can not
>> > do
>> >>>everything that C# can.
>>> > How about:
>>> > Late Binding
>>> > Multiple indexed properties
>>> > Ease of COM Interop
>>> > Optional Parameters
>>> > Edit and Continue functionality
>>> > User filtered Exception trapping
>>> > Better intellisense
>>> > Better syntax error recognition in IDE (background compile)
>>> > Select Case
>>> > With
>>> > Productivity.
>>>> > When MS decides to allow VB.net to use unmanaged code, then what?
>>>>> > I guess if using unmanaged code is extremely important to your project,
>> > then one would be foolish to pick VB.net over C#, but for the avg
>> > developer, why wouldn't they choose vb.net and if they ever needed to
>> > access unmanaged code, just write a C# DLL?
>>>> > I think the VB/C# debate can be summed up like this
>> > VB.NET -- "I am TOO a programmer! Please, won't some C++ developers
>> > out there agree??"
>> > C# -- "It's not a real programming language unless it uses brackets."
>> > C++ -- "I'll never concede to be equal to anything"
>>>
>>

"Kevin Spencer" wrote:

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??)
Microsoft will never do away with VB.Net.

--
HTH,

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

"move to c#" <move to c#@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:F3C981A0-8467-4D49-8289-CA79E9882ECD@dotnet.itags.org.microsoft.com...
>
> "Kevin Spencer" wrote:
>> 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??)
> 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.
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.
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.

"cmay" <cmay@dotnet.itags.org.walshgroup.com> wrote in message
news:1110486263.236140.62090@dotnet.itags.org.g14g2000cwa.googlegro ups.com...
> 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.
out of curiousity, why is your company still writing code in vb6. is it
mainly maintainance or is that new development?

"Rob Nicholson" <rob.nicholson@dotnet.itags.org.nospam-unforgettable.com> wrote in message
news:Otu#2caJFHA.2772@dotnet.itags.org.TK2MSFTNGP14.phx.gbl...
> > 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.
"Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
news:OXYducaJFHA.580@dotnet.itags.org.TK2MSFTNGP15.phx.gbl...
> 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

> --
> HTH,
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> What You Seek Is What You Get.
> "move to c#" <move to c#@dotnet.itags.org.discussions.microsoft.com> wrote in message
> news:F3C981A0-8467-4D49-8289-CA79E9882ECD@dotnet.itags.org.microsoft.com...
>>
>>
>> "Kevin Spencer" wrote:
>>
>>> 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??)

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

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

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

"DotNet Coder" wrote:

> "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> news:OXYducaJFHA.580@dotnet.itags.org.TK2MSFTNGP15.phx.gbl...
> > 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
>
> > --
> > HTH,
> > Kevin Spencer
> > Microsoft MVP
> > .Net Developer
> > What You Seek Is What You Get.
> > "move to c#" <move to c#@dotnet.itags.org.discussions.microsoft.com> wrote in message
> > news:F3C981A0-8467-4D49-8289-CA79E9882ECD@dotnet.itags.org.microsoft.com...
> >>
> >>
> >> "Kevin Spencer" wrote:
> >>
> >>> 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??)
>
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.

"Kevin Spencer" wrote:

> > 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.
> "cmay" <cmay@dotnet.itags.org.discussions.microsoft.com> wrote in message
> news:638B4953-D8C4-4E89-9A75-BDF18EF6359C@dotnet.itags.org.microsoft.com...
> > Funny... I don't really see a need for C# :)
> > There are a few things that C# can do that VB.NET can't, and there are
> > things that VB.Net does that C# can't do without added in a bunch of
> > VB.NET
> > references. But the reason for the very few things that VB.NET can't do
> > isn't any limitation of the language. What I mean by that is, MS could,
> > if
> > they wanted to, add all the extra stuff C# does to vb.net if they cared to
> > do
> > so. There isn't anything really holding them back from doing that. In
> > fact!
> > C# is starting to get a lot of the nice features of VB.NET, such as "With"
> > blocks.
> > Now, I'll be clear that I use both VB.NET and C#, but I clearly prefer
> > VB.NET, save a few things that bug me.
> > My 2 major annoyances with VB.net, as compared to C# are:
> > 1) XML Comments -- I have the XML comments add-in, but it doesn't tie
> > into
> > the intellisense. It would be nice if my comments showed up in my own
> > intellisense function calls in vb.net just like they do in C#.
> > 2) The "Dumbifying" of terms. "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...
> > "Alvin Bruney" wrote:
> >> I believe they did. (can of worms here)
> >>
> >> I really don't see a reason for VB.NET given the fact that it certainly
> >> isn't VB with .NET classes. Eventually, VB.NET will have to morph into
> >> something else. Programmers who need to learn VB.NET coming from VB
> >> classic
> >> are better off learning C#.
> >>
> >> --
> >> Regards
> >> Alvin Bruney
> >> [Shameless Author Plug]
> >> The Microsoft Office Web Components Black Book with .NET
> >> available at www.lulu.com/owc
> >> ----------------
> >>
> >>
> >> "Steve C. Orr [MVP, MCSD]" <Steve@dotnet.itags.org.Orr.net> wrote in message
> >> news:OT3v22TGFHA.3928@dotnet.itags.org.TK2MSFTNGP09.phx.gbl...
> >> > The main reasons they went with C# is because they were experienced
> >> > with
> >> > C++ (becuase C++ was more powerful than VB6) so it was more of a
> >> > natural
> >> > progression for them, and the other reason was because C# was the "new"
> >> > language and they wanted to eat their own dog food to ensure C# would
> >> > become capable of all that they'd envisioned and all they needed.
> >> >> > It wasn't because they saw C# as superior to VB.NET in any way.
> >> >> > --
> >> > I hope this helps,
> >> > Steve C. Orr, MCSD, MVP
> >> > http://SteveOrr.net
> >> >> >> > "Robbe Morris [C# MVP]" <info@dotnet.itags.org.turnkeytools.com> wrote in message
> >> > news:OyR3DzTGFHA.1528@dotnet.itags.org.TK2MSFTNGP09.phx.gbl...
> >> >> When I saw that when deciding whether to continue on with VB.NET
> >> >> (I was an old VB 6 and a C# coder), I went with C#.
> >> >>
> >> >> I figured if the Microsoft guys saw fit to use C#, maybe I should too.
> >> >> There must be a reason they picked it.
> >> >>
> >> >> --
> >> >> 2005 Microsoft MVP C#
> >> >> Robbe Morris
> >> >> http://www.robbemorris.com
> >> >> http://www.mastervb.net/home/ng/for...st10017013.aspx
> >> >> http://www.eggheadcafe.com/articles...e_generator.asp
> >> >>
> >> >>
> >> >>
> >> >> "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> >> >> news:%23XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
> >> >>> About 2 years ago, and as recently as perhaps 1 year ago, I can
> >> >>> recall
> >> >>> seeing many posts about what language to use with ASP.Net. The
> >> >>> consensus
> >> >>> was that employers paid more for C# programmers, and it seems that C#
> >> >>> became the darling of the ASP.Net crowd.
> >> >>>
> >> >>> In the meantime, I have observed an interesting phenomenon.
> >> >>> Originally,
> >> >>> employers hired programmers who used C# because it was based on C,
> >> >>> and
> >> >>> the prevailing opinion was (and may still be) that C# developers were
> >> >>> better because they must have known and/or practiced C or C++ at some
> >> >>> time, which would make them better programmers overall. C and C++ are
> >> >>> hard-core programming languages compared to VB.
> >> >>>
> >> >>> However, now that nearly everyone has jumped on the C# bandwagon, it
> >> >>> seems to me that the distinction between the languages has nearly
> >> >>> disappeared, at least in terms of evaluating programmers for hire.
> >> >>> There
> >> >>> seem to be almost as many clueless C# developers out there as VB.Net
> >> >>> developers. Many C# developers today are basically VB.Net developers
> >> >>> using a different syntax. I wonder if the employers have become aware
> >> >>> of
> >> >>> this trend?
> >> >>>
> >> >>> --
> >> >>>
> >> >>> Kevin Spencer
> >> >>> Microsoft MVP
> >> >>> .Net Developer
> >> >>> Neither a follower nor a lender be.
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >> >>
> >>
> >>
>
> 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.
> 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.
> 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/arc...3/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.
> 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" <rob.nicholson@dotnet.itags.org.nospam-unforgettable.com> wrote in message
news:%23mxPL%23hJFHA.3420@dotnet.itags.org.tk2msftngp13.phx.gbl...
>> 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/arc...3/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.
"Rob Nicholson" <rob.nicholson@dotnet.itags.org.nospam-unforgettable.com> wrote in message
news:eu9Qq7hJFHA.2716@dotnet.itags.org.TK2MSFTNGP15.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.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 :-)

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

> > 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.
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
> 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.
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.
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" <cmay@dotnet.itags.org.walshgroup.com> wrote in message
news:1110568932.220411.235160@dotnet.itags.org.g14g2000cwa.googlegr oups.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.
Anyone who thinks c# programmers are 'better' than VB programmers is an
idiot. Has it ever occured to people like you that the core competence of a
VB developer might be in the business rules they are trying to fulfill, and
that the vision of such a language might be to remove all the uneccessary
complexity from programming so as to allow such an individual to do just
that? By your reasoning, the habbits of an assembler programmer would be
welcome as a sign of intelligence towards OOPs related tasks! I am really
sorry guy but the time for knowing that the bios looks in the first boot
sector at address 0800 to start running the operating system is OVER. VB has
evolved into a powerfull programming language for fulfilling business rules.
C and C++ are low level languages that, becuase of their features, can be
used for system development and the like. Saying a C developer is 'smarter'
or 'better' at what they do is like saying a builder is smarter than an
engineer, or an engineer smarter than an architect!

"move to c#" wrote:

>
> "Kevin Spencer" wrote:
> > 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??)
> Anyone who thinks c# programmers are 'better' than VB programmers is an
> idiot.

I wouldn't put it that way, but in essence I agree with you there.

> Has it ever occured to people like you that the core competence of a
> VB developer might be in the business rules they are trying to fulfill,
> and
> that the vision of such a language might be to remove all the uneccessary
> complexity from programming so as to allow such an individual to do just
> that?

Are you responding to my post? I will assume that "people like you" is a
reference to people like myself. Please point out where I made the statement
that C# programmers are better than VB programmers. A careful reading of my
message will prove the opposite. There is a big difference between the
reality of things, and the way things are perceived by many people. I was
talking about perceptions, not reality.

> By your reasoning, the habbits of an assembler programmer would be
> welcome as a sign of intelligence towards OOPs related tasks!

I'm afraid not. By my reasoning, there is a perception out there that has
nearly nothing to do with reality. It is your perception of my reasoning
that is in error.

> I am really
> sorry guy but the time for knowing that the bios looks in the first boot
> sector at address 0800 to start running the operating system is OVER.

Maybe for you, but not for everyone. In any case, I didn't imply any such
thing.

>VB has
> evolved into a powerfull programming language for fulfilling business
> rules.
> C and C++ are low level languages that, becuase of their features, can be
> used for system development and the like.

I don't develop systems. I develop applications. Some of those applications
require low-level programming. So, while you seem familiar with VB, you
don't seem to understand much of anything about the use of C and its
derivatives.

This is an odd post. It seems to be in reply to "move to c#" but all of its
arguments seem to be against my own. If this is the case, the writer didn't
read my post carefully, and misunderstood it almost entirely. Pretty sloppy
work for a programmer.

BTW, will someone remove the "Kick Me" sign from my back?

--
HTH,

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

"moemeka" <moemeka@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:630CCC6A-5EF6-40C7-9936-C37EA90CBECA@dotnet.itags.org.microsoft.com...
> Anyone who thinks c# programmers are 'better' than VB programmers is an
> idiot. Has it ever occured to people like you that the core competence of
> a
> VB developer might be in the business rules they are trying to fulfill,
> and
> that the vision of such a language might be to remove all the uneccessary
> complexity from programming so as to allow such an individual to do just
> that? By your reasoning, the habbits of an assembler programmer would be
> welcome as a sign of intelligence towards OOPs related tasks! I am really
> sorry guy but the time for knowing that the bios looks in the first boot
> sector at address 0800 to start running the operating system is OVER. VB
> has
> evolved into a powerfull programming language for fulfilling business
> rules.
> C and C++ are low level languages that, becuase of their features, can be
> used for system development and the like. Saying a C developer is
> 'smarter'
> or 'better' at what they do is like saying a builder is smarter than an
> engineer, or an engineer smarter than an architect!
> "move to c#" wrote:
>>
>>
>> "Kevin Spencer" wrote:
>>
>> > 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??)

"Smithers" wrote:

> IMHO, the incompetence you are seeing more of is people jumping to Web
> development from desktop/thick client application development. Take any
> "hard core" C++ developer awash in all his/her OOP glory: If this person has
> never developed for the Web and has instead spent a career doing low-level
> programming (device drivers, etc), and throw them into a Web Application,
> they'll probably be asking a lot of dumb questions - of the same sort you
> are currently attributing to the VB6 crowd. IMHO, it's the application type
> (Web vs desktop), not the prior language.

An interesting point. I myself started in web and have moved over to
winapps. Maybe because Perl and PHP are C-esque languages I had an easier
transition.
Let me preface this with: If you do a quick scan up this thread, you
can see that I like vb.net, so this isn't coming from a vb hater.

However, regarding the "C# developers are better" thing, I'm sorry to
say that, even though I prefer vb.net, I would tend to agree with that
statement as a generality.

Now... having said that. I know lots of people who ONLY program in C#,
and my skills are FAR more than theirs in C#, VB, systems and on and
on. I'm not tooting my horn here, just stating the obvious "just cause
you use C# doesn't mean you are better than someone who users VB".

But, I have to say. If I were interviewing someone who was very good
at vb.net, but had no idea when it comes to C# I would think a lot less
of them than someone who programs in C# who knows nothing about VB.

Why is this?

It is obvious to me that new programmers (less experienced) would pick
VB over C#. So a larger portion of VB.Net developers are "newer" to
programming. What about the argument "A new programmer would look at
both languages and see that people value C# more and pick it as their
starting language" ? I would suggest that people who take that
approach are of a different mindset than the people who are thinking
"how can I get response.write to work with these crazy code behind page
things?". In other words, people who research the languages and make
an informed decision about picking one language over the other, not
matter which one they pick, are probably destined to be very good at
their job.

Also, as Kevin Spencer points out, C# isn't new (C -> C++ -> C#). C#
has many links with ECMA script which in is related to many other
languages. So in other words, imagine you took 2 people who had never
programmed a day in their life. One of them got 6 months to learn and
work with VB.Net, and the other got 6 months to learn and work with C#.
Then after 6 months you asked them to write a java app, or a client
side javascript program. The C# guy would have such an advantage b/c
the syntax is so similar.

So, basically what I am saying is, that if someone suggest that a
person is less able or competent because they work in vb.net I would
strongly disagree. However, if you want to say that the avg C#
programmer is a "better" programmer than the avg VB.Net programmer,
then I would have to agree.

I wouldn't just apply this to C# and VB though. I think the same could
be said of PHP, VFP, VBscript (vs Javascript) etc.

If someone thinks that there aren't PHP developers out there that are
fricking smart as hell, then they are wrong cause some of those guys
(dedicated PHP programmers) are brilliant! But, I would bet that if
show me a great PHP programmer (or any of the other languages listed
above) I will show you a person who can understand and read (and
probably write) most other languages, and has a very strong knowledge
over all the non-language related skills involved in programming.
"Cowboy (Gregory A. Beamer) - MVP" wrote:

> There are plenty of clueless C++, VB, et al, developer.

There's a reason for this:

"You don't have to be good, just good enough."
-me, ca. late 80s

You can also consider things such as "bad coders can write bad code faster
than good coders can write good code" (or good coders can fix bad code).
People like to code and like to get paid for something they like to do. This
is without regard to the quality of the work they produce. Generally, the
only measurement of the quality is "does it work?".

Code reviews are a rarity. Documents are a thing of even farther in the
past. Besides, most technical people can't write their way out of a paper bag
so why should they write docs which are worthless? Granted, there are people
who write them professionally, but do smaller shops which only have one, two,
or three technical people on staff have to have a technical writer who only
writes docs? Ever look at the code someone has written for a group they
belong to? Service group? Church? Charity? There are plenty of good people
who write for such groups but there are plenty who have members who willingly
hop into the pool (and pee in the water) and deliver, at best, something
someone who took a first year VB course could improve upon.

Priority #1 is get to the keyboard and bang away at code. Forget specs.
Forget everything. Keyboard is #1.

In one of the blogs where everyone is whining about VB6, "Dougie" is
throwing a fit because the 200'000 lines of code he's written over the
previous twenty years are going to have to be rewritten because VB6 is going
away. His credentials are he not only knows VB but, "and for your
information, I can code in C, pascal, delphi as well as vb". I'm guessing
most of his code is a clusterf%ck and most of it hasn't been partitioned into
various DLLs, out-of-process EXEs, classes, etc. Things which not only would
be easier to manage but migrate as well. I think he'd fit real well with a
co-worker at a contracting firm I worked for who claimed, "There's nothing
you can do with OOP which you can't do with modules." And said his MBA gave
him the divine wisdom to know such things. The funny thing is we were billed
out at $125 for VB work and he wrote & debugged code by trial-and-error (I'm
not joking about any of this). The boss|owner loved him because he raked in
the dough but anyone who had to follow in his footsteps and either fix or add
to his code either kept a wastebasket handy (to barf) or rewrote the apps on
their own time, lest they have to work with it again. It was about as tasty
as one of the Star Trek animated series when an ESP-capable member of a
feline race begins to get nauseated because one of the Enterprise crew
focuses so heavily upon eating vegetation. That's what it felt like to work
with Brent's code.

I know others are upset but I think Dougie represents a vocal group who
couldn't buy a clue if you handed them the money; and he's pretty
representative of the industry as a whole.

You can find Dougie here to look for yourself:

http://tinyurl.com/6szrc

http://blogs.msdn.com/brad_mccabe/a.../10/393704.aspx

> ***************************
> Think Outside the Box!
> ***************************

(This is trite and a poor interpretation of deMarco's "Lateral Thinking" - I
suggest you get one of his books...)

> "Kevin Spencer" wrote:

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

And before ASP.Net, it was ASP. Employers paid a lot more (and still do)
for ASP. The problem is a sizeable percentage of the ASP crowd were rats
jumping off of a sinking ship - all of the static HTMLers realizing their
pond was shrinking and they'd better jump...fast. Think about non-programmers
writing ASP + client-side JScript. Fortunately, a measure of competency
became a requirement and started to turn the tide.

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

At the risk of sounding rude, how is this the demise of c#?
> "You don't have to be good, just good enough."
> -me, ca. late 80s
> You can also consider things such as "bad coders can write bad code faster
> than good coders can write good code" (or good coders can fix bad code).
> People like to code and like to get paid for something they like to do.
> This
> is without regard to the quality of the work they produce. Generally, the
> only measurement of the quality is "does it work?".

I hope you don't really feel this way. I have certainly seen enough of this
type of mindset (lacking forethought or any appreciation of future
consequences for present decisions) in my life. However, there are
individuals, businesses, and companies that do not subscribe to such a
Dilbert-esque business philosophy. Such individuals, businesses and
companies generally seem to survive and prosper over the long haul, as that
is what they plan for.

The truth of the matter is, it takes less money and effort over the long
haul to spend the money and do it right the first time. A LOT less money.
Bad code must be constantly rewritten and hacked to adapt to changing
conditions. Unless it is completely rewritten, the legacy of bad code costs
money for a very long time.

I wouldn't work for another company like that for any salary.

--
HTH,

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

"70Bang!" <70Bang!@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:4AB739B9-BFAE-4134-94CE-E450D9191F00@dotnet.itags.org.microsoft.com...
> "Cowboy (Gregory A. Beamer) - MVP" wrote:
>> There are plenty of clueless C++, VB, et al, developer.
> There's a reason for this:
> "You don't have to be good, just good enough."
> -me, ca. late 80s
> You can also consider things such as "bad coders can write bad code faster
> than good coders can write good code" (or good coders can fix bad code).
> People like to code and like to get paid for something they like to do.
> This
> is without regard to the quality of the work they produce. Generally, the
> only measurement of the quality is "does it work?".
> Code reviews are a rarity. Documents are a thing of even farther in the
> past. Besides, most technical people can't write their way out of a paper
> bag
> so why should they write docs which are worthless? Granted, there are
> people
> who write them professionally, but do smaller shops which only have one,
> two,
> or three technical people on staff have to have a technical writer who
> only
> writes docs? Ever look at the code someone has written for a group they
> belong to? Service group? Church? Charity? There are plenty of good
> people
> who write for such groups but there are plenty who have members who
> willingly
> hop into the pool (and pee in the water) and deliver, at best, something
> someone who took a first year VB course could improve upon.
> Priority #1 is get to the keyboard and bang away at code. Forget specs.
> Forget everything. Keyboard is #1.
> In one of the blogs where everyone is whining about VB6, "Dougie" is
> throwing a fit because the 200'000 lines of code he's written over the
> previous twenty years are going to have to be rewritten because VB6 is
> going
> away. His credentials are he not only knows VB but, "and for your
> information, I can code in C, pascal, delphi as well as vb". I'm guessing
> most of his code is a clusterf%ck and most of it hasn't been partitioned
> into
> various DLLs, out-of-process EXEs, classes, etc. Things which not only
> would
> be easier to manage but migrate as well. I think he'd fit real well with
> a
> co-worker at a contracting firm I worked for who claimed, "There's nothing
> you can do with OOP which you can't do with modules." And said his MBA
> gave
> him the divine wisdom to know such things. The funny thing is we were
> billed
> out at $125 for VB work and he wrote & debugged code by trial-and-error
> (I'm
> not joking about any of this). The boss|owner loved him because he raked
> in
> the dough but anyone who had to follow in his footsteps and either fix or
> add
> to his code either kept a wastebasket handy (to barf) or rewrote the apps
> on
> their own time, lest they have to work with it again. It was about as
> tasty
> as one of the Star Trek animated series when an ESP-capable member of a
> feline race begins to get nauseated because one of the Enterprise crew
> focuses so heavily upon eating vegetation. That's what it felt like to
> work
> with Brent's code.
> I know others are upset but I think Dougie represents a vocal group who
> couldn't buy a clue if you handed them the money; and he's pretty
> representative of the industry as a whole.
> You can find Dougie here to look for yourself:
> http://tinyurl.com/6szrc
> http://blogs.msdn.com/brad_mccabe/a.../10/393704.aspx
>
>> ***************************
>> Think Outside the Box!
>> ***************************
> (This is trite and a poor interpretation of deMarco's "Lateral Thinking" -
> I
> suggest you get one of his books...)
>> "Kevin Spencer" wrote:
>> > 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.
> And before ASP.Net, it was ASP. Employers paid a lot more (and still do)
> for ASP. The problem is a sizeable percentage of the ASP crowd were rats
> jumping off of a sinking ship - all of the static HTMLers realizing their
> pond was shrinking and they'd better jump...fast. Think about
> non-programmers
> writing ASP + client-side JScript. Fortunately, a measure of competency
> became a requirement and started to turn the tide.
>> > 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?
> At the risk of sounding rude, how is this the demise of c#?
It seems to me after reading some of these posts that this is just an
argument over personal preferences. I think its great that .NET offers both
VB.NET and C# and I feel that everyone has their own personal reasons for
picking their language. I have done programming in C++, Java, ASP, VbSCript,
JavaScript, Python, TCL, and others... however when I moved to use .NET i
chose C# simply because it was closer to C++ and Java. I found the syntax of
VB.NET to be too much of a blur of different languages, and I would start to
confuse syntax when working in different environments, as I still support old
VB6 and asp apps.

The idea of writing a line of code that looks like
Dim var as Object = new Object

My syntax may be off there, as you know I use C#... but you get my point.
To me it just made me thing I would start to confuse my syntax for different
languages, so I chose C#.

However I just got a new job, where they only want me to use VB.NET because
the talent pool at the company are all peopole from vb6 with no c++/java
experience.

So I think for every company that requests a c# person, there is a company
that wants a vb.net person... for whatever reason it may be. There are a
lot of companies with talent consisting only of vb.

"cmay" wrote:

> 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...
>
> "Alvin Bruney" wrote:
> > I believe they did. (can of worms here)
> > I really don't see a reason for VB.NET given the fact that it certainly
> > isn't VB with .NET classes. Eventually, VB.NET will have to morph into
> > something else. Programmers who need to learn VB.NET coming from VB classic
> > are better off learning C#.
> > --
> > Regards
> > Alvin Bruney
> > [Shameless Author Plug]
> > The Microsoft Office Web Components Black Book with .NET
> > available at www.lulu.com/owc
> > ----------------
> > "Steve C. Orr [MVP, MCSD]" <Steve@dotnet.itags.org.Orr.net> wrote in message
> > news:OT3v22TGFHA.3928@dotnet.itags.org.TK2MSFTNGP09.phx.gbl...
> > > The main reasons they went with C# is because they were experienced with
> > > C++ (becuase C++ was more powerful than VB6) so it was more of a natural
> > > progression for them, and the other reason was because C# was the "new"
> > > language and they wanted to eat their own dog food to ensure C# would
> > > become capable of all that they'd envisioned and all they needed.
> > > > It wasn't because they saw C# as superior to VB.NET in any way.
> > > > --
> > > I hope this helps,
> > > Steve C. Orr, MCSD, MVP
> > > http://SteveOrr.net
> > > > > "Robbe Morris [C# MVP]" <info@dotnet.itags.org.turnkeytools.com> wrote in message
> > > news:OyR3DzTGFHA.1528@dotnet.itags.org.TK2MSFTNGP09.phx.gbl...
> > >> When I saw that when deciding whether to continue on with VB.NET
> > >> (I was an old VB 6 and a C# coder), I went with C#.
> > >>
> > >> I figured if the Microsoft guys saw fit to use C#, maybe I should too.
> > >> There must be a reason they picked it.
> > >>
> > >> --
> > >> 2005 Microsoft MVP C#
> > >> Robbe Morris
> > >> http://www.robbemorris.com
> > >> http://www.mastervb.net/home/ng/for...st10017013.aspx
> > >> http://www.eggheadcafe.com/articles...e_generator.asp
> > >>
> > >>
> > >>
> > >> "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> > >> news:%23XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
> > >>> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
> > >>> seeing many posts about what language to use with ASP.Net. The consensus
> > >>> was that employers paid more for C# programmers, and it seems that C#
> > >>> became the darling of the ASP.Net crowd.
> > >>>
> > >>> In the meantime, I have observed an interesting phenomenon. Originally,
> > >>> employers hired programmers who used C# because it was based on C, and
> > >>> the prevailing opinion was (and may still be) that C# developers were
> > >>> better because they must have known and/or practiced C or C++ at some
> > >>> time, which would make them better programmers overall. C and C++ are
> > >>> hard-core programming languages compared to VB.
> > >>>
> > >>> However, now that nearly everyone has jumped on the C# bandwagon, it
> > >>> seems to me that the distinction between the languages has nearly
> > >>> disappeared, at least in terms of evaluating programmers for hire. There
> > >>> seem to be almost as many clueless C# developers out there as VB.Net
> > >>> developers. Many C# developers today are basically VB.Net developers
> > >>> using a different syntax. I wonder if the employers have become aware of
> > >>> this trend?
> > >>>
> > >>> --
> > >>>
> > >>> Kevin Spencer
> > >>> Microsoft MVP
> > >>> .Net Developer
> > >>> Neither a follower nor a lender be.
> > >>>
> > >>>
> > >>
> > >>
> >
I have to agree with Steve here, though he probably wouldn't go as far as
me... I have hired many web developers, and have experienced much more
difficulty with 20 year C/C++ programmers who have been doing Internet
development for a few years, than relatively new programmers that just have a
few years experience with ASP/VBscript/VB/COM (and now with .net).

Why? I think it has to do with instinct. Some of the C/C++ developers we
have brought on board had a heck of a time becoming instinctively aware of
"where" their code was executing. ASP.NET has done a great deal to rectify
this by handling client events in the code-behind, but when you have a
programmer that has always developed applications with a single event layer,
and they suddenly have to debug a process like: request goes to the server,
server to biz layer, biz to database, biz to server, server generates
client-side html and script, server generates client-side script written to
generate more client-side script when it executes, buffer is flushed, html
rendered, dom events fire, client script executes, user triggers events,
script submits a hidden form to the server, (insert first 11 items here
again), etc.. I have had to spend an inordinate amount of time breaking down
the layers and explaining "where" different pieces of the code is generated
and where it ends up executing.

On the other hand, programmers who "grew up" on the web with ASP/VBScript
(or even Perl/PHP/etc) as their native language/platform, seem to have a much
better instinct for weaving through the web - for instance, if you have to
debug someone else's code that does something crazy like:

<% = "Hello world" %>
<script>
window.attachEvent('onload',function() {
msgbox('<% = jsEscape(sMessage) %>', msg_onclose);
}

"Kevin Spencer" wrote:

> Oh, I agree, Steve. There are plenty of good VB developers out there (such
> as yourself!).
> I also agree that a solid understanding of HTML, HTTP, and the web are very
> important to ASP.Net (critically important, actually).
> > But my
> > experience tells me you don't need to be from C land to be a solid
> > developer.
> I agree here as well, with one caveat: You don't need to know C to be a
> solid developer, but it sure helps! I could elaborate on why, but again, I'm
> really not interested in a debate about languages!
> > prospective employees shouldn't be evaluated based on assumptions and
> > stereotypes.
> I've always agreed with that point!
> Actually, I wasn't trying to dredge up the old argument about which language
> is "better." I was actually remarking on the trend toward hiring developers
> who know C#, and whether it was valid or not any more.
> My point is NOT that a VB developer is necessarily not as strong as a C#
> developer. However, at one point there was at least some statistical
> evidence that C# developers were more likely to be skilled than VB
> developers, due to their background, hence the trend. You know the old
> adage: The race is not always to the swift, nor the battle to the strong,
> but that's how you bet. I just don't believe that the language is useful any
> more as a general (statistical) measuring stick.
> And I'm wondering what the hiring trend is these days, whether it has
> adjusted with the times. My guess would be "not yet." Corporate types are
> generally slow to catch up.
> --
> HTH,
> Kevin Spencer
> Microsoft MVP
> ..Net Developer
> Neither a follower nor a lender be.
> "Steve C. Orr [MVP, MCSD]" <Steve@dotnet.itags.org.Orr.net> wrote in message
> news:e$HQ6qSGFHA.2932@dotnet.itags.org.TK2MSFTNGP15.phx.gbl...
> > When it comes to ASP.NET development, I'd think VB developers stand the
> > better chance of being more experienced, since classic ASP used VBScript.
> > C++ programmers, while they might be smart people, don't necessarily know
> > anything about web development, so C++ experience wouldn't necessarily
> > impress me when interviewing for a web developer. C++ experience would
> > probably only excite me if I was hiring a developer for creating low level
> > software such drivers.
> > Then again, I've always been more of a VB guy so perhaps I'm biased. But
> > my experience tells me you don't need to be from C land to be a solid
> > developer. That's really little more than a stereotype, and prospective
> > employees shouldn't be evaluated based on assumptions and stereotypes.
> > --
> > That's my two cents,
> > Steve C. Orr, MCSD, MVP
> > http://SteveOrr.net
> > "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> > news:%23XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
> >> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
> >> seeing many posts about what language to use with ASP.Net. The consensus
> >> was that employers paid more for C# programmers, and it seems that C#
> >> became the darling of the ASP.Net crowd.
> >>
> >> In the meantime, I have observed an interesting phenomenon. Originally,
> >> employers hired programmers who used C# because it was based on C, and
> >> the prevailing opinion was (and may still be) that C# developers were
> >> better because they must have known and/or practiced C or C++ at some
> >> time, which would make them better programmers overall. C and C++ are
> >> hard-core programming languages compared to VB.
> >>
> >> However, now that nearly everyone has jumped on the C# bandwagon, it
> >> seems to me that the distinction between the languages has nearly
> >> disappeared, at least in terms of evaluating programmers for hire. There
> >> seem to be almost as many clueless C# developers out there as VB.Net
> >> developers. Many C# developers today are basically VB.Net developers
> >> using a different syntax. I wonder if the employers have become aware of
> >> this trend?
> >>
> >> --
> >>
> >> Kevin Spencer
> >> Microsoft MVP
> >> .Net Developer
> >> Neither a follower nor a lender be.
> >>
> >>
>
About productivity, I did heard from some people writing in VB.NET that
writing in VB.NET is faster, on the other hand, I've heard from people
writing in C# (and I think so myself), that writing C# code is more
error-prone and "developable", of course, if written right (well, only VB.NET
code which is written right, is written fast).

Another thing, I've heard about some plug-in for VS.IDE which negates the
difference in speed of development for C# coders for like 95% and allows for
almost all of that nifty features of VB.NET IDE. Though, I've not used it
myself, so I can't tell anything.

About that type written after variable, or before, I don't think that
matters, whether you write it after or before, if you do it singularily, then
syntaсtic analyzer is okay with it.

Anyways, the topic is turning into "what language is better" again :)

"cmay" wrote:

>
> > 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.
>
> > > 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.
> 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.
>
Well, as Jimi Hendrix once said, you can't believe everything you see and
hear, can you?

--
;-),

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

"Kaerber" <Kaerber@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:E98745E2-E138-4DCF-B706-D93C35C2D2A4@dotnet.itags.org.microsoft.com...
> About productivity, I did heard from some people writing in VB.NET that
> writing in VB.NET is faster, on the other hand, I've heard from people
> writing in C# (and I think so myself), that writing C# code is more
> error-prone and "developable", of course, if written right (well, only
> VB.NET
> code which is written right, is written fast).
> Another thing, I've heard about some plug-in for VS.IDE which negates the
> difference in speed of development for C# coders for like 95% and allows
> for
> almost all of that nifty features of VB.NET IDE. Though, I've not used it
> myself, so I can't tell anything.
> About that type written after variable, or before, I don't think that
> matters, whether you write it after or before, if you do it singularily,
> then
> synta?tic analyzer is okay with it.
> Anyways, the topic is turning into "what language is better" again :)
> "cmay" wrote:
>>
>>
>> > 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.
>>
>>
>>> > > 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.
>>
>> 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.
>>
>
While this maybe true Kevin, I wonder how many of those clueless employers
are converting applications to C# because they think that it runs faster then
VB.Net.

The real problem exists where employers think that just because someone has
a degree that they will be programming genius. I have a friend that has a
masters in computing and he can barely open a word document, but standing
beside me, with my paltry 10 years development experience he would get the
job.

If Microsoft want to educate anyone, it should be the abundant masses of
non-technical so called managers and directors of IT departments, that don't
understand the first thing when it comes to development but merely throw the
first 'catch phrase' that pops into their head that they have read from a
journal at the HR personnel.

They alone are the sole reason why some snot nosed punk fresh out of college
who is willing to except the lowest of wages are getting jobs and they alone
perpetuate the growing band of clueless developers, whilst winging how they
don't see value for money and how their poorly specified projects are
delivered late and full of bugs.

"Kevin Spencer" wrote:

I agree with ALMOST everything you said, except for one thing:

> The real problem exists where employers think that just because someone
> has
> a degree that they will be programming genius.

While I certainly agree that this is a big problem, I can't agree that it is
THE "real" problem. It certainly is one of them!

--
HTH,

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

"Brennon Williams" <Brennon Williams@dotnet.itags.org.discussions.microsoft.com> wrote in
message news:7A812B3A-04B8-4A27-8F33-A6192B046575@dotnet.itags.org.microsoft.com...
> While this maybe true Kevin, I wonder how many of those clueless employers
> are converting applications to C# because they think that it runs faster
> then
> VB.Net.
> The real problem exists where employers think that just because someone
> has
> a degree that they will be programming genius. I have a friend that has a
> masters in computing and he can barely open a word document, but standing
> beside me, with my paltry 10 years development experience he would get the
> job.
> If Microsoft want to educate anyone, it should be the abundant masses of
> non-technical so called managers and directors of IT departments, that don't
> understand the first thing when it comes to development but merely throw
> the
> first 'catch phrase' that pops into their head that they have read from a
> journal at the HR personnel.
> They alone are the sole reason why some snot nosed punk fresh out of
> college
> who is willing to except the lowest of wages are getting jobs and they
> alone
> perpetuate the growing band of clueless developers, whilst winging how
> they
> don't see value for money and how their poorly specified projects are
> delivered late and full of bugs.
>
> "Kevin Spencer" wrote:
>> 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.
>>
>>
>
Leaving aside the fact that not everything is a web application, there are at
least 2 questionable assumptions in this:
1) That all C# developers are recycled C/C++ developers. Some in fact (such
as myself, although I had worked with C and with another c-word language that
I won't mention...and even BCPL) are ex-VB/VB Script/ASP developers (and no,
I don't write VB6 code in C# syntax, although I understand how someone might,
and have cleaned up after someone who has). Some are Java developers that
we've brought over to the Dark Side.
2) That ASP/VB Script is necessarily a good background for ASP.NET.
While *any* web experience is useful (otherwise I spend a lot of time
explaining to even very bright people what happens on the server and what
happens in the browser), do we actually want ASP.NET to be written the way a
lot of people wrote ASP? If I'm shortlisting candidates these days I'll quite
happily give equal weight to ASP *and* JSP experience - I might even favour
the latter slightly.

"Kevin Spencer" wrote:

> 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've been coding for more than 20 years, and doing architecture for
enterprise applications for at least a decade now, as well as keeping my hand
in at coding. I'm fluent in 17 "languages" (from machine code, C, C++ through
to Java, C#, VB.NET and Delphi's .NET implementation, and, yes, even a
smattering of COBOL). I now regularly consult to hire coders for large and
small companies, including government organizations right down to private
entrepreneurs. My own coding (usually just the conceptual structures and hard
bits and pieces these days) is split between VB.NET, C# and Java these days
almost equally. None of this makes me inherently smarter, better, or faster
than a coder with a few years experience right out of school. About all I can
claim is that I have a lot of experience, both good and bad, and maybe a
scrap of wisdom as a result of surviving the long haul. I am not an MVP
(don't have the inclination or the time); have no real preference between MS
languages and Sun languages, etc.; and those who have worked with me describe
me as too relaxed to be a programmer or IT manager.
That purpose of that descriptive preface is simply to place the following
opinion in perspective:
Anyone who hires primarily on the basis of language skills is a fool,
because none of these languages are weak in the hands of a professional.
About the only legitimate reason for using language as a basis of comparison
during a hiring process is if there is an existing code base in a given
language. Then, it is syntax familiarity that comes into play. HR managers
who do hiring on the basis of language are a bane to the industry, and part
of the reason the vast majority of software projects fail so miserably.
As I read the multitude of posts on this topic, I was reminded of a recent
conversation I had with a client who was asking me to help re-fit a
self-destructive team of coders (they were supposed to be rebuilding a fairly
significant enterprise system in .NET that was previously done in a variety
of languages and cobbled together beneath a VB6 GUI). The client felt the
problem was that the three lead programmers (C++ gurus) could not deal with
the "weaker" members of the team, who "could not understand the OOP issues."
A review of the situation and the legacy code-base revealed that what was
actually happening was that the C++ coders (a combined 22 years of experience
under their belts) were drowning in the .NET framework's scale, and having
trouble translating the legacy constructs to it. Two of the recent hires had
ignited a war in the team by claiming the old dogs couldn't learn the new
tricks, and instead of proving them wrong by action, the C++ lads decided to
play the OOP purist card. Two days of intensive communication solved the
problem, made the younger coders realize that they were throwing away an
opportunity, and the seasoned coders realize they were betraying their
responsibility to the younger coders, who were for all intents their
apprentices. Not once in those two days did I even speak of a language,
because language was irrelevant to the solution.
Again, this is simply an opinion, but I would say that when "language" is
believed relevant to the solution, the solution is at risk. Each set of
technologies has its place, and there will always be circumstances that make
one the choice for a given project. At the end of the day, as long as the
language choice is fitting, it is correct.
And on the point of C++ versus C# versus VB.NET: C++ is probably superior in
the sense it is closer to the language of the machine, but it is challenging
to write well, especially in the modern era of two-minute turnaround. In the
modern time frames, neither VB.NET nor C# is the better language, because in
professional hands the results are the same, which is a good solution. What
sets the professional apart from the non-professional in the world of .NET
programming is knowledge of the framework. It is far better to hire on the
basis of that knowledge than of syntax and grammar. When coders are hired for
their awareness, flexibility and enthusiasm, results are better.
Excellent points all, Frank! I couldn't agree more on all aspects of your
message. When I posted the original "spark" to this thread, it was due to an
observation I had made regarding hiring practices and trends. I had made the
same observations privately that you have, and hoped that by sparking some
discussion of it, we might all benefit from the discussion in one way or
another.

--
HTH,

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

"Frank Buchan" <Frank Buchan@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:106E4281-D498-415D-863D-E73F02D59EB3@dotnet.itags.org.microsoft.com...
> I've been coding for more than 20 years, and doing architecture for
> enterprise applications for at least a decade now, as well as keeping my
> hand
> in at coding. I'm fluent in 17 "languages" (from machine code, C, C++
> through
> to Java, C#, VB.NET and Delphi's .NET implementation, and, yes, even a
> smattering of COBOL). I now regularly consult to hire coders for large and
> small companies, including government organizations right down to private
> entrepreneurs. My own coding (usually just the conceptual structures and
> hard
> bits and pieces these days) is split between VB.NET, C# and Java these
> days
> almost equally. None of this makes me inherently smarter, better, or
> faster
> than a coder with a few years experience right out of school. About all I
> can
> claim is that I have a lot of experience, both good and bad, and maybe a
> scrap of wisdom as a result of surviving the long haul. I am not an MVP
> (don't have the inclination or the time); have no real preference between
> MS
> languages and Sun languages, etc.; and those who have worked with me
> describe
> me as too relaxed to be a programmer or IT manager.
> That purpose of that descriptive preface is simply to place the following
> opinion in perspective:
> Anyone who hires primarily on the basis of language skills is a fool,
> because none of these languages are weak in the hands of a professional.
> About the only legitimate reason for using language as a basis of
> comparison
> during a hiring process is if there is an existing code base in a given
> language. Then, it is syntax familiarity that comes into play. HR managers
> who do hiring on the basis of language are a bane to the industry, and
> part
> of the reason the vast majority of software projects fail so miserably.
> As I read the multitude of posts on this topic, I was reminded of a recent
> conversation I had with a client who was asking me to help re-fit a
> self-destructive team of coders (they were supposed to be rebuilding a
> fairly
> significant enterprise system in .NET that was previously done in a
> variety
> of languages and cobbled together beneath a VB6 GUI). The client felt the
> problem was that the three lead programmers (C++ gurus) could not deal
> with
> the "weaker" members of the team, who "could not understand the OOP
> issues."
> A review of the situation and the legacy code-base revealed that what was
> actually happening was that the C++ coders (a combined 22 years of
> experience
> under their belts) were drowning in the .NET framework's scale, and having
> trouble translating the legacy constructs to it. Two of the recent hires
> had
> ignited a war in the team by claiming the old dogs couldn't learn the new
> tricks, and instead of proving them wrong by action, the C++ lads decided
> to
> play the OOP purist card. Two days of intensive communication solved the
> problem, made the younger coders realize that they were throwing away an
> opportunity, and the seasoned coders realize they were betraying their
> responsibility to the younger coders, who were for all intents their
> apprentices. Not once in those two days did I even speak of a language,
> because language was irrelevant to the solution.
> Again, this is simply an opinion, but I would say that when "language" is
> believed relevant to the solution, the solution is at risk. Each set of
> technologies has its place, and there will always be circumstances that
> make
> one the choice for a given project. At the end of the day, as long as the
> language choice is fitting, it is correct.
> And on the point of C++ versus C# versus VB.NET: C++ is probably superior
> in
> the sense it is closer to the language of the machine, but it is
> challenging
> to write well, especially in the modern era of two-minute turnaround. In
> the
> modern time frames, neither VB.NET nor C# is the better language, because
> in
> professional hands the results are the same, which is a good solution.
> What
> sets the professional apart from the non-professional in the world of .NET
> programming is knowledge of the framework. It is far better to hire on the
> basis of that knowledge than of syntax and grammar. When coders are hired
> for
> their awareness, flexibility and enthusiasm, results are better.
This morning brought a distant memory to me. I had a mentor who once observed
that talent was the best reason to hire a person, but the hardest quality to
judge. This reminded me indirectly that everything I know that has been of
value was passed onto me by mentors, and made me wonder if maybe as a group
we have a problem in that we no longer take on the responsibility of
apprentices. Perhaps if we did, we could shape the process for hiring to
reflect the idea of quality and encompass the judgement that extends from
experience.

"Kevin Spencer" wrote:

> Excellent points all, Frank! I couldn't agree more on all aspects of your
> message. When I posted the original "spark" to this thread, it was due to an
> observation I had made regarding hiring practices and trends. I had made the
> same observations privately that you have, and hoped that by sparking some
> discussion of it, we might all benefit from the discussion in one way or
> another.
> --
> HTH,
> Kevin Spencer
> Microsoft MVP
> ..Net Developer
> What You Seek Is What You Get.
> "Frank Buchan" <Frank Buchan@dotnet.itags.org.discussions.microsoft.com> wrote in message
> news:106E4281-D498-415D-863D-E73F02D59EB3@dotnet.itags.org.microsoft.com...
> > I've been coding for more than 20 years, and doing architecture for
> > enterprise applications for at least a decade now, as well as keeping my
> > hand
> > in at coding. I'm fluent in 17 "languages" (from machine code, C, C++
> > through
> > to Java, C#, VB.NET and Delphi's .NET implementation, and, yes, even a
> > smattering of COBOL). I now regularly consult to hire coders for large and
> > small companies, including government organizations right down to private
> > entrepreneurs. My own coding (usually just the conceptual structures and
> > hard
> > bits and pieces these days) is split between VB.NET, C# and Java these
> > days
> > almost equally. None of this makes me inherently smarter, better, or
> > faster
> > than a coder with a few years experience right out of school. About all I
> > can
> > claim is that I have a lot of experience, both good and bad, and maybe a
> > scrap of wisdom as a result of surviving the long haul. I am not an MVP
> > (don't have the inclination or the time); have no real preference between
> > MS
> > languages and Sun languages, etc.; and those who have worked with me
> > describe
> > me as too relaxed to be a programmer or IT manager.
> > That purpose of that descriptive preface is simply to place the following
> > opinion in perspective:
> > Anyone who hires primarily on the basis of language skills is a fool,
> > because none of these languages are weak in the hands of a professional.
> > About the only legitimate reason for using language as a basis of
> > comparison
> > during a hiring process is if there is an existing code base in a given
> > language. Then, it is syntax familiarity that comes into play. HR managers
> > who do hiring on the basis of language are a bane to the industry, and
> > part
> > of the reason the vast majority of software projects fail so miserably.
> > As I read the multitude of posts on this topic, I was reminded of a recent
> > conversation I had with a client who was asking me to help re-fit a
> > self-destructive team of coders (they were supposed to be rebuilding a
> > fairly
> > significant enterprise system in .NET that was previously done in a
> > variety
> > of languages and cobbled together beneath a VB6 GUI). The client felt the
> > problem was that the three lead programmers (C++ gurus) could not deal
> > with
> > the "weaker" members of the team, who "could not understand the OOP
> > issues."
> > A review of the situation and the legacy code-base revealed that what was
> > actually happening was that the C++ coders (a combined 22 years of
> > experience
> > under their belts) were drowning in the .NET framework's scale, and having
> > trouble translating the legacy constructs to it. Two of the recent hires
> > had
> > ignited a war in the team by claiming the old dogs couldn't learn the new
> > tricks, and instead of proving them wrong by action, the C++ lads decided
> > to
> > play the OOP purist card. Two days of intensive communication solved the
> > problem, made the younger coders realize that they were throwing away an
> > opportunity, and the seasoned coders realize they were betraying their
> > responsibility to the younger coders, who were for all intents their
> > apprentices. Not once in those two days did I even speak of a language,
> > because language was irrelevant to the solution.
> > Again, this is simply an opinion, but I would say that when "language" is
> > believed relevant to the solution, the solution is at risk. Each set of
> > technologies has its place, and there will always be circumstances that
> > make
> > one the choice for a given project. At the end of the day, as long as the
> > language choice is fitting, it is correct.
> > And on the point of C++ versus C# versus VB.NET: C++ is probably superior
> > in
> > the sense it is closer to the language of the machine, but it is
> > challenging
> > to write well, especially in the modern era of two-minute turnaround. In
> > the
> > modern time frames, neither VB.NET nor C# is the better language, because
> > in
> > professional hands the results are the same, which is a good solution.
> > What
> > sets the professional apart from the non-professional in the world of .NET
> > programming is knowledge of the framework. It is far better to hire on the
> > basis of that knowledge than of syntax and grammar. When coders are hired
> > for
> > their awareness, flexibility and enthusiasm, results are better.
>
Well, Frank, I consider these newsgroups as a sort of opportunity to do just
that. However, a good team leader should be a personal mentor, absolutely,
as part of his/her job.

--
HTH,

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

"Frank Buchan" <FrankBuchan@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:35212CEF-0BDA-4944-A656-4E2DE1BF0AFD@dotnet.itags.org.microsoft.com...
> This morning brought a distant memory to me. I had a mentor who once
> observed
> that talent was the best reason to hire a person, but the hardest quality
> to
> judge. This reminded me indirectly that everything I know that has been of
> value was passed onto me by mentors, and made me wonder if maybe as a
> group
> we have a problem in that we no longer take on the responsibility of
> apprentices. Perhaps if we did, we could shape the process for hiring to
> reflect the idea of quality and encompass the judgement that extends from
> experience.
> "Kevin Spencer" wrote:
>> Excellent points all, Frank! I couldn't agree more on all aspects of your
>> message. When I posted the original "spark" to this thread, it was due to
>> an
>> observation I had made regarding hiring practices and trends. I had made
>> the
>> same observations privately that you have, and hoped that by sparking
>> some
>> discussion of it, we might all benefit from the discussion in one way or
>> another.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> ..Net Developer
>> What You Seek Is What You Get.
>>
>> "Frank Buchan" <Frank Buchan@dotnet.itags.org.discussions.microsoft.com> wrote in message
>> news:106E4281-D498-415D-863D-E73F02D59EB3@dotnet.itags.org.microsoft.com...
>> > I've been coding for more than 20 years, and doing architecture for
>> > enterprise applications for at least a decade now, as well as keeping
>> > my
>> > hand
>> > in at coding. I'm fluent in 17 "languages" (from machine code, C, C++
>> > through
>> > to Java, C#, VB.NET and Delphi's .NET implementation, and, yes, even a
>> > smattering of COBOL). I now regularly consult to hire coders for large
>> > and
>> > small companies, including government organizations right down to
>> > private
>> > entrepreneurs. My own coding (usually just the conceptual structures
>> > and
>> > hard
>> > bits and pieces these days) is split between VB.NET, C# and Java these
>> > days
>> > almost equally. None of this makes me inherently smarter, better, or
>> > faster
>> > than a coder with a few years experience right out of school. About all
>> > I
>> > can
>> > claim is that I have a lot of experience, both good and bad, and maybe
>> > a
>> > scrap of wisdom as a result of surviving the long haul. I am not an MVP
>> > (don't have the inclination or the time); have no real preference
>> > between
>> > MS
>> > languages and Sun languages, etc.; and those who have worked with me
>> > describe
>> > me as too relaxed to be a programmer or IT manager.
>> > That purpose of that descriptive preface is simply to place the
>> > following
>> > opinion in perspective:
>> > Anyone who hires primarily on the basis of language skills is a fool,
>> > because none of these languages are weak in the hands of a
>> > professional.
>> > About the only legitimate reason for using language as a basis of
>> > comparison
>> > during a hiring process is if there is an existing code base in a given
>> > language. Then, it is syntax familiarity that comes into play. HR
>> > managers
>> > who do hiring on the basis of language are a bane to the industry, and
>> > part
>> > of the reason the vast majority of software projects fail so miserably.
>> > As I read the multitude of posts on this topic, I was reminded of a
>> > recent
>> > conversation I had with a client who was asking me to help re-fit a
>> > self-destructive team of coders (they were supposed to be rebuilding a
>> > fairly
>> > significant enterprise system in .NET that was previously done in a
>> > variety
>> > of languages and cobbled together beneath a VB6 GUI). The client felt
>> > the
>> > problem was that the three lead programmers (C++ gurus) could not deal
>> > with
>> > the "weaker" members of the team, who "could not understand the OOP
>> > issues."
>> > A review of the situation and the legacy code-base revealed that what
>> > was
>> > actually happening was that the C++ coders (a combined 22 years of
>> > experience
>> > under their belts) were drowning in the .NET framework's scale, and
>> > having
>> > trouble translating the legacy constructs to it. Two of the recent
>> > hires
>> > had
>> > ignited a war in the team by claiming the old dogs couldn't learn the
>> > new
>> > tricks, and instead of proving them wrong by action, the C++ lads
>> > decided
>> > to
>> > play the OOP purist card. Two days of intensive communication solved
>> > the
>> > problem, made the younger coders realize that they were throwing away
>> > an
>> > opportunity, and the seasoned coders realize they were betraying their
>> > responsibility to the younger coders, who were for all intents their
>> > apprentices. Not once in those two days did I even speak of a language,
>> > because language was irrelevant to the solution.
>> > Again, this is simply an opinion, but I would say that when "language"
>> > is
>> > believed relevant to the solution, the solution is at risk. Each set of
>> > technologies has its place, and there will always be circumstances that
>> > make
>> > one the choice for a given project. At the end of the day, as long as
>> > the
>> > language choice is fitting, it is correct.
>> > And on the point of C++ versus C# versus VB.NET: C++ is probably
>> > superior
>> > in
>> > the sense it is closer to the language of the machine, but it is
>> > challenging
>> > to write well, especially in the modern era of two-minute turnaround.
>> > In
>> > the
>> > modern time frames, neither VB.NET nor C# is the better language,
>> > because
>> > in
>> > professional hands the results are the same, which is a good solution.
>> > What
>> > sets the professional apart from the non-professional in the world of
>> > .NET
>> > programming is knowledge of the framework. It is far better to hire on
>> > the
>> > basis of that knowledge than of syntax and grammar. When coders are
>> > hired
>> > for
>> > their awareness, flexibility and enthusiasm, results are better.
>>>
>>
>
Such a good thread well done Mr Spencer!

Good tools only help the creative that's all.
The stone maison can make a most wonderfull statue with a hammer and chisel
no need for a jack hammer.
Imagination and creativity are the key regardless of the language he speaks
or the tools we use.

> You can also consider things such as "bad coders can write bad code faster
> than good coders can write good code" (or good coders can fix bad code).
> People like to code and like to get paid for something they like to do. This
> is without regard to the quality of the work they produce. Generally, the
> only measurement of the quality is "does it work?".

"Peter Rilling" wrote:
> I came from a VB development background and moved to C# about five years
> ago.
Hm, is C# that old? I thought the first betas begun on 2001, but I might be
mistaken.

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

Well, I only have ONE experience of having to work with VB6 code at my
company (the project of a previous developer that left the company). It was
pretty horrible.
There was NO sign of Option Explicit, not EVEN one single Dim variable AS
<type> (although there were some Dim variable).
As if this wasn't enough, this person created a public connection, opened it
at the beggining of program's execution, but since he had to close it in a
some parts of the code, he always included the following check:
If cn.State <> 0 Then cn.Close

Well, I tried to make this thing work (as was mentioned before, this is a
very nice sample of what hackery means, since this project needed constant
changes on it's core). After a week, I abandoned it, archived the code to the
backup HDD, and begun developing it from scratch, using C# and MSDE (he used
MSAccess as the DB, and this database was supposed to be accessed by 5-6
users at the same times - evil laughs).

The result is, that using "proper" OOP techniques and modularisation (this
is the term I use for code reusability, componentisation if you prefer), the
code works perfectly, all changes were almost painless, and is more than
easier to understand the code...

I tend to see it as a difference between VB6 and .net, rather than VB6 and
C#. The reason, is that even by using VB.Net, I would have locked myself out
from all the "unproper" features, such as Option Explicit Off, Option Strict
Off etc etc...

My 2 cents...
> I tend to see it as a difference between VB6 and .net, rather than VB6 and
> C#. The reason, is that even by using VB.Net, I would have locked myself
> out
> from all the "unproper" features, such as Option Explicit Off, Option
> Strict
> Off etc etc...

This part I don't understand. By default Option Explicit is turned ON in
VB.Net, and it's a simple matter to turn Option Strict ON as well...

--
HTH,

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

"Dimitris Kavakopoulos" <Dimitris Kavakopoulos@dotnet.itags.org.discussions.microsoft.com>
wrote in message news:1A94E2EF-9B7F-470C-B295-D7C82E2D963E@dotnet.itags.org.microsoft.com...
>
> "Peter Rilling" wrote:
>> I came from a VB development background and moved to C# about five years
>> ago.
> Hm, is C# that old? I thought the first betas begun on 2001, but I might
> be
> mistaken.
>> I do not necessarily think that companies look for C# people because
>> of the tie-in with C++, but rather that C# develops have more of an OOP
>> sense about them. C++ and C# are object oriented languages and therefore
>> those people tend to think in object design. VB used to be thought of a
>> toy
>> and only used for RAD development. There was little emphasis placed on
>> proper coding styles. It was more of a "let's get it done" mentality
>> rather
>> then "let's design something for expandability and maintainability".
>> Keep
>> in mind that until VB.NET was released, the concept of classes was shoddy
>> at
>> best and certainly did not have inheritance or polymorphism, which means
>> that VB was NEVER an object oriented languages.
> Well, I only have ONE experience of having to work with VB6 code at my
> company (the project of a previous developer that left the company). It
> was
> pretty horrible.
> There was NO sign of Option Explicit, not EVEN one single Dim variable AS
> <type> (although there were some Dim variable).
> As if this wasn't enough, this person created a public connection, opened
> it
> at the beggining of program's execution, but since he had to close it in a
> some parts of the code, he always included the following check:
> If cn.State <> 0 Then cn.Close
> Well, I tried to make this thing work (as was mentioned before, this is a
> very nice sample of what hackery means, since this project needed constant
> changes on it's core). After a week, I abandoned it, archived the code to
> the
> backup HDD, and begun developing it from scratch, using C# and MSDE (he
> used
> MSAccess as the DB, and this database was supposed to be accessed by 5-6
> users at the same times - evil laughs).
> The result is, that using "proper" OOP techniques and modularisation (this
> is the term I use for code reusability, componentisation if you prefer),
> the
> code works perfectly, all changes were almost painless, and is more than
> easier to understand the code...
> I tend to see it as a difference between VB6 and .net, rather than VB6 and
> C#. The reason, is that even by using VB.Net, I would have locked myself
> out
> from all the "unproper" features, such as Option Explicit Off, Option
> Strict
> Off etc etc...
> My 2 cents...
You can use unmanaged code and pointers in VB.NET. I've used the dllImport
attribute to make calls to functions in DLLs like User32 and the like, and
there's the AddressOf operator for creating pointers to functions and such...
I think there is something C# can do that VB.NET can't, but I can't remember
what it is. I do know that C# doesn't have ParamArrays while VB.NET does,
but that's just indicitive of the main reason to choose one .NET language
over the other: personal preference.

- Dave

"Kevin Spencer" wrote:

> > There is nothing that you can do in C# that you cannot do in VB.NET.
> I'm afraid that's simply untrue. You can't use unmanaged code in VB,
> pointers, and several other less important items. Yes, it may be a rare
> occasion that you need to, but believe it or not, I've worked on several
> projects over the past year which process very large (200 - 500 MB) images,
> and there's no substitute for pointers in a situation like that. In fact,
> even with the use of pointers, I have one app that takes several hours to
> process a single image.
> --
> HTH,
> Kevin Spencer
> Microsoft MVP
> ..Net Developer
> Neither a follower nor a lender be.
> "Peter Rilling" <peter@dotnet.itags.org.nospam.rilling.net> wrote in message
> news:O6eVNATGFHA.3728@dotnet.itags.org.TK2MSFTNGP14.phx.gbl...
> > Okay, I write this message with the full knowledge that I am going to piss
> > a
> > large number of people off. So I fully expect some flaming to happen.
> > As languages evolve, there becomes less and less that differentiates them.
> > There is nothing that you can do in C# that you cannot do in VB.NET.
> > I came from a VB development background and moved to C# about five years
> > ago. I do not necessarily think that companies look for C# people because
> > of the tie-in with C++, but rather that C# develops have more of an OOP
> > sense about them. C++ and C# are object oriented languages and therefore
> > those people tend to think in object design. VB used to be thought of a
> > toy
> > and only used for RAD development. There was little emphasis placed on
> > proper coding styles. It was more of a "let's get it done" mentality
> > rather
> > then "let's design something for expandability and maintainability". Keep
> > in mind that until VB.NET was released, the concept of classes was shoddy
> > at
> > best and certainly did not have inheritance or polymorphism, which means
> > that VB was NEVER an object oriented languages.
> > Remember that when the GUI first came out it was also thought of as a toy.
> > Why would real computer uses use a graphical interface, was the mantra of
> > my
> > command-line gurus.
> > "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> > news:#XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
> >> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
> >> seeing many posts about what language to use with ASP.Net. The consensus
> > was
> >> that employers paid more for C# programmers, and it seems that C# became
> > the
> >> darling of the ASP.Net crowd.
> >>
> >> In the meantime, I have observed an interesting phenomenon. Originally,
> >> employers hired programmers who used C# because it was based on C, and
> >> the
> >> prevailing opinion was (and may still be) that C# developers were better
> >> because they must have known and/or practiced C or C++ at some time,
> >> which
> >> would make them better programmers overall. C and C++ are hard-core
> >> programming languages compared to VB.
> >>
> >> However, now that nearly everyone has jumped on the C# bandwagon, it
> >> seems
> >> to me that the distinction between the languages has nearly disappeared,
> > at
> >> least in terms of evaluating programmers for hire. There seem to be
> >> almost
> >> as many clueless C# developers out there as VB.Net developers. Many C#
> >> developers today are basically VB.Net developers using a different
> >> syntax.
> > I
> >> wonder if the employers have become aware of this trend?
> >>
> >> --
> >>
> >> Kevin Spencer
> >> Microsoft MVP
> >> .Net Developer
> >> Neither a follower nor a lender be.
> >>
> >>
>
Yes it would seem they have!

"Kevin Spencer" wrote:

--
HTH,

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

"David Davidson" <daviddavidson3@dotnet.itags.org.newsgroup.nospam> wrote in message
news:53E1470A-9787-4E0A-BF3B-FD59E0F814C9@dotnet.itags.org.microsoft.com...
> You can use unmanaged code and pointers in VB.NET. I've used the
> dllImport
> attribute to make calls to functions in DLLs like User32 and the like, and
> there's the AddressOf operator for creating pointers to functions and
> such...
> I think there is something C# can do that VB.NET can't, but I can't
> remember
> what it is. I do know that C# doesn't have ParamArrays while VB.NET does,
> but that's just indicitive of the main reason to choose one .NET language
> over the other: personal preference.
> - Dave
> "Kevin Spencer" wrote:
>> > There is nothing that you can do in C# that you cannot do in VB.NET.
>>
>> I'm afraid that's simply untrue. You can't use unmanaged code in VB,
>> pointers, and several other less important items. Yes, it may be a rare
>> occasion that you need to, but believe it or not, I've worked on several
>> projects over the past year which process very large (200 - 500 MB)
>> images,
>> and there's no substitute for pointers in a situation like that. In fact,
>> even with the use of pointers, I have one app that takes several hours to
>> process a single image.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> ..Net Developer
>> Neither a follower nor a lender be.
>>
>> "Peter Rilling" <peter@dotnet.itags.org.nospam.rilling.net> wrote in message
>> news:O6eVNATGFHA.3728@dotnet.itags.org.TK2MSFTNGP14.phx.gbl...
>> > Okay, I write this message with the full knowledge that I am going to
>> > piss
>> > a
>> > large number of people off. So I fully expect some flaming to happen.
>>> > As languages evolve, there becomes less and less that differentiates
>> > them.
>> > There is nothing that you can do in C# that you cannot do in VB.NET.
>>> > I came from a VB development background and moved to C# about five
>> > years
>> > ago. I do not necessarily think that companies look for C# people
>> > because
>> > of the tie-in with C++, but rather that C# develops have more of an OOP
>> > sense about them. C++ and C# are object oriented languages and
>> > therefore
>> > those people tend to think in object design. VB used to be thought of
>> > a
>> > toy
>> > and only used for RAD development. There was little emphasis placed on
>> > proper coding styles. It was more of a "let's get it done" mentality
>> > rather
>> > then "let's design something for expandability and maintainability".
>> > Keep
>> > in mind that until VB.NET was released, the concept of classes was
>> > shoddy
>> > at
>> > best and certainly did not have inheritance or polymorphism, which
>> > means
>> > that VB was NEVER an object oriented languages.
>>> > Remember that when the GUI first came out it was also thought of as a
>> > toy.
>> > Why would real computer uses use a graphical interface, was the mantra
>> > of
>> > my
>> > command-line gurus.
>>> > "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
>> > news:#XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
>> >> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
>> >> seeing many posts about what language to use with ASP.Net. The
>> >> consensus
>> > was
>> >> that employers paid more for C# programmers, and it seems that C#
>> >> became
>> > the
>> >> darling of the ASP.Net crowd.
>> >>
>> >> In the meantime, I have observed an interesting phenomenon.
>> >> Originally,
>> >> employers hired programmers who used C# because it was based on C, and
>> >> the
>> >> prevailing opinion was (and may still be) that C# developers were
>> >> better
>> >> because they must have known and/or practiced C or C++ at some time,
>> >> which
>> >> would make them better programmers overall. C and C++ are hard-core
>> >> programming languages compared to VB.
>> >>
>> >> However, now that nearly everyone has jumped on the C# bandwagon, it
>> >> seems
>> >> to me that the distinction between the languages has nearly
>> >> disappeared,
>> > at
>> >> least in terms of evaluating programmers for hire. There seem to be
>> >> almost
>> >> as many clueless C# developers out there as VB.Net developers. Many C#
>> >> developers today are basically VB.Net developers using a different
>> >> syntax.
>> > I
>> >> wonder if the employers have become aware of this trend?
>> >>
>> >> --
>> >>
>> >> Kevin Spencer
>> >> Microsoft MVP
>> >> .Net Developer
>> >> Neither a follower nor a lender be.
>> >>
>> >>
>>>>
>>
>
Even in VB6 i was able to emulate using pointers when i had to, you just
have to think a bit harder.

using a byte array as a stream and an index as the pointer with a couple of
funtions to return the position of objects in the stream you can emulate
pointers, although you do end up having to use some non approved
functionality to bypass safe types.

I had to use VB6 although i wanted to use C++. I needed to return some
performance data for message queues from the registry. it was maybe not quite
as fast as pointers but it was pretty close.

"Kevin Spencer" wrote:

> 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.
Well, now, Alan, that's pretty clever. Still, it's the hard way around. I
commend you for your creativity!

--
HTH,

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

"Alan Smith" <Alan Smith@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:2988E7CE-D6D2-431F-9604-12621067D364@dotnet.itags.org.microsoft.com...
> Even in VB6 i was able to emulate using pointers when i had to, you just
> have to think a bit harder.
> using a byte array as a stream and an index as the pointer with a couple
> of
> funtions to return the position of objects in the stream you can emulate
> pointers, although you do end up having to use some non approved
> functionality to bypass safe types.
> I had to use VB6 although i wanted to use C++. I needed to return some
> performance data for message queues from the registry. it was maybe not
> quite
> as fast as pointers but it was pretty close.
> "Kevin Spencer" wrote:
>>
>> 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.
>
Thank you for your commendation.

This does prove Rob's point though that you can use almost any language you
like to do whatever you want without a severe drop in performance.

Each language may have strengths and weaknesses but they can be worked
around and I am sure even your project with the images could be done in
VB.Net without costing an order of magnitude in processing if some thought
was put into it.

I have been using C# almost since its first beta, it was chosen by the dev
team who were mostly all VB6 programmers in a vote, the main reason given was
that they (me included) thought it would look better on CV than VB.Net, I had
done C and C++ City and Guilds when i was trying to become a programmer but
only had practical commercial experience of VB6, the transition was fairly
easy for me but some had problems and didnt fully understand objects properly
even though VB6 does support OOP to a certain extent.

I would reiterate the comment lots of people have made, its the programmer
who makes the difference not the language.

But on my CV I wanted C# as I believed it would look better to employers.

"Kevin Spencer" wrote:

> Well, now, Alan, that's pretty clever. Still, it's the hard way around. I
> commend you for your creativity!
> --
> HTH,
> Kevin Spencer
> Microsoft MVP
> ..Net Developer
> What You Seek Is What You Get.
Well now, Alan, don't push your luck! ;-)

I would prefer not to get into details, but what you described, while
emulating a pointer to a small degree, is far from actually USING pointers.

I will simply reiterate: There are times when unmanaged code is absolutely
necessary. Thankfully, they are not often. Still, I prefer to have that
option when I need it, which is apparently a good bit more often than the
average.

A good mechanic has a machine shop. While a good mechanic would generally
prefer to buy pre-built parts, there is the occasion when the mechanic must
use the machine shop to build a custom part. A not-so-good mechanic has no
machine shop, and has no knowledge of how to use one. Therefore, he has to
pay someone to build his custom parts. And if the custom part doesn't work
as advertised, the not-so-good mechanic can't fix it, and has no recourse
but to replace it with another custom part from some other mechanic.

You think the CLR was written in entirely managed code? Think again. After
all, if unmanaged code was never necessary, Microsoft could have saved a
good bit of money that was spent allowing for it.

--
HTH,

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

"Alan Smith" <AlanSmith@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:1D147ECB-C17B-4979-9E9E-9EB8E7E2131E@dotnet.itags.org.microsoft.com...
> Thank you for your commendation.
> This does prove Rob's point though that you can use almost any language
> you
> like to do whatever you want without a severe drop in performance.
> Each language may have strengths and weaknesses but they can be worked
> around and I am sure even your project with the images could be done in
> VB.Net without costing an order of magnitude in processing if some thought
> was put into it.
> I have been using C# almost since its first beta, it was chosen by the dev
> team who were mostly all VB6 programmers in a vote, the main reason given
> was
> that they (me included) thought it would look better on CV than VB.Net, I
> had
> done C and C++ City and Guilds when i was trying to become a programmer
> but
> only had practical commercial experience of VB6, the transition was fairly
> easy for me but some had problems and didnt fully understand objects
> properly
> even though VB6 does support OOP to a certain extent.
> I would reiterate the comment lots of people have made, its the programmer
> who makes the difference not the language.
> But on my CV I wanted C# as I believed it would look better to employers.
> "Kevin Spencer" wrote:
>> Well, now, Alan, that's pretty clever. Still, it's the hard way around. I
>> commend you for your creativity!
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> ..Net Developer
>> What You Seek Is What You Get.
>
I am a Basic developer turned VB Developer turned VBscript / ASP developer
and now because my company wants a homogeneous code base I have turned C#
developer. I have been developing web sites since before the Web when they
were just text based sites over the ARPanet that ran in browsers such as
Archie and Veronica. To make a long story short now that I am developing in a
true OO environment utilizing a language like C# I will never turn back, not
because it is harder but because it is actually easier in many ways. People
always talk about C and C++ programmers like they are on the top of the food
chain as far as programming. As web developers we have to be proficient in a
number of languages. If we came to work everyday and wrote the same code with
the same syntax hell we'd be really good at it too. As it stands I think
anyone who makes the switch from VB to C# will experience exactly what I am
experiencing. Once over the learning curve it is in my opinion much easier to
code in.

And by the way I was at a VS.Net usergroup meeting sponsored by a local head
hunter last week. There were a number of companies represented all looking
for ASP.net with C# and not one for ASP.net VB. Someone in the crowd asked if
they were seeing any employers asking for VB.net and the answer was an
emphatic no. So wether or not VB is good to bet your career on is up to you,
as for me maybe corporations are a bit misled but it is the common perception
that C# is better than VB and you know what they say, perception is reality.

"Kevin Spencer" wrote:

I am not exactly sure of your meaning with the mechanic analogy, it sounds
as though you mean a good programmer would always use the appropriate
language but the choice of language is not always up to the programmer.

I accept that sometimes unmanaged code is needed, but when performance is
vital surley it would be better to use something like C++ to write the
unmanaged code as it is faster than C#, and if you did then VB.Net or C#
would be able to use the unmanaged code.

"Kevin Spencer" wrote:

> Well now, Alan, don't push your luck! ;-)
> I would prefer not to get into details, but what you described, while
> emulating a pointer to a small degree, is far from actually USING pointers.
> I will simply reiterate: There are times when unmanaged code is absolutely
> necessary. Thankfully, they are not often. Still, I prefer to have that
> option when I need it, which is apparently a good bit more often than the
> average.
> A good mechanic has a machine shop. While a good mechanic would generally
> prefer to buy pre-built parts, there is the occasion when the mechanic must
> use the machine shop to build a custom part. A not-so-good mechanic has no
> machine shop, and has no knowledge of how to use one. Therefore, he has to
> pay someone to build his custom parts. And if the custom part doesn't work
> as advertised, the not-so-good mechanic can't fix it, and has no recourse
> but to replace it with another custom part from some other mechanic.
> You think the CLR was written in entirely managed code? Think again. After
> all, if unmanaged code was never necessary, Microsoft could have saved a
> good bit of money that was spent allowing for it.
> --
> HTH,
> Kevin Spencer
> Microsoft MVP
> ..Net Developer
> What You Seek Is What You Get.
Hey Kevin,
I agree with you for the most part. Most C# programmers I know are .NET
lovers who just use a different syntax than programmers using VB.NET. Few are
better off using C#, except that they're forced to explicitly cast objects
and perform dynamic binding and the sort.

I think that when it comes to design capabilities, the one with C++
experience is going to do better, as someone who appreciates the STL is far
more likely to understand how to develop efficient, robust, flexible code
than someone who thinks the collection classes and the enumeration methods of
the .NET classes are the best thing there is.
On a further note, I know many C# and VB.NET programmers, and many are very
good at getting a small-scale application job done. However, most of these
guys don't know the first thing about efficient design. They don't even
separate the logic processing from the GUI code, and rarely design new
classes or functions that aren't already required by the form designer.
Also, with regard to .NET in general with its various languages, I think the
language variety really isn't the big thing it's hyped up to be, as people
have mentioned here. The languages are practically the same save for some
minor syntactic differences and some variations in what's allowed (implicit
dynamic binding in VB.NET as well as global functions).

To me, I like having both VB.NET and C#. I prefer VB.NET when I'm lazy, and
the globals are nice for small-scale GUI applications as opposed to just
emulating globals through a class with static (shared) members. C# is nicer
for larger scale applications as it has a lot more safety checks in place.

Still, those two should be it. It requires Microsoft to put a lot of extra
effort to create documentation for both VB.NET and C# and Managed C++ and J#.
They should at least cut out the documentation for a couple of these, as they
are all basically the same thing, and the learning curve doesn't vary much
(even with VB.NET, you still have to learn about classes, inheritance,
polymorphism, static binding, dynamic binding, and probably template-like
generics in the upcoming version, as well as all the .NET concepts - it's
really not any easier than C# save for some really minor syntactic
simplicities and slightly looser rules).
I wish I could edit posts, as I keep thinking of new things to say.

With experienced C++ programmers not being as suited for specific .NET tasks
like developing with ASP, I think a lot of that has to do with the fact that
most C++ programmers have a history of working with platform independence. To
become fluent in .NET, you really need to become intimate with the .NET
platform, and a lot of these programmers don't like being restricted to a
single platform, especially when working with such a high-level,
heavily-layered architecture where the underlying system isn't even
recognizable, especially when you consider the rather bulky and limited
design of the .NET framework library.
> I accept that sometimes unmanaged code is needed, but when performance is
> vital surley it would be better to use something like C++ to write the
> unmanaged code as it is faster than C#, and if you did then VB.Net or C#
> would be able to use the unmanaged code.

What I'm referring to is unsafe code blocks, which you don't code in C#. You
write it in C/C++, INSIDE a C# app.
--
HTH,

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

"Alan Smith" <AlanSmith@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:36A4F895-E577-4FD3-8046-CA6B3681CC53@dotnet.itags.org.microsoft.com...
> Hi Kevin,
> I am not exactly sure of your meaning with the mechanic analogy, it sounds
> as though you mean a good programmer would always use the appropriate
> language but the choice of language is not always up to the programmer.
> I accept that sometimes unmanaged code is needed, but when performance is
> vital surley it would be better to use something like C++ to write the
> unmanaged code as it is faster than C#, and if you did then VB.Net or C#
> would be able to use the unmanaged code.
> "Kevin Spencer" wrote:
>> Well now, Alan, don't push your luck! ;-)
>>
>> I would prefer not to get into details, but what you described, while
>> emulating a pointer to a small degree, is far from actually USING
>> pointers.
>>
>> I will simply reiterate: There are times when unmanaged code is
>> absolutely
>> necessary. Thankfully, they are not often. Still, I prefer to have that
>> option when I need it, which is apparently a good bit more often than the
>> average.
>>
>> A good mechanic has a machine shop. While a good mechanic would generally
>> prefer to buy pre-built parts, there is the occasion when the mechanic
>> must
>> use the machine shop to build a custom part. A not-so-good mechanic has
>> no
>> machine shop, and has no knowledge of how to use one. Therefore, he has
>> to
>> pay someone to build his custom parts. And if the custom part doesn't
>> work
>> as advertised, the not-so-good mechanic can't fix it, and has no recourse
>> but to replace it with another custom part from some other mechanic.
>>
>> You think the CLR was written in entirely managed code? Think again.
>> After
>> all, if unmanaged code was never necessary, Microsoft could have saved a
>> good bit of money that was spent allowing for it.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> ..Net Developer
>> What You Seek Is What You Get.
>
> And by the way I was at a VS.Net usergroup meeting sponsored by a local
> head
> hunter last week. There were a number of companies represented all looking
> for ASP.net with C# and not one for ASP.net VB. Someone in the crowd asked
> if
> they were seeing any employers asking for VB.net and the answer was an
> emphatic no.

I think I'd steer clear of THAT group of employers. Sounds like a bunch of
monkey-see-monkee-do Dilberts.

But your point is well-taken!

--
HTH,

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

"Dave McNulty" <DaveMcNulty@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:2DBA96B3-564E-4097-8F6A-BC582110E46C@dotnet.itags.org.microsoft.com...
>I am a Basic developer turned VB Developer turned VBscript / ASP developer
> and now because my company wants a homogeneous code base I have turned C#
> developer. I have been developing web sites since before the Web when they
> were just text based sites over the ARPanet that ran in browsers such as
> Archie and Veronica. To make a long story short now that I am developing
> in a
> true OO environment utilizing a language like C# I will never turn back,
> not
> because it is harder but because it is actually easier in many ways.
> People
> always talk about C and C++ programmers like they are on the top of the
> food
> chain as far as programming. As web developers we have to be proficient in
> a
> number of languages. If we came to work everyday and wrote the same code
> with
> the same syntax hell we'd be really good at it too. As it stands I think
> anyone who makes the switch from VB to C# will experience exactly what I
> am
> experiencing. Once over the learning curve it is in my opinion much easier
> to
> code in.
> And by the way I was at a VS.Net usergroup meeting sponsored by a local
> head
> hunter last week. There were a number of companies represented all looking
> for ASP.net with C# and not one for ASP.net VB. Someone in the crowd asked
> if
> they were seeing any employers asking for VB.net and the answer was an
> emphatic no. So wether or not VB is good to bet your career on is up to
> you,
> as for me maybe corporations are a bit misled but it is the common
> perception
> that C# is better than VB and you know what they say, perception is
> reality.
>
> "Kevin Spencer" wrote:
>> 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 think I'd steer clear of THAT group of employers. Sounds like a bunch of
> monkey-see-monkee-do Dilberts

Kevin, aren't all employers?
This is representative of the Denver IS employment market. I don't think I
have met a management team yet in my 10 + years as a programmer that I
haven't thought were total morons when it comes to technology. Until more
tech types decide to take the management track I think this cravass between
the knowledgeable and the ignorant will only grow. It is unfortunate but it
is the reality.

I think the big picture here is that the .Net runtime is supporting many
languages and hopefully we will see a sparkle again in the eyes of Cobol,
Delphi, VB, and other languages the runtime supports as the powers that be
come to realize that they all have their place.
> Kevin, aren't all employers?

No. For example, mine is certainly not. Which is why I continue to work for
my employer for less salary than I could make elsewhere. I love the type of
work that my company does (mostly R&D for Government SBIRs), and they let me
run my team the way I know I should. We are respected, and truly have the
ear of our employer. Our CEO listens when I give advice, and our CTO is a
geek like us.

I realize that is rare. But it does exist!

If you don't believe that something exists, you will never seek it, and
very likely never find it. Unfortunately, many people don't realize that
"What you seek is what you get" as Uncle Chutney would put it, and tend to
think the whole world is like most of the world.

--
HTH,

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

"Dave McNulty" <DaveMcNulty@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:BB88F778-01AF-488B-B706-848E3A8BF9A2@dotnet.itags.org.microsoft.com...
>I think I'd steer clear of THAT group of employers. Sounds like a bunch of
>> monkey-see-monkee-do Dilberts
> Kevin, aren't all employers?
> This is representative of the Denver IS employment market. I don't think I
> have met a management team yet in my 10 + years as a programmer that I
> haven't thought were total morons when it comes to technology. Until more
> tech types decide to take the management track I think this cravass
> between
> the knowledgeable and the ignorant will only grow. It is unfortunate but
> it
> is the reality.
> I think the big picture here is that the .Net runtime is supporting many
> languages and hopefully we will see a sparkle again in the eyes of Cobol,
> Delphi, VB, and other languages the runtime supports as the powers that be
> come to realize that they all have their place.
Hmmm, having myself been a programmer for more years than I care to admit.
Fashions come and go for what passes as the programming paridigm de jour.

Problem is its going to change so radically in the future, your best off
going back to school again.

Micosoft's Avalon is the new graphics architecture for WIndows. Having used
POV-RAY for eons, I saw many familiar concepts about models, textures etc.
The user interfact uses the idea of a camera looking at something, so code is
going to need to be developed with this in mind.

So when hiring talent, sometimes skills in unrelated areas of research can
quickly become mainstream as the rest of the world catches up.

So when your want to port your product to Longhorn, these VB and C# skills
look kinda useless to me.

Worse, the world is going parallel and most programing languages are
sequential, so back to school.

"Kevin Spencer" wrote:

For instance, take the string concatenation operator from VB, &, which
automatically converts the left and right operands to strings and returns a
combined string. Why is there no equivalent in C#? Sure the '&' character
would conflict with the bitwise and, but there are plenty of other symbols
(ex - Lua's '..') that could be used in place, and it's absolutely silly that
someone has to write:

some_string_output_function("Blah blah: " + x.ToString() + ", " +
y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );

when they could have simply wrote something like:

some_string_output_function("Blah blah: " .. x .. ", " .. y .. " blah blah "
... z .. ", " .. q);

There's nothing implicit going on here; the operator has clearly-defined
behavior. It makes little sense to me why C# does not have things like this
that would do nothing but make the code a little more readable and convenient
to write.

I can understand many of the reasons for C#'s more explicit nature like
requiring explicit casts (safety) and explicitly indicating where you want to
use dynamic binding (performance), but it's silly to deprive a language of
something useful just because it isn't characteristic of the language from
which it was modeled.
> For instance, take the string concatenation operator from VB, &, which
> automatically converts the left and right operands to strings and returns
> a
> combined string. Why is there no equivalent in C#?

The "ToString() part is simply strong data typing. Try turning Option Strict
ON for a change.

--
*sigh*,

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

"John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:DA9BC3C2-D058-46EF-A5BF-3AABD03AA6AC@dotnet.itags.org.microsoft.com...
>I personally think there are some really great things in VB.NET and it's a
> real crime how C# doesn't implement them. If you ask me, VB.NET is a
> better
> language for the rapid-application development needs of most .NET
> developers.
> I still code in C# over VB most of the time, but there are many things I
> envy
> in VB that I find lacking in C#.
> For instance, take the string concatenation operator from VB, &, which
> automatically converts the left and right operands to strings and returns
> a
> combined string. Why is there no equivalent in C#? Sure the '&' character
> would conflict with the bitwise and, but there are plenty of other symbols
> (ex - Lua's '..') that could be used in place, and it's absolutely silly
> that
> someone has to write:
> some_string_output_function("Blah blah: " + x.ToString() + ", " +
> y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );
> when they could have simply wrote something like:
> some_string_output_function("Blah blah: " .. x .. ", " .. y .. " blah blah
> "
> .. z .. ", " .. q);
> There's nothing implicit going on here; the operator has clearly-defined
> behavior. It makes little sense to me why C# does not have things like
> this
> that would do nothing but make the code a little more readable and
> convenient
> to write.
> I can understand many of the reasons for C#'s more explicit nature like
> requiring explicit casts (safety) and explicitly indicating where you want
> to
> use dynamic binding (performance), but it's silly to deprive a language of
> something useful just because it isn't characteristic of the language from
> which it was modeled.
I'm sorry Kevin,

but Option Strict has no bearing on the string concatenation operator in VB,
and the & operator has nothing to do with weak data typing. It is simply a
syntactical convenience that has no implicit effects (it is explicitly
stating that both operands are going to be converted to string as necessary),
and the expression, '123 + 456' in C# is not the same as '123 & 456' in VB.
While I agree with you for the most part about the demise of C#, I found it
pretty odd that you do not understand this distinction.

Any C++ programmer who has a poorer understanding of reusability and generic
design than someone who started on VB or C# should not be calling themselves
C++ programmers, for any moron who even half-understands the STL should know
far more about design patterns than anyone who thinks that the .NET framework
library classes are the epitome of object-oriented design.

- John

"Kevin Spencer" wrote:

> > For instance, take the string concatenation operator from VB, &, which
> > automatically converts the left and right operands to strings and returns
> > a
> > combined string. Why is there no equivalent in C#?
> +
> The "ToString() part is simply strong data typing. Try turning Option Strict
> ON for a change.
> --
> *sigh*,
> Kevin Spencer
> Microsoft MVP
> ..Net Developer
> What You Seek Is What You Get.
> "John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
> news:DA9BC3C2-D058-46EF-A5BF-3AABD03AA6AC@dotnet.itags.org.microsoft.com...
> >I personally think there are some really great things in VB.NET and it's a
> > real crime how C# doesn't implement them. If you ask me, VB.NET is a
> > better
> > language for the rapid-application development needs of most .NET
> > developers.
> > I still code in C# over VB most of the time, but there are many things I
> > envy
> > in VB that I find lacking in C#.
> > For instance, take the string concatenation operator from VB, &, which
> > automatically converts the left and right operands to strings and returns
> > a
> > combined string. Why is there no equivalent in C#? Sure the '&' character
> > would conflict with the bitwise and, but there are plenty of other symbols
> > (ex - Lua's '..') that could be used in place, and it's absolutely silly
> > that
> > someone has to write:
> > some_string_output_function("Blah blah: " + x.ToString() + ", " +
> > y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );
> > when they could have simply wrote something like:
> > some_string_output_function("Blah blah: " .. x .. ", " .. y .. " blah blah
> > "
> > .. z .. ", " .. q);
> > There's nothing implicit going on here; the operator has clearly-defined
> > behavior. It makes little sense to me why C# does not have things like
> > this
> > that would do nothing but make the code a little more readable and
> > convenient
> > to write.
> > I can understand many of the reasons for C#'s more explicit nature like
> > requiring explicit casts (safety) and explicitly indicating where you want
> > to
> > use dynamic binding (performance), but it's silly to deprive a language of
> > something useful just because it isn't characteristic of the language from
> > which it was modeled.
>
Hi Frank,

I agree with many things you've said.

> Anyone who hires primarily on the basis of language skills is a fool,
> because none of these languages are weak in the hands of a professional.

I have to disagree to some extent here. I work in the 3D graphics industry,
and if I were to choose between a moderately skilled C programmer and a
highly skilled Java programmer for writing our package's core renderer, I
would choose the C programmer. Some tools are just better suited for a
specific purpose.

> And on the point of C++ versus C# versus VB.NET: C++ is probably superior in
> the sense it is closer to the language of the machine, but it is challenging
> to write well, especially in the modern era of two-minute turnaround.

I would say that C++ starts out closer to language of the machine. However,
it provides facilities for achieving higher and higher and higher levels of
abstraction that Java and .NET simply cannot provide. In the hands of a truly
skilled C++ programmer, C++ can become a very high level language that,
unlike other high-level languages out there, preserves the power of low-level
languages through its ability to apply solution patterns at compile-time.
While I agree that a skilled programmer should have no problem adapting to a
new language and doing just as well or even better than the programmers
fluent in that language, I would say that the more experienced a programmer
becomes, the more these language differences start becoming significant in
his work.

While primarily a C++ programmer, I've had to work alongside .NET
enthusiasts, and I managed to pick up C# and VB in a few days to the point
where I was showing my co-workers new things about .NET methods of
implementing callback events, using delegates, the significance of sealed
classes, how to implement a thread pool, etc. Not all C++ programmers are
prone to drown in the .NET framework. However, I do agree that the .NET
framework can be a source of grief for C++ programmers. For me, it is because
I find it to be inferior in many places, and I have a hard time implementing
something with techniques I know to be inferior. Take reverse iteration of a
collection in .NET. It doesn't exist using the enumeration constructs
provided. While the typical C# or VB might happily just reverse a container
and then use forward iteration, it's hard for me, a person who has seen
superior libraries, to simply tuck my tail between my legs and write inferior
code. The drive for superiority that many C++ programmers have can be a fault
when compared to the rapid speed at which many of these VB and C# programmers
develop software.

> In the
> modern time frames, neither VB.NET nor C# is the better language, because in
> professional hands the results are the same, which is a good solution. What
> sets the professional apart from the non-professional in the world of .NET
> programming is knowledge of the framework.

I absolutely agree here. That is the only thing that should be important to
an employer looking to hire a programmer writing .NET applications.

- John
Hello John,

I understand generics fine thank you. Generics have their place. But you
missed my point. And I'm not going to waste anyone's time debating it.

And please point out to me where I called myself a C++ programmer. I am
simply a programmer. I can program in a half-dozen languages, one of which
is C++, although I tend to avoid it. C# is an excellent RAD language, and
when I need to go lower than C# I generally go to C. I can also program in
VB.Net, but tend to avoid it because of the requirements of many of my
applications, which require things not available in VB.Net, like pointers.

No need to get personal, eh?

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

"John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:EA0A8BA5-615C-4D7B-B8FA-4E6C0B920B32@dotnet.itags.org.microsoft.com...
> I'm sorry Kevin,
> but Option Strict has no bearing on the string concatenation operator in
> VB,
> and the & operator has nothing to do with weak data typing. It is simply a
> syntactical convenience that has no implicit effects (it is explicitly
> stating that both operands are going to be converted to string as
> necessary),
> and the expression, '123 + 456' in C# is not the same as '123 & 456' in
> VB.
> While I agree with you for the most part about the demise of C#, I found
> it
> pretty odd that you do not understand this distinction.
> Any C++ programmer who has a poorer understanding of reusability and
> generic
> design than someone who started on VB or C# should not be calling
> themselves
> C++ programmers, for any moron who even half-understands the STL should
> know
> far more about design patterns than anyone who thinks that the .NET
> framework
> library classes are the epitome of object-oriented design.
> - John
> "Kevin Spencer" wrote:
>> > For instance, take the string concatenation operator from VB, &, which
>> > automatically converts the left and right operands to strings and
>> > returns
>> > a
>> > combined string. Why is there no equivalent in C#?
>>
>> +
>>
>> The "ToString() part is simply strong data typing. Try turning Option
>> Strict
>> ON for a change.
>>
>> --
>> *sigh*,
>>
>> Kevin Spencer
>> Microsoft MVP
>> ..Net Developer
>> What You Seek Is What You Get.
>>
>> "John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
>> news:DA9BC3C2-D058-46EF-A5BF-3AABD03AA6AC@dotnet.itags.org.microsoft.com...
>> >I personally think there are some really great things in VB.NET and it's
>> >a
>> > real crime how C# doesn't implement them. If you ask me, VB.NET is a
>> > better
>> > language for the rapid-application development needs of most .NET
>> > developers.
>> > I still code in C# over VB most of the time, but there are many things
>> > I
>> > envy
>> > in VB that I find lacking in C#.
>>> > For instance, take the string concatenation operator from VB, &, which
>> > automatically converts the left and right operands to strings and
>> > returns
>> > a
>> > combined string. Why is there no equivalent in C#? Sure the '&'
>> > character
>> > would conflict with the bitwise and, but there are plenty of other
>> > symbols
>> > (ex - Lua's '..') that could be used in place, and it's absolutely
>> > silly
>> > that
>> > someone has to write:
>>> > some_string_output_function("Blah blah: " + x.ToString() + ", " +
>> > y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );
>>> > when they could have simply wrote something like:
>>> > some_string_output_function("Blah blah: " .. x .. ", " .. y .. " blah
>> > blah
>> > "
>> > .. z .. ", " .. q);
>>> > There's nothing implicit going on here; the operator has
>> > clearly-defined
>> > behavior. It makes little sense to me why C# does not have things like
>> > this
>> > that would do nothing but make the code a little more readable and
>> > convenient
>> > to write.
>>> > I can understand many of the reasons for C#'s more explicit nature like
>> > requiring explicit casts (safety) and explicitly indicating where you
>> > want
>> > to
>> > use dynamic binding (performance), but it's silly to deprive a language
>> > of
>> > something useful just because it isn't characteristic of the language
>> > from
>> > which it was modeled.
>>
>>
>
Hi Kevin,

I'm sorry but that second part wasn't directed at you. I was in a hurry and
crammed two messages into one after browsing through the boards - I apologize
about the confusion. The second paragraph was in response to someone writing
about how a .NET developer is more likely to understand object-oriented
design and reusability than a C++ programmer. I would have to disagree, at
least based on my experience. That said, I know plenty of C++ programmers who
shouldn't be calling themselves as such - the kind of C++ programmer that
thinks that templates are only useful for making collections of arbitrary
types, for instance.

As for the first part, syntactic differences aren't going to make or break a
language, but between VB.NET and C#, that's among the most significant
differences between the two. What I would like to see is a hybrid between the
two languages.

There are syntactical conveniences (like the string concatenation operator)
in both languages would be nice to have at once. Global functions may not be
suitable for a large-scale design, but the .NET languages are just as
suitable for rapid application development where globally accessible
functions can be quite suitable. Furthermore, a VB module provides the
ability to declare state variables with private modifiers, and can be
contained within a custom namespace, so as far as I'm concerned, a module is
superior to a class with nothing but static functions, as the members of such
a class cannot be brought into the global namespace.

Operator overloading is another example. It seems like a shame that VB users
must cope without the syntactic convenience simply because operator
overloading isn't 'VB-esque'. Well, neither was inheritance and polymorphism.
Polymorphism to a VB programmer prior to .NET was to use variants.

Syntax and small features like the addition of modules is pretty much all
there is to go by when judging the differences between .NET languages.

- John

"Kevin Spencer" wrote:

> Hello John,
> I understand generics fine thank you. Generics have their place. But you
> missed my point. And I'm not going to waste anyone's time debating it.
> And please point out to me where I called myself a C++ programmer. I am
> simply a programmer. I can program in a half-dozen languages, one of which
> is C++, although I tend to avoid it. C# is an excellent RAD language, and
> when I need to go lower than C# I generally go to C. I can also program in
> VB.Net, but tend to avoid it because of the requirements of many of my
> applications, which require things not available in VB.Net, like pointers.
> No need to get personal, eh?
> --
> Kevin Spencer
> Microsoft MVP
> ..Net Developer
> What You Seek Is What You Get.
>
> "John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
> news:EA0A8BA5-615C-4D7B-B8FA-4E6C0B920B32@dotnet.itags.org.microsoft.com...
> > I'm sorry Kevin,
> > but Option Strict has no bearing on the string concatenation operator in
> > VB,
> > and the & operator has nothing to do with weak data typing. It is simply a
> > syntactical convenience that has no implicit effects (it is explicitly
> > stating that both operands are going to be converted to string as
> > necessary),
> > and the expression, '123 + 456' in C# is not the same as '123 & 456' in
> > VB.
> > While I agree with you for the most part about the demise of C#, I found
> > it
> > pretty odd that you do not understand this distinction.
> > Any C++ programmer who has a poorer understanding of reusability and
> > generic
> > design than someone who started on VB or C# should not be calling
> > themselves
> > C++ programmers, for any moron who even half-understands the STL should
> > know
> > far more about design patterns than anyone who thinks that the .NET
> > framework
> > library classes are the epitome of object-oriented design.
> > - John
> > "Kevin Spencer" wrote:
> >> > For instance, take the string concatenation operator from VB, &, which
> >> > automatically converts the left and right operands to strings and
> >> > returns
> >> > a
> >> > combined string. Why is there no equivalent in C#?
> >>
> >> +
> >>
> >> The "ToString() part is simply strong data typing. Try turning Option
> >> Strict
> >> ON for a change.
> >>
> >> --
> >> *sigh*,
> >>
> >> Kevin Spencer
> >> Microsoft MVP
> >> ..Net Developer
> >> What You Seek Is What You Get.
> >>
> >> "John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
> >> news:DA9BC3C2-D058-46EF-A5BF-3AABD03AA6AC@dotnet.itags.org.microsoft.com...
> >> >I personally think there are some really great things in VB.NET and it's
> >> >a
> >> > real crime how C# doesn't implement them. If you ask me, VB.NET is a
> >> > better
> >> > language for the rapid-application development needs of most .NET
> >> > developers.
> >> > I still code in C# over VB most of the time, but there are many things
> >> > I
> >> > envy
> >> > in VB that I find lacking in C#.
> >> >> > For instance, take the string concatenation operator from VB, &, which
> >> > automatically converts the left and right operands to strings and
> >> > returns
> >> > a
> >> > combined string. Why is there no equivalent in C#? Sure the '&'
> >> > character
> >> > would conflict with the bitwise and, but there are plenty of other
> >> > symbols
> >> > (ex - Lua's '..') that could be used in place, and it's absolutely
> >> > silly
> >> > that
> >> > someone has to write:
> >> >> > some_string_output_function("Blah blah: " + x.ToString() + ", " +
> >> > y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );
> >> >> > when they could have simply wrote something like:
> >> >> > some_string_output_function("Blah blah: " .. x .. ", " .. y .. " blah
> >> > blah
> >> > "
> >> > .. z .. ", " .. q);
> >> >> > There's nothing implicit going on here; the operator has
> >> > clearly-defined
> >> > behavior. It makes little sense to me why C# does not have things like
> >> > this
> >> > that would do nothing but make the code a little more readable and
> >> > convenient
> >> > to write.
> >> >> > I can understand many of the reasons for C#'s more explicit nature like
> >> > requiring explicit casts (safety) and explicitly indicating where you
> >> > want
> >> > to
> >> > use dynamic binding (performance), but it's silly to deprive a language
> >> > of
> >> > something useful just because it isn't characteristic of the language
> >> > from
> >> > which it was modeled.
> >>
> >>
> >>
>
Thanks John.

Microsoft reads these newsgroups, and will respond to feature sets that a
large number of people ask for. So, keep your fingers crossed!

--
HTH,

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

"John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:E0192DFC-8661-4B40-878E-E02985E75D66@dotnet.itags.org.microsoft.com...
> Hi Kevin,
> I'm sorry but that second part wasn't directed at you. I was in a hurry
> and
> crammed two messages into one after browsing through the boards - I
> apologize
> about the confusion. The second paragraph was in response to someone
> writing
> about how a .NET developer is more likely to understand object-oriented
> design and reusability than a C++ programmer. I would have to disagree, at
> least based on my experience. That said, I know plenty of C++ programmers
> who
> shouldn't be calling themselves as such - the kind of C++ programmer that
> thinks that templates are only useful for making collections of arbitrary
> types, for instance.
> As for the first part, syntactic differences aren't going to make or break
> a
> language, but between VB.NET and C#, that's among the most significant
> differences between the two. What I would like to see is a hybrid between
> the
> two languages.
> There are syntactical conveniences (like the string concatenation
> operator)
> in both languages would be nice to have at once. Global functions may not
> be
> suitable for a large-scale design, but the .NET languages are just as
> suitable for rapid application development where globally accessible
> functions can be quite suitable. Furthermore, a VB module provides the
> ability to declare state variables with private modifiers, and can be
> contained within a custom namespace, so as far as I'm concerned, a module
> is
> superior to a class with nothing but static functions, as the members of
> such
> a class cannot be brought into the global namespace.
> Operator overloading is another example. It seems like a shame that VB
> users
> must cope without the syntactic convenience simply because operator
> overloading isn't 'VB-esque'. Well, neither was inheritance and
> polymorphism.
> Polymorphism to a VB programmer prior to .NET was to use variants.
> Syntax and small features like the addition of modules is pretty much all
> there is to go by when judging the differences between .NET languages.
> - John
> "Kevin Spencer" wrote:
>> Hello John,
>>
>> I understand generics fine thank you. Generics have their place. But you
>> missed my point. And I'm not going to waste anyone's time debating it.
>>
>> And please point out to me where I called myself a C++ programmer. I am
>> simply a programmer. I can program in a half-dozen languages, one of
>> which
>> is C++, although I tend to avoid it. C# is an excellent RAD language, and
>> when I need to go lower than C# I generally go to C. I can also program
>> in
>> VB.Net, but tend to avoid it because of the requirements of many of my
>> applications, which require things not available in VB.Net, like
>> pointers.
>>
>> No need to get personal, eh?
>>
>> --
>>
>> Kevin Spencer
>> Microsoft MVP
>> ..Net Developer
>> What You Seek Is What You Get.
>>
>>
>> "John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
>> news:EA0A8BA5-615C-4D7B-B8FA-4E6C0B920B32@dotnet.itags.org.microsoft.com...
>> > I'm sorry Kevin,
>>> > but Option Strict has no bearing on the string concatenation operator
>> > in
>> > VB,
>> > and the & operator has nothing to do with weak data typing. It is
>> > simply a
>> > syntactical convenience that has no implicit effects (it is explicitly
>> > stating that both operands are going to be converted to string as
>> > necessary),
>> > and the expression, '123 + 456' in C# is not the same as '123 & 456' in
>> > VB.
>> > While I agree with you for the most part about the demise of C#, I
>> > found
>> > it
>> > pretty odd that you do not understand this distinction.
>>> > Any C++ programmer who has a poorer understanding of reusability and
>> > generic
>> > design than someone who started on VB or C# should not be calling
>> > themselves
>> > C++ programmers, for any moron who even half-understands the STL should
>> > know
>> > far more about design patterns than anyone who thinks that the .NET
>> > framework
>> > library classes are the epitome of object-oriented design.
>>> > - John
>>> > "Kevin Spencer" wrote:
>>> >> > For instance, take the string concatenation operator from VB, &,
>> >> > which
>> >> > automatically converts the left and right operands to strings and
>> >> > returns
>> >> > a
>> >> > combined string. Why is there no equivalent in C#?
>> >>
>> >> +
>> >>
>> >> The "ToString() part is simply strong data typing. Try turning Option
>> >> Strict
>> >> ON for a change.
>> >>
>> >> --
>> >> *sigh*,
>> >>
>> >> Kevin Spencer
>> >> Microsoft MVP
>> >> ..Net Developer
>> >> What You Seek Is What You Get.
>> >>
>> >> "John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
>> >> news:DA9BC3C2-D058-46EF-A5BF-3AABD03AA6AC@dotnet.itags.org.microsoft.com...
>> >> >I personally think there are some really great things in VB.NET and
>> >> >it's
>> >> >a
>> >> > real crime how C# doesn't implement them. If you ask me, VB.NET is a
>> >> > better
>> >> > language for the rapid-application development needs of most .NET
>> >> > developers.
>> >> > I still code in C# over VB most of the time, but there are many
>> >> > things
>> >> > I
>> >> > envy
>> >> > in VB that I find lacking in C#.
>> >>> >> > For instance, take the string concatenation operator from VB, &,
>> >> > which
>> >> > automatically converts the left and right operands to strings and
>> >> > returns
>> >> > a
>> >> > combined string. Why is there no equivalent in C#? Sure the '&'
>> >> > character
>> >> > would conflict with the bitwise and, but there are plenty of other
>> >> > symbols
>> >> > (ex - Lua's '..') that could be used in place, and it's absolutely
>> >> > silly
>> >> > that
>> >> > someone has to write:
>> >>> >> > some_string_output_function("Blah blah: " + x.ToString() + ", " +
>> >> > y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );
>> >>> >> > when they could have simply wrote something like:
>> >>> >> > some_string_output_function("Blah blah: " .. x .. ", " .. y .. "
>> >> > blah
>> >> > blah
>> >> > "
>> >> > .. z .. ", " .. q);
>> >>> >> > There's nothing implicit going on here; the operator has
>> >> > clearly-defined
>> >> > behavior. It makes little sense to me why C# does not have things
>> >> > like
>> >> > this
>> >> > that would do nothing but make the code a little more readable and
>> >> > convenient
>> >> > to write.
>> >>> >> > I can understand many of the reasons for C#'s more explicit nature
>> >> > like
>> >> > requiring explicit casts (safety) and explicitly indicating where
>> >> > you
>> >> > want
>> >> > to
>> >> > use dynamic binding (performance), but it's silly to deprive a
>> >> > language
>> >> > of
>> >> > something useful just because it isn't characteristic of the
>> >> > language
>> >> > from
>> >> > which it was modeled.
>> >>
>> >>
>> >>
>>
>>
>
Is there *any* way to make this thread demise ?

;-)

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Espaol
Ven, y hablemos de ASP.NET...
======================

"John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
news:E0192DFC-8661-4B40-878E-E02985E75D66@dotnet.itags.org.microsoft.com...
> Hi Kevin,
> I'm sorry but that second part wasn't directed at you. I was in a hurry and
> crammed two messages into one after browsing through the boards - I apologize
> about the confusion. The second paragraph was in response to someone writing
> about how a .NET developer is more likely to understand object-oriented
> design and reusability than a C++ programmer. I would have to disagree, at
> least based on my experience. That said, I know plenty of C++ programmers who
> shouldn't be calling themselves as such - the kind of C++ programmer that
> thinks that templates are only useful for making collections of arbitrary
> types, for instance.
> As for the first part, syntactic differences aren't going to make or break a
> language, but between VB.NET and C#, that's among the most significant
> differences between the two. What I would like to see is a hybrid between the
> two languages.
> There are syntactical conveniences (like the string concatenation operator)
> in both languages would be nice to have at once. Global functions may not be
> suitable for a large-scale design, but the .NET languages are just as
> suitable for rapid application development where globally accessible
> functions can be quite suitable. Furthermore, a VB module provides the
> ability to declare state variables with private modifiers, and can be
> contained within a custom namespace, so as far as I'm concerned, a module is
> superior to a class with nothing but static functions, as the members of such
> a class cannot be brought into the global namespace.
> Operator overloading is another example. It seems like a shame that VB users
> must cope without the syntactic convenience simply because operator
> overloading isn't 'VB-esque'. Well, neither was inheritance and polymorphism.
> Polymorphism to a VB programmer prior to .NET was to use variants.
> Syntax and small features like the addition of modules is pretty much all
> there is to go by when judging the differences between .NET languages.
> - John
> "Kevin Spencer" wrote:
>> Hello John,
>>
>> I understand generics fine thank you. Generics have their place. But you
>> missed my point. And I'm not going to waste anyone's time debating it.
>>
>> And please point out to me where I called myself a C++ programmer. I am
>> simply a programmer. I can program in a half-dozen languages, one of which
>> is C++, although I tend to avoid it. C# is an excellent RAD language, and
>> when I need to go lower than C# I generally go to C. I can also program in
>> VB.Net, but tend to avoid it because of the requirements of many of my
>> applications, which require things not available in VB.Net, like pointers.
>>
>> No need to get personal, eh?
>>
>> --
>>
>> Kevin Spencer
>> Microsoft MVP
>> ..Net Developer
>> What You Seek Is What You Get.
>>
>>
>> "John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
>> news:EA0A8BA5-615C-4D7B-B8FA-4E6C0B920B32@dotnet.itags.org.microsoft.com...
>> > I'm sorry Kevin,
>>> > but Option Strict has no bearing on the string concatenation operator in
>> > VB,
>> > and the & operator has nothing to do with weak data typing. It is simply a
>> > syntactical convenience that has no implicit effects (it is explicitly
>> > stating that both operands are going to be converted to string as
>> > necessary),
>> > and the expression, '123 + 456' in C# is not the same as '123 & 456' in
>> > VB.
>> > While I agree with you for the most part about the demise of C#, I found
>> > it
>> > pretty odd that you do not understand this distinction.
>>> > Any C++ programmer who has a poorer understanding of reusability and
>> > generic
>> > design than someone who started on VB or C# should not be calling
>> > themselves
>> > C++ programmers, for any moron who even half-understands the STL should
>> > know
>> > far more about design patterns than anyone who thinks that the .NET
>> > framework
>> > library classes are the epitome of object-oriented design.
>>> > - John
>>> > "Kevin Spencer" wrote:
>>> >> > For instance, take the string concatenation operator from VB, &, which
>> >> > automatically converts the left and right operands to strings and
>> >> > returns
>> >> > a
>> >> > combined string. Why is there no equivalent in C#?
>> >>
>> >> +
>> >>
>> >> The "ToString() part is simply strong data typing. Try turning Option
>> >> Strict
>> >> ON for a change.
>> >>
>> >> --
>> >> *sigh*,
>> >>
>> >> Kevin Spencer
>> >> Microsoft MVP
>> >> ..Net Developer
>> >> What You Seek Is What You Get.
>> >>
>> >> "John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
>> >> news:DA9BC3C2-D058-46EF-A5BF-3AABD03AA6AC@dotnet.itags.org.microsoft.com...
>> >> >I personally think there are some really great things in VB.NET and it's
>> >> >a
>> >> > real crime how C# doesn't implement them. If you ask me, VB.NET is a
>> >> > better
>> >> > language for the rapid-application development needs of most .NET
>> >> > developers.
>> >> > I still code in C# over VB most of the time, but there are many things
>> >> > I
>> >> > envy
>> >> > in VB that I find lacking in C#.
>> >>> >> > For instance, take the string concatenation operator from VB, &, which
>> >> > automatically converts the left and right operands to strings and
>> >> > returns
>> >> > a
>> >> > combined string. Why is there no equivalent in C#? Sure the '&'
>> >> > character
>> >> > would conflict with the bitwise and, but there are plenty of other
>> >> > symbols
>> >> > (ex - Lua's '..') that could be used in place, and it's absolutely
>> >> > silly
>> >> > that
>> >> > someone has to write:
>> >>> >> > some_string_output_function("Blah blah: " + x.ToString() + ", " +
>> >> > y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );
>> >>> >> > when they could have simply wrote something like:
>> >>> >> > some_string_output_function("Blah blah: " .. x .. ", " .. y .. " blah
>> >> > blah
>> >> > "
>> >> > .. z .. ", " .. q);
>> >>> >> > There's nothing implicit going on here; the operator has
>> >> > clearly-defined
>> >> > behavior. It makes little sense to me why C# does not have things like
>> >> > this
>> >> > that would do nothing but make the code a little more readable and
>> >> > convenient
>> >> > to write.
>> >>> >> > I can understand many of the reasons for C#'s more explicit nature like
>> >> > requiring explicit casts (safety) and explicitly indicating where you
>> >> > want
>> >> > to
>> >> > use dynamic binding (performance), but it's silly to deprive a language
>> >> > of
>> >> > something useful just because it isn't characteristic of the language
>> >> > from
>> >> > which it was modeled.
>> >>
>> >>
>> >>
>>
>>
>
Aw, c'mon, Juan. While some of the replies in this thread have been useless,
I'm happy to note that perhaps it has stimulated some fruitful thought in
many, for the most part. That was the reason I started it. After all, as
Uncle Chutney sez, "Guns don't kill people, and people don't kill people
either. Ideas kill people." And of course, conversely, ideas can save
people! :)

--
HTH,

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

"Juan T. Llibre" <nomailreplies@dotnet.itags.org.nowhere.com> wrote in message
news:u5KPyaaSFHA.1096@dotnet.itags.org.tk2msftngp13.phx.gbl...
> Is there *any* way to make this thread demise ?
> ;-)
>
> Juan T. Llibre
> ASP.NET MVP
> http://asp.net.do/foros/
> Foros de ASP.NET en Espaol
> Ven, y hablemos de ASP.NET...
> ======================
> "John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
> news:E0192DFC-8661-4B40-878E-E02985E75D66@dotnet.itags.org.microsoft.com...
>> Hi Kevin,
>>
>> I'm sorry but that second part wasn't directed at you. I was in a hurry
>> and
>> crammed two messages into one after browsing through the boards - I
>> apologize
>> about the confusion. The second paragraph was in response to someone
>> writing
>> about how a .NET developer is more likely to understand object-oriented
>> design and reusability than a C++ programmer. I would have to disagree,
>> at
>> least based on my experience. That said, I know plenty of C++ programmers
>> who
>> shouldn't be calling themselves as such - the kind of C++ programmer that
>> thinks that templates are only useful for making collections of arbitrary
>> types, for instance.
>>
>> As for the first part, syntactic differences aren't going to make or
>> break a
>> language, but between VB.NET and C#, that's among the most significant
>> differences between the two. What I would like to see is a hybrid between
>> the
>> two languages.
>>
>> There are syntactical conveniences (like the string concatenation
>> operator)
>> in both languages would be nice to have at once. Global functions may not
>> be
>> suitable for a large-scale design, but the .NET languages are just as
>> suitable for rapid application development where globally accessible
>> functions can be quite suitable. Furthermore, a VB module provides the
>> ability to declare state variables with private modifiers, and can be
>> contained within a custom namespace, so as far as I'm concerned, a module
>> is
>> superior to a class with nothing but static functions, as the members of
>> such
>> a class cannot be brought into the global namespace.
>>
>> Operator overloading is another example. It seems like a shame that VB
>> users
>> must cope without the syntactic convenience simply because operator
>> overloading isn't 'VB-esque'. Well, neither was inheritance and
>> polymorphism.
>> Polymorphism to a VB programmer prior to .NET was to use variants.
>>
>> Syntax and small features like the addition of modules is pretty much all
>> there is to go by when judging the differences between .NET languages.
>>
>> - John
>>
>> "Kevin Spencer" wrote:
>>
>>> Hello John,
>>>
>>> I understand generics fine thank you. Generics have their place. But you
>>> missed my point. And I'm not going to waste anyone's time debating it.
>>>
>>> And please point out to me where I called myself a C++ programmer. I am
>>> simply a programmer. I can program in a half-dozen languages, one of
>>> which
>>> is C++, although I tend to avoid it. C# is an excellent RAD language,
>>> and
>>> when I need to go lower than C# I generally go to C. I can also program
>>> in
>>> VB.Net, but tend to avoid it because of the requirements of many of my
>>> applications, which require things not available in VB.Net, like
>>> pointers.
>>>
>>> No need to get personal, eh?
>>>
>>> --
>>>
>>> Kevin Spencer
>>> Microsoft MVP
>>> ..Net Developer
>>> What You Seek Is What You Get.
>>>
>>>
>>> "John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
>>> news:EA0A8BA5-615C-4D7B-B8FA-4E6C0B920B32@dotnet.itags.org.microsoft.com...
>>> > I'm sorry Kevin,
>>>>> > but Option Strict has no bearing on the string concatenation operator
>>> > in
>>> > VB,
>>> > and the & operator has nothing to do with weak data typing. It is
>>> > simply a
>>> > syntactical convenience that has no implicit effects (it is explicitly
>>> > stating that both operands are going to be converted to string as
>>> > necessary),
>>> > and the expression, '123 + 456' in C# is not the same as '123 & 456'
>>> > in
>>> > VB.
>>> > While I agree with you for the most part about the demise of C#, I
>>> > found
>>> > it
>>> > pretty odd that you do not understand this distinction.
>>>>> > Any C++ programmer who has a poorer understanding of reusability and
>>> > generic
>>> > design than someone who started on VB or C# should not be calling
>>> > themselves
>>> > C++ programmers, for any moron who even half-understands the STL
>>> > should
>>> > know
>>> > far more about design patterns than anyone who thinks that the .NET
>>> > framework
>>> > library classes are the epitome of object-oriented design.
>>>>> > - John
>>>>> > "Kevin Spencer" wrote:
>>>>> >> > For instance, take the string concatenation operator from VB, &,
>>> >> > which
>>> >> > automatically converts the left and right operands to strings and
>>> >> > returns
>>> >> > a
>>> >> > combined string. Why is there no equivalent in C#?
>>> >>
>>> >> +
>>> >>
>>> >> The "ToString() part is simply strong data typing. Try turning Option
>>> >> Strict
>>> >> ON for a change.
>>> >>
>>> >> --
>>> >> *sigh*,
>>> >>
>>> >> Kevin Spencer
>>> >> Microsoft MVP
>>> >> ..Net Developer
>>> >> What You Seek Is What You Get.
>>> >>
>>> >> "John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
>>> >> news:DA9BC3C2-D058-46EF-A5BF-3AABD03AA6AC@dotnet.itags.org.microsoft.com...
>>> >> >I personally think there are some really great things in VB.NET and
>>> >> >it's
>>> >> >a
>>> >> > real crime how C# doesn't implement them. If you ask me, VB.NET is
>>> >> > a
>>> >> > better
>>> >> > language for the rapid-application development needs of most .NET
>>> >> > developers.
>>> >> > I still code in C# over VB most of the time, but there are many
>>> >> > things
>>> >> > I
>>> >> > envy
>>> >> > in VB that I find lacking in C#.
>>> >>>> >> > For instance, take the string concatenation operator from VB, &,
>>> >> > which
>>> >> > automatically converts the left and right operands to strings and
>>> >> > returns
>>> >> > a
>>> >> > combined string. Why is there no equivalent in C#? Sure the '&'
>>> >> > character
>>> >> > would conflict with the bitwise and, but there are plenty of other
>>> >> > symbols
>>> >> > (ex - Lua's '..') that could be used in place, and it's absolutely
>>> >> > silly
>>> >> > that
>>> >> > someone has to write:
>>> >>>> >> > some_string_output_function("Blah blah: " + x.ToString() + ", " +
>>> >> > y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );
>>> >>>> >> > when they could have simply wrote something like:
>>> >>>> >> > some_string_output_function("Blah blah: " .. x .. ", " .. y .. "
>>> >> > blah
>>> >> > blah
>>> >> > "
>>> >> > .. z .. ", " .. q);
>>> >>>> >> > There's nothing implicit going on here; the operator has
>>> >> > clearly-defined
>>> >> > behavior. It makes little sense to me why C# does not have things
>>> >> > like
>>> >> > this
>>> >> > that would do nothing but make the code a little more readable and
>>> >> > convenient
>>> >> > to write.
>>> >>>> >> > I can understand many of the reasons for C#'s more explicit nature
>>> >> > like
>>> >> > requiring explicit casts (safety) and explicitly indicating where
>>> >> > you
>>> >> > want
>>> >> > to
>>> >> > use dynamic binding (performance), but it's silly to deprive a
>>> >> > language
>>> >> > of
>>> >> > something useful just because it isn't characteristic of the
>>> >> > language
>>> >> > from
>>> >> > which it was modeled.
>>> >>
>>> >>
>>> >>
>>>
>>>
>>>
That's cool, Kevin.

It's just that it's a very long-running thread... ;-)

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Espaol
Ven, y hablemos de ASP.NET...
======================

"Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
news:uhECevaSFHA.3288@dotnet.itags.org.TK2MSFTNGP14.phx.gbl...
> Aw, c'mon, Juan. While some of the replies in this thread have been useless, I'm happy
> to note that perhaps it has stimulated some fruitful thought in many, for the most part.
> That was the reason I started it. After all, as Uncle Chutney sez, "Guns don't kill
> people, and people don't kill people either. Ideas kill people." And of course,
> conversely, ideas can save people! :)
> --
> HTH,
> Kevin Spencer
> Microsoft MVP
> .Net Developer
> What You Seek Is What You Get.
> "Juan T. Llibre" <nomailreplies@dotnet.itags.org.nowhere.com> wrote in message
> news:u5KPyaaSFHA.1096@dotnet.itags.org.tk2msftngp13.phx.gbl...
>> Is there *any* way to make this thread demise ?
>>
>> ;-)
>>
>>
>>
>> Juan T. Llibre
>> ASP.NET MVP
>> http://asp.net.do/foros/
>> Foros de ASP.NET en Espaol
>> Ven, y hablemos de ASP.NET...
>> ======================
>>
>> "John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
>> news:E0192DFC-8661-4B40-878E-E02985E75D66@dotnet.itags.org.microsoft.com...
>>> Hi Kevin,
>>>
>>> I'm sorry but that second part wasn't directed at you. I was in a hurry and
>>> crammed two messages into one after browsing through the boards - I apologize
>>> about the confusion. The second paragraph was in response to someone writing
>>> about how a .NET developer is more likely to understand object-oriented
>>> design and reusability than a C++ programmer. I would have to disagree, at
>>> least based on my experience. That said, I know plenty of C++ programmers who
>>> shouldn't be calling themselves as such - the kind of C++ programmer that
>>> thinks that templates are only useful for making collections of arbitrary
>>> types, for instance.
>>>
>>> As for the first part, syntactic differences aren't going to make or break a
>>> language, but between VB.NET and C#, that's among the most significant
>>> differences between the two. What I would like to see is a hybrid between the
>>> two languages.
>>>
>>> There are syntactical conveniences (like the string concatenation operator)
>>> in both languages would be nice to have at once. Global functions may not be
>>> suitable for a large-scale design, but the .NET languages are just as
>>> suitable for rapid application development where globally accessible
>>> functions can be quite suitable. Furthermore, a VB module provides the
>>> ability to declare state variables with private modifiers, and can be
>>> contained within a custom namespace, so as far as I'm concerned, a module is
>>> superior to a class with nothing but static functions, as the members of such
>>> a class cannot be brought into the global namespace.
>>>
>>> Operator overloading is another example. It seems like a shame that VB users
>>> must cope without the syntactic convenience simply because operator
>>> overloading isn't 'VB-esque'. Well, neither was inheritance and polymorphism.
>>> Polymorphism to a VB programmer prior to .NET was to use variants.
>>>
>>> Syntax and small features like the addition of modules is pretty much all
>>> there is to go by when judging the differences between .NET languages.
>>>
>>> - John
>>>
>>> "Kevin Spencer" wrote:
>>>
>>>> Hello John,
>>>>
>>>> I understand generics fine thank you. Generics have their place. But you
>>>> missed my point. And I'm not going to waste anyone's time debating it.
>>>>
>>>> And please point out to me where I called myself a C++ programmer. I am
>>>> simply a programmer. I can program in a half-dozen languages, one of which
>>>> is C++, although I tend to avoid it. C# is an excellent RAD language, and
>>>> when I need to go lower than C# I generally go to C. I can also program in
>>>> VB.Net, but tend to avoid it because of the requirements of many of my
>>>> applications, which require things not available in VB.Net, like pointers.
>>>>
>>>> No need to get personal, eh?
>>>>
>>>> --
>>>>
>>>> Kevin Spencer
>>>> Microsoft MVP
>>>> ..Net Developer
>>>> What You Seek Is What You Get.
>>>>
>>>>
>>>> "John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
>>>> news:EA0A8BA5-615C-4D7B-B8FA-4E6C0B920B32@dotnet.itags.org.microsoft.com...
>>>> > I'm sorry Kevin,
>>>>>>> > but Option Strict has no bearing on the string concatenation operator in
>>>> > VB,
>>>> > and the & operator has nothing to do with weak data typing. It is simply a
>>>> > syntactical convenience that has no implicit effects (it is explicitly
>>>> > stating that both operands are going to be converted to string as
>>>> > necessary),
>>>> > and the expression, '123 + 456' in C# is not the same as '123 & 456' in
>>>> > VB.
>>>> > While I agree with you for the most part about the demise of C#, I found
>>>> > it
>>>> > pretty odd that you do not understand this distinction.
>>>>>>> > Any C++ programmer who has a poorer understanding of reusability and
>>>> > generic
>>>> > design than someone who started on VB or C# should not be calling
>>>> > themselves
>>>> > C++ programmers, for any moron who even half-understands the STL should
>>>> > know
>>>> > far more about design patterns than anyone who thinks that the .NET
>>>> > framework
>>>> > library classes are the epitome of object-oriented design.
>>>>>>> > - John
>>>>>>> > "Kevin Spencer" wrote:
>>>>>>> >> > For instance, take the string concatenation operator from VB, &, which
>>>> >> > automatically converts the left and right operands to strings and
>>>> >> > returns
>>>> >> > a
>>>> >> > combined string. Why is there no equivalent in C#?
>>>> >>
>>>> >> +
>>>> >>
>>>> >> The "ToString() part is simply strong data typing. Try turning Option
>>>> >> Strict
>>>> >> ON for a change.
>>>> >>
>>>> >> --
>>>> >> *sigh*,
>>>> >>
>>>> >> Kevin Spencer
>>>> >> Microsoft MVP
>>>> >> ..Net Developer
>>>> >> What You Seek Is What You Get.
>>>> >>
>>>> >> "John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
>>>> >> news:DA9BC3C2-D058-46EF-A5BF-3AABD03AA6AC@dotnet.itags.org.microsoft.com...
>>>> >> >I personally think there are some really great things in VB.NET and it's
>>>> >> >a
>>>> >> > real crime how C# doesn't implement them. If you ask me, VB.NET is a
>>>> >> > better
>>>> >> > language for the rapid-application development needs of most .NET
>>>> >> > developers.
>>>> >> > I still code in C# over VB most of the time, but there are many things
>>>> >> > I
>>>> >> > envy
>>>> >> > in VB that I find lacking in C#.
>>>> >>>>> >> > For instance, take the string concatenation operator from VB, &, which
>>>> >> > automatically converts the left and right operands to strings and
>>>> >> > returns
>>>> >> > a
>>>> >> > combined string. Why is there no equivalent in C#? Sure the '&'
>>>> >> > character
>>>> >> > would conflict with the bitwise and, but there are plenty of other
>>>> >> > symbols
>>>> >> > (ex - Lua's '..') that could be used in place, and it's absolutely
>>>> >> > silly
>>>> >> > that
>>>> >> > someone has to write:
>>>> >>>>> >> > some_string_output_function("Blah blah: " + x.ToString() + ", " +
>>>> >> > y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );
>>>> >>>>> >> > when they could have simply wrote something like:
>>>> >>>>> >> > some_string_output_function("Blah blah: " .. x .. ", " .. y .. " blah
>>>> >> > blah
>>>> >> > "
>>>> >> > .. z .. ", " .. q);
>>>> >>>>> >> > There's nothing implicit going on here; the operator has
>>>> >> > clearly-defined
>>>> >> > behavior. It makes little sense to me why C# does not have things like
>>>> >> > this
>>>> >> > that would do nothing but make the code a little more readable and
>>>> >> > convenient
>>>> >> > to write.
>>>> >>>>> >> > I can understand many of the reasons for C#'s more explicit nature like
>>>> >> > requiring explicit casts (safety) and explicitly indicating where you
>>>> >> > want
>>>> >> > to
>>>> >> > use dynamic binding (performance), but it's silly to deprive a language
>>>> >> > of
>>>> >> > something useful just because it isn't characteristic of the language
>>>> >> > from
>>>> >> > which it was modeled.
>>>> >>
>>>> >>
>>>> >>
>>>>
>>>>
>>>>
>>
>>
I'm sorry John, but I'd have to say Kevin is right. Option Strict does have
an effect on string concatenation in VB.

If Option Strict is off, and you write a line like this: '123 + 456' the IL
will be different than if Option Strict is on because of the type checking
IL code that must be generated.
However, the & operator always works on strings so no type checking is
needed and the IL is more efficient.
If Option Strict is turned on, they both generate the same IL because no
runtime type checking is needed.
It's all about how the compiler sees the code.

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

By the string concatentation operator, I was talking about '&', not '+', for
which Option Strict has no bearing on (not to mention that Option Strict is a
VB feature, which completely seems irrelevant to my point about having C#
include a real string concatenation operator - no I don't mean having '+'
allow implicit lexical conversions happening in the background). As I've
said, '123 & 456' is completely different from '123 + 456'. My point was that
there are syntactical conveniences such as this in VB.NET that would be
useful in C# and vice versa. A string concatentation operator would be useful
in C# (naturally you'd have to pick something other than '&' to avoid
conflicts with the bitwise and operator). A power operator would be useful in
C#. Operator overloading would be useful in VB. Modules would be useful in
C#. Increment/decrement operators would be useful in VB. Why did they include
+= and -= but not ++ and --? Seems odd.

Anyway, these are small things, but they're really the only significant
types of features that separate VB from C# in terms of language features.
While primarily a C# programmer, I do admire some of the language features in
VB, though when I move to VB, I end up missing some of the features in C#. I
could go on some more about the differences between the form designer code
and its synchronization with the IDE and the way you implement events and so
forth which are another thing worth looking at, but that's probably best
saved for another thread.

- John

"Steve C. Orr [MVP, MCSD]" wrote:

> I'm sorry John, but I'd have to say Kevin is right. Option Strict does have
> an effect on string concatenation in VB.
> If Option Strict is off, and you write a line like this: '123 + 456' the IL
> will be different than if Option Strict is on because of the type checking
> IL code that must be generated.
> However, the & operator always works on strings so no type checking is
> needed and the IL is more efficient.
> If Option Strict is turned on, they both generate the same IL because no
> runtime type checking is needed.
> It's all about how the compiler sees the code.
> --
> I hope this helps,
> Steve C. Orr, MCSD, MVP
> http://SteveOrr.net
>
> "John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
> news:EA0A8BA5-615C-4D7B-B8FA-4E6C0B920B32@dotnet.itags.org.microsoft.com...
> > I'm sorry Kevin,
> > but Option Strict has no bearing on the string concatenation operator in
> > VB,
> > and the & operator has nothing to do with weak data typing. It is simply a
> > syntactical convenience that has no implicit effects (it is explicitly
> > stating that both operands are going to be converted to string as
> > necessary),
> > and the expression, '123 + 456' in C# is not the same as '123 & 456' in
> > VB.
> > While I agree with you for the most part about the demise of C#, I found
> > it
> > pretty odd that you do not understand this distinction.
> > Any C++ programmer who has a poorer understanding of reusability and
> > generic
> > design than someone who started on VB or C# should not be calling
> > themselves
> > C++ programmers, for any moron who even half-understands the STL should
> > know
> > far more about design patterns than anyone who thinks that the .NET
> > framework
> > library classes are the epitome of object-oriented design.
> > - John
> > "Kevin Spencer" wrote:
> >> > For instance, take the string concatenation operator from VB, &, which
> >> > automatically converts the left and right operands to strings and
> >> > returns
> >> > a
> >> > combined string. Why is there no equivalent in C#?
> >>
> >> +
> >>
> >> The "ToString() part is simply strong data typing. Try turning Option
> >> Strict
> >> ON for a change.
> >>
> >> --
> >> *sigh*,
> >>
> >> Kevin Spencer
> >> Microsoft MVP
> >> ..Net Developer
> >> What You Seek Is What You Get.
> >>
> >> "John" <John@dotnet.itags.org.discussions.microsoft.com> wrote in message
> >> news:DA9BC3C2-D058-46EF-A5BF-3AABD03AA6AC@dotnet.itags.org.microsoft.com...
> >> >I personally think there are some really great things in VB.NET and it's
> >> >a
> >> > real crime how C# doesn't implement them. If you ask me, VB.NET is a
> >> > better
> >> > language for the rapid-application development needs of most .NET
> >> > developers.
> >> > I still code in C# over VB most of the time, but there are many things
> >> > I
> >> > envy
> >> > in VB that I find lacking in C#.
> >> >> > For instance, take the string concatenation operator from VB, &, which
> >> > automatically converts the left and right operands to strings and
> >> > returns
> >> > a
> >> > combined string. Why is there no equivalent in C#? Sure the '&'
> >> > character
> >> > would conflict with the bitwise and, but there are plenty of other
> >> > symbols
> >> > (ex - Lua's '..') that could be used in place, and it's absolutely
> >> > silly
> >> > that
> >> > someone has to write:
> >> >> > some_string_output_function("Blah blah: " + x.ToString() + ", " +
> >> > y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );
> >> >> > when they could have simply wrote something like:
> >> >> > some_string_output_function("Blah blah: " .. x .. ", " .. y .. " blah
> >> > blah
> >> > "
> >> > .. z .. ", " .. q);
> >> >> > There's nothing implicit going on here; the operator has
> >> > clearly-defined
> >> > behavior. It makes little sense to me why C# does not have things like
> >> > this
> >> > that would do nothing but make the code a little more readable and
> >> > convenient
> >> > to write.
> >> >> > I can understand many of the reasons for C#'s more explicit nature like
> >> > requiring explicit casts (safety) and explicitly indicating where you
> >> > want
> >> > to
> >> > use dynamic binding (performance), but it's silly to deprive a language
> >> > of
> >> > something useful just because it isn't characteristic of the language
> >> > from
> >> > which it was modeled.
> >>
> >>
> >>
>
What about VarPtr, VarPtrArray, StrPtr, and ObjPtr? Won't they still work in
VB.Net?

- Dave

"Kevin Spencer" wrote:

> The AddressOf operator is not for creating pointers. It is for creating
> procedure delegates. You can't use pointers in .Net without unsafe code.
> VB.Net does not allow unsafe code.
> --
> HTH,
> Kevin Spencer
> Microsoft MVP
> ..Net Developer
> What You Seek Is What You Get.
> "David Davidson" <daviddavidson3@dotnet.itags.org.newsgroup.nospam> wrote in message
> news:53E1470A-9787-4E0A-BF3B-FD59E0F814C9@dotnet.itags.org.microsoft.com...
> > You can use unmanaged code and pointers in VB.NET. I've used the
> > dllImport
> > attribute to make calls to functions in DLLs like User32 and the like, and
> > there's the AddressOf operator for creating pointers to functions and
> > such...
> > I think there is something C# can do that VB.NET can't, but I can't
> > remember
> > what it is. I do know that C# doesn't have ParamArrays while VB.NET does,
> > but that's just indicitive of the main reason to choose one .NET language
> > over the other: personal preference.
> > - Dave
> > "Kevin Spencer" wrote:
> >> > There is nothing that you can do in C# that you cannot do in VB.NET.
> >>
> >> I'm afraid that's simply untrue. You can't use unmanaged code in VB,
> >> pointers, and several other less important items. Yes, it may be a rare
> >> occasion that you need to, but believe it or not, I've worked on several
> >> projects over the past year which process very large (200 - 500 MB)
> >> images,
> >> and there's no substitute for pointers in a situation like that. In fact,
> >> even with the use of pointers, I have one app that takes several hours to
> >> process a single image.
> >>
> >> --
> >> HTH,
> >>
> >> Kevin Spencer
> >> Microsoft MVP
> >> ..Net Developer
> >> Neither a follower nor a lender be.
> >>
> >> "Peter Rilling" <peter@dotnet.itags.org.nospam.rilling.net> wrote in message
> >> news:O6eVNATGFHA.3728@dotnet.itags.org.TK2MSFTNGP14.phx.gbl...
> >> > Okay, I write this message with the full knowledge that I am going to
> >> > piss
> >> > a
> >> > large number of people off. So I fully expect some flaming to happen.
> >> >> > As languages evolve, there becomes less and less that differentiates
> >> > them.
> >> > There is nothing that you can do in C# that you cannot do in VB.NET.
> >> >> > I came from a VB development background and moved to C# about five
> >> > years
> >> > ago. I do not necessarily think that companies look for C# people
> >> > because
> >> > of the tie-in with C++, but rather that C# develops have more of an OOP
> >> > sense about them. C++ and C# are object oriented languages and
> >> > therefore
> >> > those people tend to think in object design. VB used to be thought of
> >> > a
> >> > toy
> >> > and only used for RAD development. There was little emphasis placed on
> >> > proper coding styles. It was more of a "let's get it done" mentality
> >> > rather
> >> > then "let's design something for expandability and maintainability".
> >> > Keep
> >> > in mind that until VB.NET was released, the concept of classes was
> >> > shoddy
> >> > at
> >> > best and certainly did not have inheritance or polymorphism, which
> >> > means
> >> > that VB was NEVER an object oriented languages.
> >> >> > Remember that when the GUI first came out it was also thought of as a
> >> > toy.
> >> > Why would real computer uses use a graphical interface, was the mantra
> >> > of
> >> > my
> >> > command-line gurus.
> >> >> > "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
> >> > news:#XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
> >> >> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
> >> >> seeing many posts about what language to use with ASP.Net. The
> >> >> consensus
> >> > was
> >> >> that employers paid more for C# programmers, and it seems that C#
> >> >> became
> >> > the
> >> >> darling of the ASP.Net crowd.
> >> >>
> >> >> In the meantime, I have observed an interesting phenomenon.
> >> >> Originally,
> >> >> employers hired programmers who used C# because it was based on C, and
> >> >> the
> >> >> prevailing opinion was (and may still be) that C# developers were
> >> >> better
> >> >> because they must have known and/or practiced C or C++ at some time,
> >> >> which
> >> >> would make them better programmers overall. C and C++ are hard-core
> >> >> programming languages compared to VB.
> >> >>
> >> >> However, now that nearly everyone has jumped on the C# bandwagon, it
> >> >> seems
> >> >> to me that the distinction between the languages has nearly
> >> >> disappeared,
> >> > at
> >> >> least in terms of evaluating programmers for hire. There seem to be
> >> >> almost
> >> >> as many clueless C# developers out there as VB.Net developers. Many C#
> >> >> developers today are basically VB.Net developers using a different
> >> >> syntax.
> >> > I
> >> >> wonder if the employers have become aware of this trend?
> >> >>
> >> >> --
> >> >>
> >> >> Kevin Spencer
> >> >> Microsoft MVP
> >> >> .Net Developer
> >> >> Neither a follower nor a lender be.
> >> >>
> >> >>
> >> >> >>
> >>
> >>
>
Those are not available in VB.Net. The closest you can get to a pointer in
VB.Net is a delegate.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Paranoia is just a state of mind.

"David Davidson" <daviddavidson3@dotnet.itags.org.newsgroup.nospam> wrote in message
news:1652FE2D-52DE-4A2C-9CFF-D2F3C74FC379@dotnet.itags.org.microsoft.com...
> What about VarPtr, VarPtrArray, StrPtr, and ObjPtr? Won't they still work
> in
> VB.Net?
> - Dave
> "Kevin Spencer" wrote:
>> The AddressOf operator is not for creating pointers. It is for creating
>> procedure delegates. You can't use pointers in .Net without unsafe code.
>> VB.Net does not allow unsafe code.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> ..Net Developer
>> What You Seek Is What You Get.
>>
>> "David Davidson" <daviddavidson3@dotnet.itags.org.newsgroup.nospam> wrote in message
>> news:53E1470A-9787-4E0A-BF3B-FD59E0F814C9@dotnet.itags.org.microsoft.com...
>> > You can use unmanaged code and pointers in VB.NET. I've used the
>> > dllImport
>> > attribute to make calls to functions in DLLs like User32 and the like,
>> > and
>> > there's the AddressOf operator for creating pointers to functions and
>> > such...
>> > I think there is something C# can do that VB.NET can't, but I can't
>> > remember
>> > what it is. I do know that C# doesn't have ParamArrays while VB.NET
>> > does,
>> > but that's just indicitive of the main reason to choose one .NET
>> > language
>> > over the other: personal preference.
>>> > - Dave
>>> > "Kevin Spencer" wrote:
>>> >> > There is nothing that you can do in C# that you cannot do in VB.NET.
>> >>
>> >> I'm afraid that's simply untrue. You can't use unmanaged code in VB,
>> >> pointers, and several other less important items. Yes, it may be a
>> >> rare
>> >> occasion that you need to, but believe it or not, I've worked on
>> >> several
>> >> projects over the past year which process very large (200 - 500 MB)
>> >> images,
>> >> and there's no substitute for pointers in a situation like that. In
>> >> fact,
>> >> even with the use of pointers, I have one app that takes several hours
>> >> to
>> >> process a single image.
>> >>
>> >> --
>> >> HTH,
>> >>
>> >> Kevin Spencer
>> >> Microsoft MVP
>> >> ..Net Developer
>> >> Neither a follower nor a lender be.
>> >>
>> >> "Peter Rilling" <peter@dotnet.itags.org.nospam.rilling.net> wrote in message
>> >> news:O6eVNATGFHA.3728@dotnet.itags.org.TK2MSFTNGP14.phx.gbl...
>> >> > Okay, I write this message with the full knowledge that I am going
>> >> > to
>> >> > piss
>> >> > a
>> >> > large number of people off. So I fully expect some flaming to
>> >> > happen.
>> >>> >> > As languages evolve, there becomes less and less that differentiates
>> >> > them.
>> >> > There is nothing that you can do in C# that you cannot do in VB.NET.
>> >>> >> > I came from a VB development background and moved to C# about five
>> >> > years
>> >> > ago. I do not necessarily think that companies look for C# people
>> >> > because
>> >> > of the tie-in with C++, but rather that C# develops have more of an
>> >> > OOP
>> >> > sense about them. C++ and C# are object oriented languages and
>> >> > therefore
>> >> > those people tend to think in object design. VB used to be thought
>> >> > of
>> >> > a
>> >> > toy
>> >> > and only used for RAD development. There was little emphasis placed
>> >> > on
>> >> > proper coding styles. It was more of a "let's get it done"
>> >> > mentality
>> >> > rather
>> >> > then "let's design something for expandability and maintainability".
>> >> > Keep
>> >> > in mind that until VB.NET was released, the concept of classes was
>> >> > shoddy
>> >> > at
>> >> > best and certainly did not have inheritance or polymorphism, which
>> >> > means
>> >> > that VB was NEVER an object oriented languages.
>> >>> >> > Remember that when the GUI first came out it was also thought of as
>> >> > a
>> >> > toy.
>> >> > Why would real computer uses use a graphical interface, was the
>> >> > mantra
>> >> > of
>> >> > my
>> >> > command-line gurus.
>> >>> >> > "Kevin Spencer" <kevin@dotnet.itags.org.DIESPAMMERSDIEtakempis.com> wrote in message
>> >> > news:#XnYteSGFHA.2876@dotnet.itags.org.TK2MSFTNGP12.phx.gbl...
>> >> >> About 2 years ago, and as recently as perhaps 1 year ago, I can
>> >> >> recall
>> >> >> seeing many posts about what language to use with ASP.Net. The
>> >> >> consensus
>> >> > was
>> >> >> that employers paid more for C# programmers, and it seems that C#
>> >> >> became
>> >> > the
>> >> >> darling of the ASP.Net crowd.
>> >> >>
>> >> >> In the meantime, I have observed an interesting phenomenon.
>> >> >> Originally,
>> >> >> employers hired programmers who used C# because it was based on C,
>> >> >> and
>> >> >> the
>> >> >> prevailing opinion was (and may still be) that C# developers were
>> >> >> better
>> >> >> because they must have known and/or practiced C or C++ at some
>> >> >> time,
>> >> >> which
>> >> >> would make them better programmers overall. C and C++ are hard-core
>> >> >> programming languages compared to VB.
>> >> >>
>> >> >> However, now that nearly everyone has jumped on the C# bandwagon,
>> >> >> it
>> >> >> seems
>> >> >> to me that the distinction between the languages has nearly
>> >> >> disappeared,
>> >> > at
>> >> >> least in terms of evaluating programmers for hire. There seem to be
>> >> >> almost
>> >> >> as many clueless C# developers out there as VB.Net developers. Many
>> >> >> C#
>> >> >> developers today are basically VB.Net developers using a different
>> >> >> syntax.
>> >> > I
>> >> >> wonder if the employers have become aware of this trend?
>> >> >>
>> >> >> --
>> >> >>
>> >> >> Kevin Spencer
>> >> >> Microsoft MVP
>> >> >> .Net Developer
>> >> >> Neither a follower nor a lender be.
>> >> >>
>> >> >>
>> >>> >>> >>
>> >>
>> >>
>>
>>
>
I have to amend my remarks: There are several other ways to obtain
"pointers" in VB.Net, but again, you don't get the raw functionality of a
true pointer using any of them. The most common is the IntPtr, and there are
also some undocumented versions of a couple of the types you mentioned. You
can read about them here:

http://www.codeproject.com/vb/net/Marshal.asp

Again, though, I would stress that you cannot do with them what you can do
with unmanaged pointers, which is accessing and manipulating memory
directly.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Paranoia is just a state of mind.

Saturday, March 24, 2012

The Demise of C#

0 comments:

Post a Comment

extreme basics

Blog Archive

About Me