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.
132  4703 
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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@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
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@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.
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]" <St***@Orr.net> wrote in message
news:e$**************@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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@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]" <St***@Orr.net> wrote in message
news:e$**************@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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:#X**************@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: 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.
As a long-time VB person who fumbles with C#, I'm one of those "VB.Net
developers using a different syntax."
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@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 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/foru...t10017013.aspx http://www.eggheadcafe.com/articles/..._generator.asp
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@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.
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]" <in**@turnkeytools.com> wrote in message
news:Oy**************@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/foru...t10017013.aspx
http://www.eggheadcafe.com/articles/..._generator.asp
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@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]" <St***@Orr.net> wrote in message
news:OT**************@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]" <in**@turnkeytools.com> wrote in message
news:Oy**************@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/foru...t10017013.aspx
http://www.eggheadcafe.com/articles/..._generator.asp
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@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" <pe***@nospam.rilling.net> wrote in message
news:O6**************@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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:#X**************@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" <No************@comcast.netNoSpamM> wrote
in message news:96**********************************@microsof t.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]" <BA************@sympatico.ca> wrote in message
news:%2****************@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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@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 @ REMOVE openmymind REMOVEMETOO . ANDME net>
wrote in message news:uR**************@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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@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]" <St***@Orr.net> wrote in message
news:OT**************@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]" <in**@turnkeytools.com> wrote in message
news:Oy**************@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/foru...t10017013.aspx
http://www.eggheadcafe.com/articles/..._generator.asp
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:eq**************@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" <pe***@nospam.rilling.net> wrote in message
news:O6**************@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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:#X**************@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"
<ke***@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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:eq**************@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" <pe***@nospam.rilling.net> wrote in message
news:O6**************@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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:#X**************@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:%2****************@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: 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.
Nice book, Carl! Good reading.
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****@discussions.microsoft.com> wrote in message
news:4C**********************************@microsof t.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 Wi******@discussions.microsoft.com> wrote in message
news:98**********************************@microsof t.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 @ REMOVE openmymind
REMOVEMETOO . ANDME net> postulated in news:uRNRvVaGFHA.4004
@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 br******@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.
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...
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
br******@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: 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.
"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
br******@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" <er****@discussions.microsoft.com> wrote in message
news:73**********************************@microsof t.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
> br******@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" <Ge***********@discussions.microsoft.com> wrote in message
news:0E**********************************@microsof t.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: 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 was never sure about a language being an indication of the developers skill level though.
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/foru...t10017013.aspx
http://www.eggheadcafe.com/articles/..._generator.asp
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@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]" <St***@Orr.net> wrote in message
news:OT**************@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]" <in**@turnkeytools.com> wrote in message
news:Oy**************@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/foru...t10017013.aspx
http://www.eggheadcafe.com/articles/..._generator.asp
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@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" <cm**@discussions.microsoft.com> wrote in message
news:63**********************************@microsof t.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]" <St***@Orr.net> wrote in message
news:OT**************@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]" <in**@turnkeytools.com> wrote in message
> news:Oy**************@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/foru...t10017013.aspx
>> http://www.eggheadcafe.com/articles/..._generator.asp
>>
>>
>>
>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
>> news:%2****************@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: 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!
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" <Ma**********@discussions.microsoft.com> wrote in message
news:88**********************************@microsof t.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" <Ma**********@discussions.microsoft.com> wrote in message
news:88**********************************@microsof t.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: 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 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 Be*********@discussions.microsoft.com> wrote in
message news:1A**********************************@microsof t.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 Be*********@discussions.microsoft.com> wrote in
message news:1A**********************************@microsof t.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.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Kevin Spencer |
last post by:
Is it just me, or am I really observing a trend away from analysis and
probem-solving amongst programmers? Let me be more specific:
It seems that every day, in greater numbers, people are coming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
