473,326 Members | 2,255 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

The Demise of C#

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

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

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

--

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
Nov 19 '05
132 4693
Hi,

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:Ov**************@TK2MSFTNGP15.phx.gbl...
There are a few things that C# can do that VB.NET can't, and there are
things that VB.Net does that C# can't do without added in a bunch of
VB.NET
references.
I'm afraid that's just not true. The only things that C# can't do without

a bunch of VB.Net References is use the Microsoft.VisualBasic NameSpace. This doesn't mean that you can't do those things with C#. In fact, the
Microsoft.VisualBasic NameSpace is mostly a lot of functions that wrap
functionality in the CLR, but with the older VB syntax.

For example, take CInt(string). This is taken straight from VB syntax, but
under the covers it is calling System.Convert.ToInt32(string). Or the
Replace() method in VB.Net, which is a wrapper for System.String.Replace().
On the other hand, you can't use unmanaged code in VB.Net. Now, many people might think that this is a small thing, but it certainly is not for myself. I have written a number of classes and utilities that work with images
(LARGE images), and use unmanaged code and pointers to work with the pixels of the images. Without unmanaged code and pointers, these apps would
function extremely slowly. I find it impossible to believe that I'm the only developer who has this sort of need.
You're not the only one.

Another thing that comes to my mind is when I had to make a really
performant calculations with arrays of integers and I didn't want to write
it in C++ (I'm lazy). The crucial part was allocating the arrays on the
stack using stackalloc. Just another example when one should go for C#.

So, in fact, while C# can do anything that VB.Net can, VB.Net can not do
everything that C# can.
Absolutely.

Greetings,
Martin Dechev
ASP.NET MVP
to wonder: with the technical reasons for using C# all but gone, why would new programmers choose C# (new, meaning they aren't coming from years of
C++
of java development)?
If the technical reasons for using C# were all gone, I wouldn't have

written this. I think the ability to use pointers all by itself is technical reason enough.

--
HTH,

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

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



Nov 19 '05 #51
C# shops also hope to draw from the pool of Java developers as well as OOP
developers. The Jave devs have network/web experience already.

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

"Peter Rilling" wrote:
Okay, I write this message with the full knowledge that I am going to piss a
large number of people off. So I fully expect some flaming to happen.

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

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

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

"Kevin Spencer" <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.


Nov 19 '05 #52
Durring the 30 odd years I've been in this business the question of which
language to use has come up many times. My obersavation, for what its worth,
is that the more that a language/development tool dose for you the less the
programmer thinks about what they are doing. This can lead to code that is
harder to maintain and has performance issues. This is not always the case,
one can write bad code in any language.

As for VB vs C#, while most ASP pages are programmed in VB Script, there
isn't really a choice. All though I use VB Script alot, I prefer a more
"robust" language.
We are in the process of converting our website from ASP using VB Script to
..NET using C#.

So why C#? While VB programmers tend to have more "business" experience then
C programmers, if they learned to program the "Microsoft" way the code is
difficult to maintain and not preform well. Also, VB programms tend to be on
the small side.

We booked 75k orders on our website last month. That number is expected to
double in 6 months. We have to think very carefully about how our code is
written and C programmers have more experience doing that.

All that said, I continue to use VB for small desktop apps & VB Script for
lower volume web sites. For us it was a choice between C# or Java (which is a
much longer descussion)
Nov 19 '05 #53
> So why C#? While VB programmers tend to have more "business" experience
then
C programmers, if they learned to program the "Microsoft" way the code is
difficult to maintain and not preform well. Also, VB programms tend to be
on
the small side.
Oh, so you're a "heightist," eh? Don't like small people? ;-)

--
HTH,

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

"Ken G." <Ken G.@discussions.microsoft.com> wrote in message
news:B6**********************************@microsof t.com... Durring the 30 odd years I've been in this business the question of which
language to use has come up many times. My obersavation, for what its
worth,
is that the more that a language/development tool dose for you the less
the
programmer thinks about what they are doing. This can lead to code that is
harder to maintain and has performance issues. This is not always the
case,
one can write bad code in any language.

As for VB vs C#, while most ASP pages are programmed in VB Script, there
isn't really a choice. All though I use VB Script alot, I prefer a more
"robust" language.
We are in the process of converting our website from ASP using VB Script
to
.NET using C#.

So why C#? While VB programmers tend to have more "business" experience
then
C programmers, if they learned to program the "Microsoft" way the code is
difficult to maintain and not preform well. Also, VB programms tend to be
on
the small side.

We booked 75k orders on our website last month. That number is expected to
double in 6 months. We have to think very carefully about how our code is
written and C programmers have more experience doing that.

All that said, I continue to use VB for small desktop apps & VB Script for
lower volume web sites. For us it was a choice between C# or Java (which
is a
much longer descussion)

Nov 19 '05 #54
>>So, in fact, while C# can do anything that VB.Net can, VB.Net can not
do
everything that C# can.


How about:

Late Binding

Multiple indexed properties

Ease of COM Interop

Optional Parameters

Edit and Continue functionality

User filtered Exception trapping

Better intellisense

Better syntax error recognition in IDE (background compile)

Select Case

With

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

I guess if using unmanaged code is extremely important to your project,
then one would be foolish to pick VB.net over C#, but for the avg
developer, why wouldn't they choose vb.net and if they ever needed to
access unmanaged code, just write a C# DLL?
I think the VB/C# debate can be summed up like this
VB.NET -- "I am TOO a programmer! Please, won't some C++ developers
out there agree??"
C# -- "It's not a real programming language unless it uses brackets."
C++ -- "I'll never concede to be equal to anything"

Nov 19 '05 #55
> We booked 75k orders on our website last month. That number is expected to
double in 6 months. We have to think very carefully about how our code is
written and C programmers have more experience doing that.


Isn't that really all about how you implement the problem, not the
underlying language. After all, you *could* write the whole thing in
assembler and it would work equally as well. Would take you a lot longer
though. In a large program, your problems are algorithmic, not syntactical -
for example, the most efficient way to store and retrieve your data from the
database or reducing the number of postbacks required.

However, I can see where are coming from historically. C is somewhere
between assembler and VB, sort of a mid-level language as opposed to a high
level like Pascal or low-level like assembler or even Forth. Therefore, C
programmers were "closer to the metal" which often gave them a better
understanding of the underlying architecture. And as much of the early APIs
were also written in C, the interface between the operating system and C was
a better fit. I'm thinking here of bit level operations and structures. VB's
early lack of pointers et al made it harder to interface with the operating
system.

C++ was first out of the gates with a popular class OO language so C++
programmers got a head start there as well.

So all these things together (closer to the metal, better interface to
API/OS, classes) made your C/C++ programmer a "better" programmer.

But in terms of C# versus VB.NET, then the differences really are small now
and come down to whether you prefer one syntax over another with a few
enhancements on either side.

I'm not sure though that there is any particular problem than couldn't be
coded in either language.

Rob.
Nov 19 '05 #56
> But in terms of C# versus VB.NET, then the differences really are small
now and come down to whether you prefer one syntax over another with a few
enhancements on either side.

I'm not sure though that there is any particular problem than couldn't be
coded in either language.


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

--
HTH,

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

"Rob Nicholson" <ro***********@nospam-unforgettable.com> wrote in message
news:e6**************@tk2msftngp13.phx.gbl...
We booked 75k orders on our website last month. That number is expected
to
double in 6 months. We have to think very carefully about how our code is
written and C programmers have more experience doing that.


Isn't that really all about how you implement the problem, not the
underlying language. After all, you *could* write the whole thing in
assembler and it would work equally as well. Would take you a lot longer
though. In a large program, your problems are algorithmic, not
syntactical - for example, the most efficient way to store and retrieve
your data from the database or reducing the number of postbacks required.

However, I can see where are coming from historically. C is somewhere
between assembler and VB, sort of a mid-level language as opposed to a
high level like Pascal or low-level like assembler or even Forth.
Therefore, C programmers were "closer to the metal" which often gave them
a better understanding of the underlying architecture. And as much of the
early APIs were also written in C, the interface between the operating
system and C was a better fit. I'm thinking here of bit level operations
and structures. VB's early lack of pointers et al made it harder to
interface with the operating system.

C++ was first out of the gates with a popular class OO language so C++
programmers got a head start there as well.

So all these things together (closer to the metal, better interface to
API/OS, classes) made your C/C++ programmer a "better" programmer.

But in terms of C# versus VB.NET, then the differences really are small
now and come down to whether you prefer one syntax over another with a few
enhancements on either side.

I'm not sure though that there is any particular problem than couldn't be
coded in either language.

Rob.

Nov 19 '05 #57
I'm afraid your arguments simply indict you and (by association) other VB
programmers, and may in fact add to the impression of VB programmers not
being too savvy. Why?
Late Binding
Is this a good thing? (Answer: no - Late Binding is something to be avoided)
Multiple indexed properties
You got me there. This can be achieved with C# however, using a different
syntax.
Ease of COM Interop
Is that a good thing? Regardless, both languages can use COM Interop, and
there is no difference in performance. You're talking about the ease of
writing the code there.
Optional Parameters
Optional Parameters is really a wrapper for overloading. It is not unique to
VB.
Edit and Continue functionality
What does this have to do with VB? This is a feature of the VS.Net IDE.
User filtered Exception trapping
Sorry. Each language implements this, just a bit differently.
Better intellisense
Again, you're mixing up Visual Studio.Net with Visual Basic.Net.
Better syntax error recognition in IDE (background compile)
This is getting embarassing (Visual Studio.Net again) Select Case
switch() in C#
With
A handy little tool for developers, but makes no difference in the app.
Productivity.


