P
Peter Rilling
Alright, you got me, ALMOST nothing. :}
Kevin Spencer said:
S
Steve C. Orr [MVP, MCSD]
You're certainly entitled to your wrong opinion.
G
Guest
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!
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!
G
Guest
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
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
K
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
"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.
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.
K
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.
And thanks for avoiding the "other" issue! ;-)
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
I
IPGrunt
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
G
Guest
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
(e-mail address removed)
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
(e-mail address removed)
G
Guest
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.
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.
G
Guest
Does it matter which language its written in?
The CLR cares not.
The CLR cares not.
G
Guest
Bryan MacFarlane said:
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
K
Kevin Spencer
Complete agreement here, it's the algorithm that counts the most.
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.
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.
G
Guest
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!!!!
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!!!!
K
Kevin Spencer
As for the Demise of C#...hmm i think it is too popular a syntax to get
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.
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.
G
Guest
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
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 ofpeople 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
R
Rob Nicholson
I was never sure about a language being an indication of the developers
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.
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.
R
Rob Nicholson
Finally in my opinion today a job has to be broken down into different
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.
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.
G
Guest
Get the design correct and the code should fall out of the other end
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
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
G
Guest
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.
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.
G
Guest
Many C# developers today are basically VB.Net developers using a different
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.
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.