The Demise of C#

[Kevin Spencer]

About 2 years ago, and as recently as perhaps 1 year ago, I can recall
seeing many posts about what language to use with ASP.Net. The consensus was
that employers paid more for C# programmers, and it seems that C# became the
darling of the ASP.Net crowd.

In the meantime, I have observed an interesting phenomenon. Originally,
employers hired programmers who used C# because it was based on C, and the
prevailing opinion was (and may still be) that C# developers were better
because they must have known and/or practiced C or C++ at some time, which
would make them better programmers overall. C and C++ are hard-core
programming languages compared to VB.

However, now that nearly everyone has jumped on the C# bandwagon, it seems
to me that the distinction between the languages has nearly disappeared, at
least in terms of evaluating programmers for hire. There seem to be almost
as many clueless C# developers out there as VB.Net developers. Many C#
developers today are basically VB.Net developers using a different syntax. I
wonder if the employers have become aware of this trend?

--

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

[Peter Rilling]

Alright, you got me, ALMOST nothing. :}

"Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> wrote in message
news:eq******** ******@TK2MSFTN GP12.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.r illing.net> wrote in message
news:O6******** ******@TK2MSFTN GP14.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***@DIESPAMM ERSDIEtakempis. com> wrote in message
news:#X******** ******@TK2MSFTN GP12.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.

[Steve C. Orr [MVP, MCSD]]

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******** ********@tk2msf tngp13.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
--------------------------------------------------

[Carl On VB.NET]

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!

[Geoff Willings]

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.

[Kevin Spencer]

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
"conditioni ng" 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****@discussi ons.microsoft.c om> wrote in message
news:4C******** *************** ***********@mic rosoft.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!

[Kevin Spencer]

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******@discus sions.microsoft .com> wrote in message
news:98******** *************** ***********@mic rosoft.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.

[IPGrunt]

On 23 Feb 2005, "Karl Seguin" <karl REMOVE @ REMOVE openmymind
REMOVEMETOO . ANDME net> postulated in news:uRNRvVaGFH A.4004
@tk2msftngp13.p hx.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
interoperabilit y. 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

[Bryan MacFarlane]

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******@micros oft.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.

[Bryan MacFarlane]

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******@micros oft.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.

[Joey Schluchter]

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.