Huh?

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

--
HTH,

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

"cmay" <cm**@walshgroup.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
So, in fact, while C# can do anything that VB.Net can, VB.Net can not doeverything that C# can.


How about:

Late Binding

Multiple indexed properties

Ease of COM Interop

Optional Parameters

Edit and Continue functionality

User filtered Exception trapping

Better intellisense

Better syntax error recognition in IDE (background compile)

Select Case

With

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

I guess if using unmanaged code is extremely important to your project,
then one would be foolish to pick VB.net over C#, but for the avg
developer, why wouldn't they choose vb.net and if they ever needed to
access unmanaged code, just write a C# DLL?
I think the VB/C# debate can be summed up like this
VB.NET -- "I am TOO a programmer! Please, won't some C++ developers
out there agree??"
C# -- "It's not a real programming language unless it uses brackets."
C++ -- "I'll never concede to be equal to anything"

Nov 19 '05 #58
just 2 cents from a coder who could not care less about the incessant vb vc
c# debate

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

avoided)

well that is one opinion - and not always possible - see below.
Multiple indexed properties
You got me there. This can be achieved with C# however, using a different
syntax.
Ease of COM Interop


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


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

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


not really - if it was then all languages would support it.
Edit & Continue may be facilitated by the ide but is still up to the
language module to enable it.
User filtered Exception trapping
Sorry. Each language implements this, just a bit differently.
Better intellisense


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


ok so the ide displays the intellisense BUT it is entirely based on
information that comes from the langauge module
see last point.
Better syntax error recognition in IDE (background compile)
This is getting embarassing (Visual Studio.Net again)


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


switch() in C#
With


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


Huh?

BTW, I did not mention ALL of the language features that C# has which

VB.Net does not, only the most salient ones (ones which affect the performance of
the app, or which may be necessary, but are not available in VB). There are some situations in which you can NOT do away with pointers. There are NO
situations in which you can NOT do away with, for example, the With
statement.

--
HTH,

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

"cmay" <cm**@walshgroup.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
So, in fact, while C# can do anything that VB.Net can, VB.Net can not

do
everything that C# can.


How about:

Late Binding

Multiple indexed properties

Ease of COM Interop

Optional Parameters

Edit and Continue functionality

User filtered Exception trapping

Better intellisense

Better syntax error recognition in IDE (background compile)

Select Case

With

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

I guess if using unmanaged code is extremely important to your project,
then one would be foolish to pick VB.net over C#, but for the avg
developer, why wouldn't they choose vb.net and if they ever needed to
access unmanaged code, just write a C# DLL?
I think the VB/C# debate can be summed up like this
VB.NET -- "I am TOO a programmer! Please, won't some C++ developers
out there agree??"
C# -- "It's not a real programming language unless it uses brackets."
C++ -- "I'll never concede to be equal to anything"


Nov 19 '05 #59
> not true.
I have run across a few com components that just could not be used in any
reasonable fashion from c# but worked perfectly well with vb.
This being due to ill-designed com servers that expose everything as
Objects
and c#'s ( lack of ) late binding. Of course you may consider wrapping an
untyped com object with a class that implements zillion InvokeMember()
calls as a reasonable solution - I personally don't
I have run across a few hills that were too steep to climb. Oops.
Correction. I have run a across a few hills that I could not climb. They
weren't too steep for everyyone to climb. How would I know that? All I know
is, I couldn't climb them. On the other hand, I don't live near any hills,
and climbing hills is not a good thing to do. So it really doesn't matter.
not really - if it was then all languages would support it.
Edit & Continue may be facilitated by the ide but is still up to the
language module to enable it.
Okay, so how do you edit and continue using the command-line compiler? How
do you edit and continue while debugging a VB.Net file you're composing in
Notepad? And how does Edit and Continue make your app run better? Or
perhaps, just maybe, this may be part of the "language module" that has
nothing to do with the language, but the IDE?
ok so the ide displays the intellisense BUT it is entirely based on
information that comes from the langauge module
see last point.
See MY last point.

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

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

--
HTH,

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

"gerry" <ge**@hotmail.com> wrote in message
news:Oo**************@TK2MSFTNGP10.phx.gbl... just 2 cents from a coder who could not care less about the incessant vb
vc
c# debate

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:un****************@TK2MSFTNGP10.phx.gbl...
I'm afraid your arguments simply indict you and (by association) other VB
programmers, and may in fact add to the impression of VB programmers not
being too savvy. Why?
> Late Binding


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

avoided)

well that is one opinion - and not always possible - see below.
> Multiple indexed properties


You got me there. This can be achieved with C# however, using a different
syntax.
> Ease of COM Interop


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


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


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

to
VB.
> Edit and Continue functionality


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


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


Sorry. Each language implements this, just a bit differently.
> Better intellisense


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


ok so the ide displays the intellisense BUT it is entirely based on
information that comes from the langauge module
see last point.
> Better syntax error recognition in IDE (background compile)


This is getting embarassing (Visual Studio.Net again)


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


switch() in C#
> With


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


Huh?

BTW, I did not mention ALL of the language features that C# has which

VB.Net
does not, only the most salient ones (ones which affect the performance
of
the app, or which may be necessary, but are not available in VB). There

are
some situations in which you can NOT do away with pointers. There are NO
situations in which you can NOT do away with, for example, the With
statement.

--
HTH,

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

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



Nov 19 '05 #60


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

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

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

--

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


I'm a VB programmer who decided to go to C#. I saw in books how there
seemed to be almost a one-to-one correspondence between C# and VB.Net.
Certainly there's a line-to-line correspondence. I feel that Microsoft will
attempt to do away with VB.NET, they will attempt to slide people into C#.
Also, whether fair or not, it sounds more impress to know "C#", than to know
"VB", even if it's "VB.NET". As you can see in this discussion group, VB has
the reputation of being for, how can I put it, well, people who are a step
below the "pros". I'm not saying this is true, but this seems to be the word
out there.

For all the above rambling reasons, I learned C# at home, even though
I'm still doing VB6 at work (when will they EVER migrate????)
Nov 19 '05 #61
Microsoft will never do away with VB.Net.

--
HTH,

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

"move to c#" <move to c#@discussions.microsoft.com> wrote in message
news:F3**********************************@microsof t.com...


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

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

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

--

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


I'm a VB programmer who decided to go to C#. I saw in books how there
seemed to be almost a one-to-one correspondence between C# and VB.Net.
Certainly there's a line-to-line correspondence. I feel that Microsoft
will
attempt to do away with VB.NET, they will attempt to slide people into C#.
Also, whether fair or not, it sounds more impress to know "C#", than to
know
"VB", even if it's "VB.NET". As you can see in this discussion group, VB
has
the reputation of being for, how can I put it, well, people who are a step
below the "pros". I'm not saying this is true, but this seems to be the
word
out there.

For all the above rambling reasons, I learned C# at home, even though
I'm still doing VB6 at work (when will they EVER migrate????)

Nov 19 '05 #62
> Certainly there's a line-to-line correspondence. I feel that Microsoft
will
attempt to do away with VB.NET, they will attempt to slide people into C#.
That'll take a long time. They tried to get rid of NT 4 and it's still got a
huge user base. They're trying to get rid of VB6 but there's still many,
many lines of code per day being written in it.
I'm still doing VB6 at work (when will they EVER migrate????)


QED :-)

Cheers, Rob.
Nov 19 '05 #63
Wouldn't you think that the reason microsoft would choose C# is because
their developers were previously coding in C++?

C++ developers are not going to learn VB when C# is available.

Nov 19 '05 #64
I wouldn't think so. As I mentioned, the CLR is full of managed classes that
have low-level functionality inside them. I would strongly suspect that some
of them use pointers (in fact, a class is technically a pointer to a
structure). You can't work with pointers using VB. Therefore, I strongly
suspect that the choice of C# was for more practical reasons than developer
preference.

--
HTH,

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

"cmay" <cm**@walshgroup.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...
Wouldn't you think that the reason microsoft would choose C# is because
their developers were previously coding in C++?

C++ developers are not going to learn VB when C# is available.

Nov 19 '05 #65
out of curiousity, why is your company still writing code in vb6. is it
mainly maintainance or is that new development?

"Rob Nicholson" <ro***********@nospam-unforgettable.com> wrote in message
news:Ot**************@TK2MSFTNGP14.phx.gbl...
Certainly there's a line-to-line correspondence. I feel that Microsoft
will
attempt to do away with VB.NET, they will attempt to slide people into
C#.
That'll take a long time. They tried to get rid of NT 4 and it's still got a huge user base. They're trying to get rid of VB6 but there's still many,
many lines of code per day being written in it.
I'm still doing VB6 at work (when will they EVER migrate????)


QED :-)

Cheers, Rob.

Nov 19 '05 #66

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:OX*************@TK2MSFTNGP15.phx.gbl...
Microsoft will never do away with VB.Net.
(As much as us C# developers would like them to... ;-) (OK, Just Kidding!
sheesh... lol)

On the whole subject, I came from a VB4~VB6 background. I did the whole ASP
thing, COM, COM+ etc using VB and was relatively happy until C# came around.
I have always enjoyed doing back-end systems as opposed to front-end GUIs
and I never realized just how much protection VB offered to the common
developer. Not to mention the fact of how much went on behind the scenes
without my knowledge. Nor do feel that I had a true understanding of what
was going on under the hood when it came to my VB applications. I was
pitifully oblivious to most of it, and I really didn't care. My code was
clean and optimized. It did exactly what it was supposed to and worked (most
of the time) flawlessly. Yet, I did not take the time to actually look at
*why* it worked the way it did or what the VB runtimes were doing in the
background.

I have now been using C# since BETA1 of .NET and I can honestly say that I
am ashamed to look back on some of my old code and code habits and think
"Man, I wrote THAT?!". The semantic differences between the two are simply
mind boggling, IMHO. (Just look at how VB.NET uses the "Friend" keyword. WTH
is up with that?!). (My flame here would be, WTH did MSFT not just use the
same keywords in both languages? I could have dealt with "public friend void
MyMethod()" or something like that. It's not like the Friend keyword existed
in VB6, so it wasn't for backwards compatibility.)

While I don't knock VB/VB.NET programmers, I do look at the language as a
"shortcut" language now a days. Even with .Net and all of MSFT's touting of
the CLR and the languages compiling to the same base, there are simply
things that you can do with C# that you cannot do *easily* (or at all, for
that matter) with VB.NET. Now, if you throw in the fact that VB *still*
abstracts the developer from the things that are happening under the hood,
you can start to see why I call it a shortcut language. (There was a post in
one of the other groups about why VB treats strings differently than C#
does. It goes to the fact of my reasoning).

Also, with NET 2.0 looming, there is definitely a rift forming between the
languages (and not just in the IDE). The whole debate that was sparked with
E&C should be proof of that. I think I saw a total of 50 C# developers that
actually wanted E&C (ok, I'm exaggerating, but it was a ridiculously low
number compared to the VB developers that wanted it). As this rift continues
to grow, I see yet another period where you have C# developers (much akin to
the C/C++ developers during the VB4~VB6 era) doing more enterprise-type
applications and VB developers doing more front-end/desktop applications. As
long as MSFT doesn't decide to spilt up the IDE again (Like VS6 and
earlier), I think we can all get along. :-)

HTH,
~d


--
HTH,

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

"move to c#" <move to c#@discussions.microsoft.com> wrote in message
news:F3**********************************@microsof t.com...


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

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

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

--

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


I'm a VB programmer who decided to go to C#. I saw in books how there
seemed to be almost a one-to-one correspondence between C# and VB.Net.
Certainly there's a line-to-line correspondence. I feel that Microsoft
will
attempt to do away with VB.NET, they will attempt to slide people into
C#.
Also, whether fair or not, it sounds more impress to know "C#", than to
know
"VB", even if it's "VB.NET". As you can see in this discussion group, VB
has
the reputation of being for, how can I put it, well, people who are a
step
below the "pros". I'm not saying this is true, but this seems to be the
word
out there.

For all the above rambling reasons, I learned C# at home, even though
I'm still doing VB6 at work (when will they EVER migrate????)


Nov 19 '05 #67

I have run across a few hills that were too steep to climb. Oops.
Correction. I have run a across a few hills that I could not climb. They weren't too steep for everyyone to climb. How would I know that? All I know is, I couldn't climb them. On the other hand, I don't live near any hills, and climbing hills is not a good thing to do. So it really doesn't matter.
This sounds like a good argument. So you are saying that since the
vast majority of .net developers don't use C#'s unmanaged code ability,
it doesn't really matter right?

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

Why do you get so angry when people talk about real world examples?
How many people write their C# apps in Notepad? I can understand that
you are not happy that VS.net gives VB developers some nice features
that C# developers don't have, but come on, VS.NET is the development
tool most people use. Can't I apply your earlier argument again: I
always write my code w/ VS.net, so it doesn't really matter.

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

Okay, let's for the sake of argument assume that you have pointed up

a few things you can do with VB.Net that you can't with C# (only for the sake of argument). How many of these things can you not do without? How many of these things affect the performance of your app? Answer: none.
Just to prove I am not mean spirted or trolling, I will absolutely
concede this point. The things I list as VB.NET "HAVES" are nothing
that are going to make a development team say "For this project we HAVE
to use VB, we can't use C#".

On the other
hand, let's say you want to write a custom image filter, to do blurring, or sharpness, or contrast. And you're writing with VB.Net. No pointers. Now, you're processing a 600X800 image. How long will it take to process the whole image? Well, from personal experience I can tell you that it is an order of magnitude slower to do without pointers. We're talking hundreds of times slower.
Actually, if it were an order of magnitude faster, it would be only be
10 +/- times faster. 100 times faster is 2 orders of magnitude. :)

In fact, you could not sell such an app. The competition would kill it.

Yes, I agree. However, let me ask a few questions: If this app was so
performance intensive, why not write the whole product in unmanaged
code? Q2: How would your C# app perform against an app written in 95%
VB.NET, w/ 5% written in C# to do the unmanaged code? I'm guessing
pretty similar.
So, in terms of real value (as compared with trivial conveniences), there is nothing that VB offers that C# doesn't.


There is 1 difference that is not trivial, and that is productivity. I
know you argued that this was not due to VB.Net, but in fact was simply
a feature of VS. From an analitical standpoint, this may be right
(although the previous poster seemed pretty sure it was due to things
within the language module, but I don't know about that so I won't
pretend to) in practice you can develop many applications faster in
VB.net than C#. Part of the intellisense benefits of VB.NET simply
cannot be implemented in C# because of how ECMA script works. VB puts
the type after "As" so the IDE knows to provide you with intellisense.
This can't work the same in C# because you declare the type first.
Now, you are talking about real value vs trivial conveniences... How
about "this web application will take 100 days in VB.Net, or 130 days
in C#", or "to complete this project in time we need 3 VB.net
developers, or 4 C# developers". That is real value. I know you will
say that I am simply not good enough in C# and that is the only reason
why I feel vb.net is quicker to develop in, but I won't agree with that
argument.

The amount of time that the VS.Net IDE saves a developer who chooses VB
is something to be seriously considered. Is this added productivity
due to VBs use of "Dim"? No, of course not, and if I had to use
notepad and command line compiler (which I have done), I would not
suggest that VB is still more productive. But as long as I am working
in VS.Net, my choice to write as much code in VB.net will result in
more productivity.

Nov 19 '05 #68
I really dislike when people try to say a language is 'dying', especially
when I've worked so hard to become a respected developer in said language.
But the sad truth is I've wondered myself about the security of C#. It's
awsome, it's almost too awsome, but platform dependance has kept it from
growing like it ought. C# is like the evolution of C++, In My Opinion. The
..NET Framework has given us so much power that we never had before, at such
an introductory level. Sure, you can do everything in C# in many other
languages, but the simplicity and streamlined process is so improved in C#.
It truely is a marvel in engineering and thought.

I've knocked VB.NET/VB6 for a long time, but in all honesty, Visual Basic is
a programming language, and it has it's place. While it may not be as
powerful as C++ or C#, it's essential to the world. There is a very fine line
where Visual Basic loses power to C#, and I believe that line is getting
further and further away with everything the VB community does. They
certainly are a hearty bunch who know what they are doing. I don't think VB
is going anywhere.

"DotNet Coder" wrote:

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:OX*************@TK2MSFTNGP15.phx.gbl...
Microsoft will never do away with VB.Net.


(As much as us C# developers would like them to... ;-) (OK, Just Kidding!
sheesh... lol)

On the whole subject, I came from a VB4~VB6 background. I did the whole ASP
thing, COM, COM+ etc using VB and was relatively happy until C# came around.
I have always enjoyed doing back-end systems as opposed to front-end GUIs
and I never realized just how much protection VB offered to the common
developer. Not to mention the fact of how much went on behind the scenes
without my knowledge. Nor do feel that I had a true understanding of what
was going on under the hood when it came to my VB applications. I was
pitifully oblivious to most of it, and I really didn't care. My code was
clean and optimized. It did exactly what it was supposed to and worked (most
of the time) flawlessly. Yet, I did not take the time to actually look at
*why* it worked the way it did or what the VB runtimes were doing in the
background.

I have now been using C# since BETA1 of .NET and I can honestly say that I
am ashamed to look back on some of my old code and code habits and think
"Man, I wrote THAT?!". The semantic differences between the two are simply
mind boggling, IMHO. (Just look at how VB.NET uses the "Friend" keyword. WTH
is up with that?!). (My flame here would be, WTH did MSFT not just use the
same keywords in both languages? I could have dealt with "public friend void
MyMethod()" or something like that. It's not like the Friend keyword existed
in VB6, so it wasn't for backwards compatibility.)

While I don't knock VB/VB.NET programmers, I do look at the language as a
"shortcut" language now a days. Even with .Net and all of MSFT's touting of
the CLR and the languages compiling to the same base, there are simply
things that you can do with C# that you cannot do *easily* (or at all, for
that matter) with VB.NET. Now, if you throw in the fact that VB *still*
abstracts the developer from the things that are happening under the hood,
you can start to see why I call it a shortcut language. (There was a post in
one of the other groups about why VB treats strings differently than C#
does. It goes to the fact of my reasoning).

Also, with NET 2.0 looming, there is definitely a rift forming between the
languages (and not just in the IDE). The whole debate that was sparked with
E&C should be proof of that. I think I saw a total of 50 C# developers that
actually wanted E&C (ok, I'm exaggerating, but it was a ridiculously low
number compared to the VB developers that wanted it). As this rift continues
to grow, I see yet another period where you have C# developers (much akin to
the C/C++ developers during the VB4~VB6 era) doing more enterprise-type
applications and VB developers doing more front-end/desktop applications. As
long as MSFT doesn't decide to spilt up the IDE again (Like VS6 and
earlier), I think we can all get along. :-)

HTH,
~d


--
HTH,

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

"move to c#" <move to c#@discussions.microsoft.com> wrote in message
news:F3**********************************@microsof t.com...


"Kevin Spencer" wrote:

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

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

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

--

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


I'm a VB programmer who decided to go to C#. I saw in books how there
seemed to be almost a one-to-one correspondence between C# and VB.Net.
Certainly there's a line-to-line correspondence. I feel that Microsoft
will
attempt to do away with VB.NET, they will attempt to slide people into
C#.
Also, whether fair or not, it sounds more impress to know "C#", than to
know
"VB", even if it's "VB.NET". As you can see in this discussion group, VB
has
the reputation of being for, how can I put it, well, people who are a
step
below the "pros". I'm not saying this is true, but this seems to be the
word
out there.

For all the above rambling reasons, I learned C# at home, even though
I'm still doing VB6 at work (when will they EVER migrate????)



Nov 19 '05 #69
I did not come from a pure C++ background. I chose C# because it was so much
cleaner and object oriented right from the start than C++. I liked how it was
so adaptable to GUI implementation, and how the Visual Studio IDE made
development much easier. I hate sloppy code, and I dispise RAD Tools, but C#
was just so well done that I couldn't help but be drawn to it.

"Kevin Spencer" wrote:
There are a few things that C# can do that VB.NET can't, and there are
things that VB.Net does that C# can't do without added in a bunch of
VB.NET
references.


I'm afraid that's just not true. The only things that C# can't do without a
bunch of VB.Net References is use the Microsoft.VisualBasic NameSpace. This
doesn't mean that you can't do those things with C#. In fact, the
Microsoft.VisualBasic NameSpace is mostly a lot of functions that wrap
functionality in the CLR, but with the older VB syntax.

For example, take CInt(string). This is taken straight from VB syntax, but
under the covers it is calling System.Convert.ToInt32(string). Or the
Replace() method in VB.Net, which is a wrapper for System.String.Replace().

On the other hand, you can't use unmanaged code in VB.Net. Now, many people
might think that this is a small thing, but it certainly is not for myself.
I have written a number of classes and utilities that work with images
(LARGE images), and use unmanaged code and pointers to work with the pixels
of the images. Without unmanaged code and pointers, these apps would
function extremely slowly. I find it impossible to believe that I'm the only
developer who has this sort of need.

So, in fact, while C# can do anything that VB.Net can, VB.Net can not do
everything that C# can.
to wonder: with the technical reasons for using C# all but gone, why would
new programmers choose C# (new, meaning they aren't coming from years of
C++
of java development)?


If the technical reasons for using C# were all gone, I wouldn't have written
this. I think the ability to use pointers all by itself is technical reason
enough.

--
HTH,

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

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


Nov 19 '05 #70
> out of curiousity, why is your company still writing code in vb6. is it
mainly maintainance or is that new development?


For us, it's maintenence and enhancements to a large VB6 app. But it's going
to require maintenence for at least the next five years for some customers.
Classic case of "it's works, so don't fix it". There will be a lot of that
around.

Cheers, Rob.
Nov 19 '05 #71
> MyMethod()" or something like that. It's not like the Friend keyword
existed in VB6, so it wasn't for backwards compatibility.)
But it was a case of using the same keyword as C++ wasn't it?
While I don't knock VB/VB.NET programmers, I do look at the language as a
"shortcut" language now a days. Even with .Net and all of MSFT's touting
of
Whilst I'd agree in teh VB6 vs. C++ discussion, VB.NET should really be
classed as a shortcut language. But even if it was - what's actually wrong
with that? :-) In every parts of our lives we try and use as many shortcuts
to make our life easier or to achieve something quicker.
abstracts the developer from the things that are happening under the hood,
you can start to see why I call it a shortcut language. (There was a post
in one of the other groups about why VB treats strings differently than C#
does. It goes to the fact of my reasoning).
But in 99% of the cases, this hiding is a good thing IMHO. After all, aren't
using objects and abstraction partly about trying to "hide" the underlying
mechanisms:

Window.SaveAsGIF("c:\wibble.gif")

Is all about hiding the nasty intricies of GIF LZW (it is LZW isn't it?)
compression.
number compared to the VB developers that wanted it). As this rift
continues to grow, I see yet another period where you have C# developers
(much akin to the C/C++ developers during the VB4~VB6 era) doing more
enterprise-type applications and VB developers doing more
front-end/desktop applications. As long as MSFT doesn't decide to spilt up
the IDE again (Like VS6 and earlier), I think we can all get along. :-)


But I'd agrue that's still historical in that your back-end guys used C++ in
the past whereas your front-end programmers might have used VB6 and
therefore feel more at home with and C# and VB.NET respectively. It's not
because there are some things that VB.NET just can't do.

I used to do most of my programming in C++ but that was because I came from
a games programmer background and the C++ (or even C) compilers were the
first things to offer a viable alternative to assembler. History again.

But the last large project I worked on was in VB6 and I certainly don't
think it's a weaker product because of that. We're now writing a mid-sized
ASP.NET system using VB.NET and whilst we did think "shall we try C# a the
same time", the reasons were more that we fancied trying something new, not
that there was a sound business reason for doing so. In fact, quite the
opposite - it would have been slower to develop using C# due to the learning
curve.

And besides, good programmers can program in any langauge :-)

Cheers, Rob.
Nov 19 '05 #72
> a programming language, and it has it's place. While it may not be as
powerful as C++ or C#, it's essential to the world. There is a very fine
line


Depends I think how you define "powerful". This web page has some arguments
both ways:

http://blogs.msdn.com/csharpfaq/arch.../11/87816.aspx

Interestingly, VB.NET is getting two of the C# advantages in the next
version: overloading (hmm, not sure that's an advantage, I've been
thoroughly confused by overloading on occasion) and unsigned support.

VB.NET vs. C# is a bit like English versus French. English doesn't care - it
absorbs and expands as required (like VB.NET) whereas C# tries to stay a bit
more pure (like French).

Cheers, Rob.
Nov 19 '05 #73
> Interestingly, VB.NET is getting two of the C# advantages in the next
version: overloading (hmm, not sure that's an advantage, I've been
thoroughly confused by overloading on occasion) and unsigned support.


Overloading and unsigned support are nice, I suppose. However, you can get
along quite nicely without them. Not that I consider optional parameters to
be something desirable, but you can certainly use them with VB.Net to obtain
a semblance of overloading. On the other hand, if VB.Net were to support
pointers, without which some apps can't be written, I might think about
using it again. Still, as I'm already quite used to C#, I probably wouldn't
by now!

--
HTH,

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

"Rob Nicholson" <ro***********@nospam-unforgettable.com> wrote in message
news:%2******************@tk2msftngp13.phx.gbl...
a programming language, and it has it's place. While it may not be as
powerful as C++ or C#, it's essential to the world. There is a very fine
line


Depends I think how you define "powerful". This web page has some
arguments both ways:

http://blogs.msdn.com/csharpfaq/arch.../11/87816.aspx

Interestingly, VB.NET is getting two of the C# advantages in the next
version: overloading (hmm, not sure that's an advantage, I've been
thoroughly confused by overloading on occasion) and unsigned support.

VB.NET vs. C# is a bit like English versus French. English doesn't care -
it absorbs and expands as required (like VB.NET) whereas C# tries to stay
a bit more pure (like French).

Cheers, Rob.

Nov 19 '05 #74

"Rob Nicholson" <ro***********@nospam-unforgettable.com> wrote in message
news:eu**************@TK2MSFTNGP15.phx.gbl...
MyMethod()" or something like that. It's not like the Friend keyword
existed in VB6, so it wasn't for backwards compatibility.)
But it was a case of using the same keyword as C++ wasn't it?


C++ had the Friend keyword? I never remember seeing that anywhere, then
again, my C++ is almost as good as my Greek (which in almost
non-existant)... lol
While I don't knock VB/VB.NET programmers, I do look at the language as a
"shortcut" language now a days. Even with .Net and all of MSFT's touting
of
Whilst I'd agree in teh VB6 vs. C++ discussion, VB.NET should really be
classed as a shortcut language. But even if it was - what's actually wrong
with that? :-) In every parts of our lives we try and use as many
shortcuts to make our life easier or to achieve something quicker.


True, but, I think that where you mention later in the post about VB.NET vs.
C# as English vs. French, that argument applies here. I have always noticed
that C/C++/C#/Java/etc developers are usually very touchy about code flow
(for lack of a better term and I am very much one of those types of
people)... "Don't have sloppy code. Don't have unreadable code.". While
shortcuts are great and all (even in C#), having a language like VB6 or
VB.NET, where you have to really hack around some things makes for totally
horrible code. Take for instance, optional parameters... Great concept, but
makes debugging hell, espesically when you inherit the code from someone
else. :-)
abstracts the developer from the things that are happening under the
hood, you can start to see why I call it a shortcut language. (There was
a post in one of the other groups about why VB treats strings differently
than C# does. It goes to the fact of my reasoning).
But in 99% of the cases, this hiding is a good thing IMHO. After all,
aren't using objects and abstraction partly about trying to "hide" the
underlying mechanisms:

Window.SaveAsGIF("c:\wibble.gif")

Is all about hiding the nasty intricies of GIF LZW (it is LZW isn't it?)
compression.


Sure, but the problem here is that whilst hiding the uglies from the
developer, the developer isn't educated to the fact of WHY the code works.
The developer just KNOWS it works and goes about his or her job oblibious to
what is happening behind the scenes. Not only does hiding and abstraction
like this lead to bad patterns and practices, but it also just promotes more
and more crappy applications being released that don't play nicely out in
the real world. (Although, I have to say that this might be more of a
laziness or newbie problem, rather than the language itself.)

IMHO, I would like to see all developers take an in depth course on Windows
internals before ever writing a single line of code. lol :-)
number compared to the VB developers that wanted it). As this rift
continues to grow, I see yet another period where you have C# developers
(much akin to the C/C++ developers during the VB4~VB6 era) doing more
enterprise-type applications and VB developers doing more
front-end/desktop applications. As long as MSFT doesn't decide to spilt
up the IDE again (Like VS6 and earlier), I think we can all get along.
:-)
But I'd agrue that's still historical in that your back-end guys used C++
in the past whereas your front-end programmers might have used VB6 and
therefore feel more at home with and C# and VB.NET respectively. It's not
because there are some things that VB.NET just can't do.


Well, it did take 3+ versions of the framework to be released before VB.NET
got overloading. That was one thing VB.NET couldn't do ;-)
I used to do most of my programming in C++ but that was because I came
from a games programmer background and the C++ (or even C) compilers were
the first things to offer a viable alternative to assembler. History
again.

But the last large project I worked on was in VB6 and I certainly don't
think it's a weaker product because of that. We're now writing a mid-sized
ASP.NET system using VB.NET and whilst we did think "shall we try C# a the
same time", the reasons were more that we fancied trying something new,
not that there was a sound business reason for doing so. In fact, quite
the opposite - it would have been slower to develop using C# due to the
learning curve.

And besides, good programmers can program in any langauge :-)
Totally agreed on that one :)

Cheers, Rob.

Enjoy!
~d
Nov 19 '05 #75
Another quick reply...

Kevin Spencer wrote:
Is this a good thing? (Answer: no - Late Binding is something to be avoided)
Aside from the places where you are working with some COM interop
function that really makes you need late binding, I have to say that I
whole heartily agree with you.

One of my pet peves is when I am going through some code that another
programmer wrote and they have functions that don't have their return
type specified, or when doing some "quick dirty" function they dim a
variable w/o a type "Dim i". It doesn't fall under this same category,
but it also drives me nuts when VB developers don't declare
functions/subs as public or private, or when they have class level
variables that are declared with "Dim" as opposed to "Private" or
"Public". Maybe I'm a C# guy at heart? :)

Optional Parameters


Optional Parameters is really a wrapper for overloading. It is not

unique to VB.

This is totally true, that the functionality of optional parameters can
be 100% acheived in C# via overloading, but this is actually a case of
the VB *language* having something C# doesn't. A function w/ 15
optional parameters would take a lot longer to write in C# than in VB,
and that would hold true if you were coding in VS.NET or notepad. Now
does a function with 15 optional parameters ring of a good design....
probably not, but there are cases where having a bunch optional
parameters CAN be a good idea.

User filtered Exception trapping


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

I didn't think C# could do this, are you sure? What I am talking about
is the ability in VB.Net to trap a specific error, but only enter the
Catch block if some other condition is met, e.g. Catch ex as
ThreadAbortException When bCatchError = true and GlobalInfo.ServerName
<> "Development" ... or whatever). If the When condition is not met,
the exception is passed down to the next level, where you might trap it
as a general exception like Catch ex as Exception. I don't think you
can do this in C#, but I am not 100% sure.

Select Case


switch() in C#
With


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

app.
It's my understanding that C# requires the switched var to be a int or
string, while in VB it can be a lot of other types. Also, and probably
more important, is that in C# the expression used in the Case has to be
a compile time value, e.g. case 123, but in VB it can be a variable
Case Me.SomeValue.

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

Until I read this last paragraph I had actually forgotten about some of
the initial well know differences between the first releases of the 2
products.

I think at one point you couldn't do short circuiting in VB.net... or
maybe it was that they were going to short circut by default, but then
decided against it cause it would break VB6 code? Eitherway, I use the
OrElse and AndAlso quite a bit but think its pretty stupid to have to.
I also forgot about stuff like the "=" overriding that you can do in
C#, which I think you still can't do in VB.

Regarding pointers: agreed. If the project needs pointers, you better
be using C#. No argument.

Nov 19 '05 #76
Derek,

What did you do before you did C# work?
What led you to select C# over VB.Net?

I don't want to get into an argument over your choice or anything, I'm
just curious. :)

Chris

Nov 19 '05 #77
> C++ had the Friend keyword? I never remember seeing that anywhere, then
again, my C++ is almost as good as my Greek (which in almost
non-existant)... lol
Yes, I'm pretty sure it had. When it popped up in VB.NET it was a complete
surprise so it must have been C++. Not used anything else!
IMHO, I would like to see all developers take an in depth course on
Windows internals before ever writing a single line of code. lol :-)
Well yes of course that would be ideal :-) But I don't know about you, but I
don't live in an ideal world. I have to deliver to some pretty tight
deadlines! Now maybe if you worked in a pure research environment, then that
would be okay.
Well, it did take 3+ versions of the framework to be released before
VB.NET got overloading. That was one thing VB.NET couldn't do ;-)


Yeah, but I think I said elsewhere, I'm not sure overloading is a good idea
<grin>

1 + 1 = 2

or does it?....

Cheers, Rob.
Nov 19 '05 #78
Just to take it a little further for discussion...

Do you think the ability to work with low level functionality was
something that was ADDED to C#, maybe because those developing the
framework needed it, or MS thought that C++ programmers would be turned
off if they were totally locked out of unmanaged code. Or, do you
think it was NOT INCLUDED with VB.Net because they figured (and
probably correctly) that most people using VB.Net would not be writing
unmanaged code (because they would be using C#) ?

In other words do you think that unmanaged code was a special gift from
MS to C#, or do you think unmanaged code is totally available in .NET
apps, but MS didn't do the work necessary to make it accessible to
VB.Net?

Chris
Kevin Spencer wrote:
I wouldn't think so. As I mentioned, the CLR is full of managed classes that have low-level functionality inside them. I would strongly suspect that some of them use pointers (in fact, a class is technically a pointer to a structure). You can't work with pointers using VB. Therefore, I strongly suspect that the choice of C# was for more practical reasons than developer preference.


Nov 19 '05 #79
Hi Chris,

Imagine a programming platform that did NOT give you the ability to do
low-level coding. What good would it be? Sure, it would do quite a bit, but
not everything. And then where would you be? You'd have to write your whole
app in unmanaged code, like C++. That would not be a good selling point for
the platform. Programmers are generally control freaks by nature (at least
the good ones). You don't want to take control away from them. They will
just go somewhere that they can have control.

C# is a superset (extension) of C++, which is a superset of C. Therefore,
everything that is in C is in C++, and everything that is in C++ is in C#.
Any "flavor" of C will have all the components of C.

On the other hand, VB has NEVER supported low-level functionality. VB was
written for people who need to throw something together quick and dirty. It
was never intended as a full-fledged programming language. VB.Net is really
the first version of VB to take a stab at it. But one of the "missions" of
VB is to hide all the inner complexity of applications from developers, to
handle all that technical stuff for them. I believe Microsoft made a gallant
effort there, in terms of elevating the language, but they did have to think
about all those shade-tree VB developers out there who wouldn't know a
pointer from a hole in the ground. Pointers in particular are a difficult
subject to grasp, especially if you don't know how data is stored in memory,
what a variable is, what a data type is, etc. And they are dangerous. So, my
guess is, Microsoft made a compromise, in the interest of losing as few
customers as possible, while elevating existing VB developers to a more
powerful level, understanding data types, using true OOP, etc. Even so, it
seems that many VB people are drowning in the influx of new information. And
let's face it, some people are just too lazy for their own good.

Microsoft has had to walk a virtual tightrope as a result of VB. I can't
fault them for their efforts. As I said, VB wasn't originally designed as a
"true" programming language, more like a "macro" language. Unfortunately,
the rest of the world didn't seem to listen. It became very popular, and
became used in all kinds of professional applications. Now we have an entire
segment of the developer world that uses VB for just about everything. And
that is a problem. Microsoft has had to gradually elevate the language and
its capabilities over the years as a result. I just hope they don't stop!

--
HTH,

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

"cmay" <cm**@walshgroup.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
Just to take it a little further for discussion...

Do you think the ability to work with low level functionality was
something that was ADDED to C#, maybe because those developing the
framework needed it, or MS thought that C++ programmers would be turned
off if they were totally locked out of unmanaged code. Or, do you
think it was NOT INCLUDED with VB.Net because they figured (and
probably correctly) that most people using VB.Net would not be writing
unmanaged code (because they would be using C#) ?

In other words do you think that unmanaged code was a special gift from
MS to C#, or do you think unmanaged code is totally available in .NET
apps, but MS didn't do the work necessary to make it accessible to
VB.Net?

Chris
Kevin Spencer wrote:
I wouldn't think so. As I mentioned, the CLR is full of managed

classes that
have low-level functionality inside them. I would strongly suspect

that some
of them use pointers (in fact, a class is technically a pointer to a

structure). You can't work with pointers using VB. Therefore, I

strongly
suspect that the choice of C# was for more practical reasons than

developer
preference.

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

"move to c#" wrote:


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

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

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

--

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


I'm a VB programmer who decided to go to C#. I saw in books how there
seemed to be almost a one-to-one correspondence between C# and VB.Net.
Certainly there's a line-to-line correspondence. I feel that Microsoft will
attempt to do away with VB.NET, they will attempt to slide people into C#.
Also, whether fair or not, it sounds more impress to know "C#", than to know
"VB", even if it's "VB.NET". As you can see in this discussion group, VB has
the reputation of being for, how can I put it, well, people who are a step
below the "pros". I'm not saying this is true, but this seems to be the word
out there.

For all the above rambling reasons, I learned C# at home, even though
I'm still doing VB6 at work (when will they EVER migrate????)

Nov 19 '05 #81
> Anyone who thinks c# programmers are 'better' than VB programmers is an
idiot.
I wouldn't put it that way, but in essence I agree with you there.
Has it ever occured to people like you that the core competence of a
VB developer might be in the business rules they are trying to fulfill,
and
that the vision of such a language might be to remove all the uneccessary
complexity from programming so as to allow such an individual to do just
that?
Are you responding to my post? I will assume that "people like you" is a
reference to people like myself. Please point out where I made the statement
that C# programmers are better than VB programmers. A careful reading of my
message will prove the opposite. There is a big difference between the
reality of things, and the way things are perceived by many people. I was
talking about perceptions, not reality.
By your reasoning, the habbits of an assembler programmer would be
welcome as a sign of intelligence towards OOPs related tasks!
I'm afraid not. By my reasoning, there is a perception out there that has
nearly nothing to do with reality. It is your perception of my reasoning
that is in error.
I am really
sorry guy but the time for knowing that the bios looks in the first boot
sector at address 0800 to start running the operating system is OVER.
Maybe for you, but not for everyone. In any case, I didn't imply any such
thing.
VB has
evolved into a powerfull programming language for fulfilling business
rules.
C and C++ are low level languages that, becuase of their features, can be
used for system development and the like.
I don't develop systems. I develop applications. Some of those applications
require low-level programming. So, while you seem familiar with VB, you
don't seem to understand much of anything about the use of C and its
derivatives.

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

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

--
HTH,

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

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

"move to c#" wrote:


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


I'm a VB programmer who decided to go to C#. I saw in books how there
seemed to be almost a one-to-one correspondence between C# and VB.Net.
Certainly there's a line-to-line correspondence. I feel that Microsoft
will
attempt to do away with VB.NET, they will attempt to slide people into
C#.
Also, whether fair or not, it sounds more impress to know "C#", than to
know
"VB", even if it's "VB.NET". As you can see in this discussion group, VB
has
the reputation of being for, how can I put it, well, people who are a
step
below the "pros". I'm not saying this is true, but this seems to be the
word
out there.

For all the above rambling reasons, I learned C# at home, even though
I'm still doing VB6 at work (when will they EVER migrate????)

Nov 19 '05 #82


"Smithers" wrote:

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


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

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

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

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

Why is this?

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

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

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

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

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

Nov 19 '05 #84
"Cowboy (Gregory A. Beamer) - MVP" wrote:
There are plenty of clueless C++, VB, et al, developer.
There's a reason for this:

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

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

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

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

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

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

You can find Dougie here to look for yourself:

http://tinyurl.com/6szrc

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

***************************
Think Outside the Box!
***************************
(This is trite and a poor interpretation of deMarco's "Lateral Thinking" - I
suggest you get one of his books...)
"Kevin Spencer" wrote:

About 2 years ago, and as recently as perhaps 1 year ago, I can recall
seeing many posts about what language to use with ASP.Net. The consensus was
that employers paid more for C# programmers, and it seems that C# became the
darling of the ASP.Net crowd.
And before ASP.Net, it was ASP. Employers paid a lot more (and still do)
for ASP. The problem is a sizeable percentage of the ASP crowd were rats
jumping off of a sinking ship - all of the static HTMLers realizing their
pond was shrinking and they'd better jump...fast. Think about non-programmers
writing ASP + client-side JScript. Fortunately, a measure of competency
became a requirement and started to turn the tide.
In the meantime, I have observed an interesting phenomenon. Originally,
employers hired programmers who used C# because it was based on C, and the
prevailing opinion was (and may still be) that C# developers were better
because they must have known and/or practiced C or C++ at some time, which
would make them better programmers overall. C and C++ are hard-core
programming languages compared to VB. However, now that nearly everyone has jumped on the C# bandwagon, it seems
to me that the distinction between the languages has nearly disappeared, at
least in terms of evaluating programmers for hire. There seem to be almost
as many clueless C# developers out there as VB.Net developers. Many C#
developers today are basically VB.Net developers using a different syntax. I
wonder if the employers have become aware of this trend?


At the risk of sounding rude, how is this the demise of c#?

Nov 19 '05 #85
> "You don't have to be good, just good enough."
-me, ca. late 80s

You can also consider things such as "bad coders can write bad code faster
than good coders can write good code" (or good coders can fix bad code).
People like to code and like to get paid for something they like to do.
This
is without regard to the quality of the work they produce. Generally, the
only measurement of the quality is "does it work?".
I hope you don't really feel this way. I have certainly seen enough of this
type of mindset (lacking forethought or any appreciation of future
consequences for present decisions) in my life. However, there are
individuals, businesses, and companies that do not subscribe to such a
Dilbert-esque business philosophy. Such individuals, businesses and
companies generally seem to survive and prosper over the long haul, as that
is what they plan for.

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

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

--
HTH,

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

"70Bang!" <70*****@discussions.microsoft.com> wrote in message
news:4A**********************************@microsof t.com... "Cowboy (Gregory A. Beamer) - MVP" wrote:
There are plenty of clueless C++, VB, et al, developer.


There's a reason for this:

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

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

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

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

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

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

You can find Dougie here to look for yourself:

http://tinyurl.com/6szrc

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

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


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

> About 2 years ago, and as recently as perhaps 1 year ago, I can recall
> seeing many posts about what language to use with ASP.Net. The
> consensus was
> that employers paid more for C# programmers, and it seems that C#
> became the
> darling of the ASP.Net crowd.
And before ASP.Net, it was ASP. Employers paid a lot more (and still do)
for ASP. The problem is a sizeable percentage of the ASP crowd were rats
jumping off of a sinking ship - all of the static HTMLers realizing their
pond was shrinking and they'd better jump...fast. Think about
non-programmers
writing ASP + client-side JScript. Fortunately, a measure of competency
became a requirement and started to turn the tide.
> In the meantime, I have observed an interesting phenomenon. Originally,
> employers hired programmers who used C# because it was based on C, and
> the
> prevailing opinion was (and may still be) that C# developers were
> better
> because they must have known and/or practiced C or C++ at some time,
> which
> would make them better programmers overall. C and C++ are hard-core
> programming languages compared to VB. > However, now that nearly everyone has jumped on the C# bandwagon, it
> seems
> to me that the distinction between the languages has nearly
> disappeared, at
> least in terms of evaluating programmers for hire. There seem to be
> almost
> as many clueless C# developers out there as VB.Net developers. Many C#
> developers today are basically VB.Net developers using a different
> syntax. I
> wonder if the employers have become aware of this trend?


At the risk of sounding rude, how is this the demise of c#?

Nov 19 '05 #86
It seems to me after reading some of these posts that this is just an
argument over personal preferences. I think its great that .NET offers both
VB.NET and C# and I feel that everyone has their own personal reasons for
picking their language. I have done programming in C++, Java, ASP, VbSCript,
JavaScript, Python, TCL, and others... however when I moved to use .NET i
chose C# simply because it was closer to C++ and Java. I found the syntax of
VB.NET to be too much of a blur of different languages, and I would start to
confuse syntax when working in different environments, as I still support old
VB6 and asp apps.

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

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

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

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

"cmay" wrote:
Funny... I don't really see a need for C# :)

There are a few things that C# can do that VB.NET can't, and there are
things that VB.Net does that C# can't do without added in a bunch of VB.NET
references. But the reason for the very few things that VB.NET can't do
isn't any limitation of the language. What I mean by that is, MS could, if
they wanted to, add all the extra stuff C# does to vb.net if they cared to do
so. There isn't anything really holding them back from doing that. In fact!
C# is starting to get a lot of the nice features of VB.NET, such as "With"
blocks.

Now, I'll be clear that I use both VB.NET and C#, but I clearly prefer
VB.NET, save a few things that bug me.

My 2 major annoyances with VB.net, as compared to C# are:
1) XML Comments -- I have the XML comments add-in, but it doesn't tie into
the intellisense. It would be nice if my comments showed up in my own
intellisense function calls in vb.net just like they do in C#.
2) The "Dumbifying" of terms. "MustInherit", "Shared" etc. A standard
question for all interviewers who program in vb.net should be "what is an
abstract class?" If you have to explain that "abstract" means "MustInherit"
then you know what kind of programmer you are dealing with.

Now, I think you would be hard pressed to prove that you can develop as fast
in C# as you can in VB.Net. The intellisense and error catching is so much
better in VB.NET (Im referring to the VS ide).

Either way, I agree the 2 will be moving closer to one another, but you have
to wonder: with the technical reasons for using C# all but gone, why would
new programmers choose C# (new, meaning they aren't coming from years of C++
of java development)?

Better question: Is there any (quality) vb.net programmer out there who
can't read/write C#? Maybe not as fast, but everything is so similar...

"Alvin Bruney" wrote:
I believe they did. (can of worms here)

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

--
Regards
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
--------------------------------------------------
"Steve C. Orr [MVP, MCSD]" <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.
>>
>>
>
>


Nov 19 '05 #87
coz
I have to agree with Steve here, though he probably wouldn't go as far as
me... I have hired many web developers, and have experienced much more
difficulty with 20 year C/C++ programmers who have been doing Internet
development for a few years, than relatively new programmers that just have a
few years experience with ASP/VBscript/VB/COM (and now with .net).

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

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

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

function msgbox(message, closeEvent) {
document.msgWin = window.open('blank.htm','width=400,height=300);
setTimeout(1000, 'msgboxReady("' + message + '", ' + closeEvent + ')');
}
function msgReady(message, closeEvent) {
if (document.msgWin) {
if (document.msgWin.readyState) {
document.msgWin.document.opener = document;
document.msgWin.document.open();
document.msgWin.document.title = '<% = sTitle %>';
document.msgWin.document.write('<p class=message>' +
unescape(message) + '</p><button onclick="window.close()">Close</button>');
document.msgWin.document.attachEvent('onclose', eval('opener.' +
closeEvent));
} else {
setTimeout(1000, 'msgboxReady("' + unescape(message) + '", ' +
closeEvent + ')');
}
} else {
alert('Error! Please contact <% = Application.Settings("AdminEmail") %>
if this problem continues');
}
}
</script>

Unfortunately, there are times you have to fix someone else's code that
looks like this (don't try and run that, I just typed it as an example of
code I have had to debug.) A web programmer has to have a good instinct to
know where each piece of that code is executing in order to decipher and
debug. Of course there are many exceptions (like, umm.. the C/C++ programmers
that built the technology probably have it down pretty good) but within MY
little corner of the web, the unfortunate reality is that we are simple
hiring more 5 year web-grown, ASP programmers than 25 year C/C++ veterans -
even if they say they have 5 years of web programming. This isn't a rule of
course - we give them all an equal chance at an interview - it just seems
like we don't hire them as much in the end.

"Kevin Spencer" wrote:
Oh, I agree, Steve. There are plenty of good VB developers out there (such
as yourself!).

I also agree that a solid understanding of HTML, HTTP, and the web are very
important to ASP.Net (critically important, actually).
> But my
experience tells me you don't need to be from C land to be a solid
developer.


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


I've always agreed with that point!

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

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

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

--
HTH,

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

"Steve C. Orr [MVP, MCSD]" <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.



Nov 19 '05 #88
About productivity, I did heard from some people writing in VB.NET that
writing in VB.NET is faster, on the other hand, I've heard from people
writing in C# (and I think so myself), that writing C# code is more
error-prone and "developable", of course, if written right (well, only VB.NET
code which is written right, is written fast).

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

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

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

"cmay" wrote:

I have run across a few hills that were too steep to climb. Oops.
Correction. I have run a across a few hills that I could not climb.

They
weren't too steep for everyyone to climb. How would I know that? All

I know
is, I couldn't climb them. On the other hand, I don't live near any

hills,
and climbing hills is not a good thing to do. So it really doesn't

matter.
This sounds like a good argument. So you are saying that since the
vast majority of .net developers don't use C#'s unmanaged code ability,
it doesn't really matter right?

Okay, so how do you edit and continue using the command-line

compiler? How
do you edit and continue while debugging a VB.Net file you're

composing in
Notepad? And how does Edit and Continue make your app run better? Or
perhaps, just maybe, this may be part of the "language module" that

has
nothing to do with the language, but the IDE?

Why do you get so angry when people talk about real world examples?
How many people write their C# apps in Notepad? I can understand that
you are not happy that VS.net gives VB developers some nice features
that C# developers don't have, but come on, VS.NET is the development
tool most people use. Can't I apply your earlier argument again: I
always write my code w/ VS.net, so it doesn't really matter.

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


See MY last point.

Okay, let's for the sake of argument assume that you have pointed up

a few
things you can do with VB.Net that you can't with C# (only for the

sake of
argument). How many of these things can you not do without? How many

of
these things affect the performance of your app? Answer: none.


Just to prove I am not mean spirted or trolling, I will absolutely
concede this point. The things I list as VB.NET "HAVES" are nothing
that are going to make a development team say "For this project we HAVE
to use VB, we can't use C#".

On the other
hand, let's say you want to write a custom image filter, to do

blurring, or
sharpness, or contrast. And you're writing with VB.Net. No pointers.

Now,
you're processing a 600X800 image. How long will it take to process

the
whole image? Well, from personal experience I can tell you that it is

an
order of magnitude slower to do without pointers. We're talking

hundreds of
times slower.


Actually, if it were an order of magnitude faster, it would be only be
10 +/- times faster. 100 times faster is 2 orders of magnitude. :)

In fact, you could not sell such an app. The competition would
kill it.


Yes, I agree. However, let me ask a few questions: If this app was so
performance intensive, why not write the whole product in unmanaged
code? Q2: How would your C# app perform against an app written in 95%
VB.NET, w/ 5% written in C# to do the unmanaged code? I'm guessing
pretty similar.
So, in terms of real value (as compared with trivial conveniences),

there is
nothing that VB offers that C# doesn't.


There is 1 difference that is not trivial, and that is productivity. I
know you argued that this was not due to VB.Net, but in fact was simply
a feature of VS. From an analitical standpoint, this may be right
(although the previous poster seemed pretty sure it was due to things
within the language module, but I don't know about that so I won't
pretend to) in practice you can develop many applications faster in
VB.net than C#. Part of the intellisense benefits of VB.NET simply
cannot be implemented in C# because of how ECMA script works. VB puts
the type after "As" so the IDE knows to provide you with intellisense.
This can't work the same in C# because you declare the type first.
Now, you are talking about real value vs trivial conveniences... How
about "this web application will take 100 days in VB.Net, or 130 days
in C#", or "to complete this project in time we need 3 VB.net
developers, or 4 C# developers". That is real value. I know you will
say that I am simply not good enough in C# and that is the only reason
why I feel vb.net is quicker to develop in, but I won't agree with that
argument.

The amount of time that the VS.Net IDE saves a developer who chooses VB
is something to be seriously considered. Is this added productivity
due to VBs use of "Dim"? No, of course not, and if I had to use
notepad and command line compiler (which I have done), I would not
suggest that VB is still more productive. But as long as I am working
in VS.Net, my choice to write as much code in VB.net will result in
more productivity.

Nov 19 '05 #89
Well, as Jimi Hendrix once said, you can't believe everything you see and
hear, can you?

--
;-),

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

"Kaerber" <Ka*****@discussions.microsoft.com> wrote in message
news:E9**********************************@microsof t.com...
About productivity, I did heard from some people writing in VB.NET that
writing in VB.NET is faster, on the other hand, I've heard from people
writing in C# (and I think so myself), that writing C# code is more
error-prone and "developable", of course, if written right (well, only
VB.NET
code which is written right, is written fast).

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

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

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

"cmay" wrote:

> I have run across a few hills that were too steep to climb. Oops.
> Correction. I have run a across a few hills that I could not climb.

They
> weren't too steep for everyyone to climb. How would I know that? All

I know
> is, I couldn't climb them. On the other hand, I don't live near any

hills,
> and climbing hills is not a good thing to do. So it really doesn't

matter.
This sounds like a good argument. So you are saying that since the
vast majority of .net developers don't use C#'s unmanaged code ability,
it doesn't really matter right?

> Okay, so how do you edit and continue using the command-line

compiler? How
> do you edit and continue while debugging a VB.Net file you're

composing in
> Notepad? And how does Edit and Continue make your app run better? Or
> perhaps, just maybe, this may be part of the "language module" that

has
> nothing to do with the language, but the IDE?

Why do you get so angry when people talk about real world examples?
How many people write their C# apps in Notepad? I can understand that
you are not happy that VS.net gives VB developers some nice features
that C# developers don't have, but come on, VS.NET is the development
tool most people use. Can't I apply your earlier argument again: I
always write my code w/ VS.net, so it doesn't really matter.

>
> > ok so the ide displays the intellisense BUT it is entirely based on
> > information that comes from the langauge module
> > see last point.
>
> See MY last point.
>
> Okay, let's for the sake of argument assume that you have pointed up

a few
> things you can do with VB.Net that you can't with C# (only for the

sake of
> argument). How many of these things can you not do without? How many

of
> these things affect the performance of your app? Answer: none.


Just to prove I am not mean spirted or trolling, I will absolutely
concede this point. The things I list as VB.NET "HAVES" are nothing
that are going to make a development team say "For this project we HAVE
to use VB, we can't use C#".

> On the other
> hand, let's say you want to write a custom image filter, to do

blurring, or
> sharpness, or contrast. And you're writing with VB.Net. No pointers.

Now,
> you're processing a 600X800 image. How long will it take to process

the
> whole image? Well, from personal experience I can tell you that it is

an
> order of magnitude slower to do without pointers. We're talking

hundreds of
> times slower.


Actually, if it were an order of magnitude faster, it would be only be
10 +/- times faster. 100 times faster is 2 orders of magnitude. :)

In fact, you could not sell such an app. The competition would
> kill it.
>


Yes, I agree. However, let me ask a few questions: If this app was so
performance intensive, why not write the whole product in unmanaged
code? Q2: How would your C# app perform against an app written in 95%
VB.NET, w/ 5% written in C# to do the unmanaged code? I'm guessing
pretty similar.
> So, in terms of real value (as compared with trivial conveniences),

there is
> nothing that VB offers that C# doesn't.


There is 1 difference that is not trivial, and that is productivity. I
know you argued that this was not due to VB.Net, but in fact was simply
a feature of VS. From an analitical standpoint, this may be right
(although the previous poster seemed pretty sure it was due to things
within the language module, but I don't know about that so I won't
pretend to) in practice you can develop many applications faster in
VB.net than C#. Part of the intellisense benefits of VB.NET simply
cannot be implemented in C# because of how ECMA script works. VB puts
the type after "As" so the IDE knows to provide you with intellisense.
This can't work the same in C# because you declare the type first.
Now, you are talking about real value vs trivial conveniences... How
about "this web application will take 100 days in VB.Net, or 130 days
in C#", or "to complete this project in time we need 3 VB.net
developers, or 4 C# developers". That is real value. I know you will
say that I am simply not good enough in C# and that is the only reason
why I feel vb.net is quicker to develop in, but I won't agree with that
argument.

The amount of time that the VS.Net IDE saves a developer who chooses VB
is something to be seriously considered. Is this added productivity
due to VBs use of "Dim"? No, of course not, and if I had to use
notepad and command line compiler (which I have done), I would not
suggest that VB is still more productive. But as long as I am working
in VS.Net, my choice to write as much code in VB.net will result in
more productivity.

Nov 19 '05 #90
While this maybe true Kevin, I wonder how many of those clueless employers
are converting applications to C# because they think that it runs faster then
VB.Net.

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

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

They alone are the sole reason why some snot nosed punk fresh out of college
who is willing to except the lowest of wages are getting jobs and they alone
perpetuate the growing band of clueless developers, whilst winging how they
don’t see value for money and how their poorly specified projects are
delivered late and full of bugs.
"Kevin Spencer" wrote:
About 2 years ago, and as recently as perhaps 1 year ago, I can recall
seeing many posts about what language to use with ASP.Net. The consensus was
that employers paid more for C# programmers, and it seems that C# became the
darling of the ASP.Net crowd.

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

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

--

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

Nov 19 '05 #91
Hi Brennon,

I agree with ALMOST everything you said, except for one thing:
The real problem exists where employers think that just because someone
has
a degree that they will be programming genius.
While I certainly agree that this is a big problem, I can't agree that it is
THE "real" problem. It certainly is one of them!

--
HTH,

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

"Brennon Williams" <Brennon Wi******@discussions.microsoft.com> wrote in
message news:7A**********************************@microsof t.com... While this maybe true Kevin, I wonder how many of those clueless employers
are converting applications to C# because they think that it runs faster
then
VB.Net.

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

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

They alone are the sole reason why some snot nosed punk fresh out of
college
who is willing to except the lowest of wages are getting jobs and they
alone
perpetuate the growing band of clueless developers, whilst winging how
they
don't see value for money and how their poorly specified projects are
delivered late and full of bugs.
"Kevin Spencer" wrote:
About 2 years ago, and as recently as perhaps 1 year ago, I can recall
seeing many posts about what language to use with ASP.Net. The consensus
was
that employers paid more for C# programmers, and it seems that C# became
the
darling of the ASP.Net crowd.

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

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

--

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

Nov 19 '05 #92
Leaving aside the fact that not everything is a web application, there are at
least 2 questionable assumptions in this:
1) That all C# developers are recycled C/C++ developers. Some in fact (such
as myself, although I had worked with C and with another c-word language that
I won't mention...and even BCPL) are ex-VB/VB Script/ASP developers (and no,
I don't write VB6 code in C# syntax, although I understand how someone might,
and have cleaned up after someone who has). Some are Java developers that
we've brought over to the Dark Side.
2) That ASP/VB Script is necessarily a good background for ASP.NET.
While *any* web experience is useful (otherwise I spend a lot of time
explaining to even very bright people what happens on the server and what
happens in the browser), do we actually want ASP.NET to be written the way a
lot of people wrote ASP? If I'm shortlisting candidates these days I'll quite
happily give equal weight to ASP *and* JSP experience - I might even favour
the latter slightly.

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

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

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

--

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

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

Nov 19 '05 #94
Excellent points all, Frank! I couldn't agree more on all aspects of your
message. When I posted the original "spark" to this thread, it was due to an
observation I had made regarding hiring practices and trends. I had made the
same observations privately that you have, and hoped that by sparking some
discussion of it, we might all benefit from the discussion in one way or
another.

--
HTH,

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

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

Nov 19 '05 #95
This morning brought a distant memory to me. I had a mentor who once observed
that talent was the best reason to hire a person, but the hardest quality to
judge. This reminded me indirectly that everything I know that has been of
value was passed onto me by mentors, and made me wonder if maybe as a group
we have a problem in that we no longer take on the responsibility of
apprentices. Perhaps if we did, we could shape the process for hiring to
reflect the idea of quality and encompass the judgement that extends from
experience.

"Kevin Spencer" wrote:
Excellent points all, Frank! I couldn't agree more on all aspects of your
message. When I posted the original "spark" to this thread, it was due to an
observation I had made regarding hiring practices and trends. I had made the
same observations privately that you have, and hoped that by sparking some
discussion of it, we might all benefit from the discussion in one way or
another.

--
HTH,

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

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


Nov 19 '05 #96
Well, Frank, I consider these newsgroups as a sort of opportunity to do just
that. However, a good team leader should be a personal mentor, absolutely,
as part of his/her job.

--
HTH,

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

"Frank Buchan" <Fr*********@discussions.microsoft.com> wrote in message
news:35**********************************@microsof t.com...
This morning brought a distant memory to me. I had a mentor who once
observed
that talent was the best reason to hire a person, but the hardest quality
to
judge. This reminded me indirectly that everything I know that has been of
value was passed onto me by mentors, and made me wonder if maybe as a
group
we have a problem in that we no longer take on the responsibility of
apprentices. Perhaps if we did, we could shape the process for hiring to
reflect the idea of quality and encompass the judgement that extends from
experience.

"Kevin Spencer" wrote:
Excellent points all, Frank! I couldn't agree more on all aspects of your
message. When I posted the original "spark" to this thread, it was due to
an
observation I had made regarding hiring practices and trends. I had made
the
same observations privately that you have, and hoped that by sparking
some
discussion of it, we might all benefit from the discussion in one way or
another.

--
HTH,

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

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


Nov 19 '05 #97
Such a good thread well done Mr Spencer!

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

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


Nov 19 '05 #98


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


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

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

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

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

My 2 cents...
Nov 19 '05 #99
> I tend to see it as a difference between VB6 and .net, rather than VB6 and
C#. The reason, is that even by using VB.Net, I would have locked myself
out
from all the "unproper" features, such as Option Explicit Off, Option
Strict
Off etc etc...
This part I don't understand. By default Option Explicit is turned ON in
VB.Net, and it's a simple matter to turn Option Strict ON as well...

--
HTH,

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

"Dimitris Kavakopoulos" <Dimitris Ka**********@discussions.microsoft.com>
wrote in message news:1A**********************************@microsof t.com...

"Peter Rilling" wrote:
I came from a VB development background and moved to C# about five years
ago.

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


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

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

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

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

My 2 cents...

Nov 19 '05 #100

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

42
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...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shllpp 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 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 former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.