Re: What I don't like about C# so far, compared to C++ (managed or otherwise)
- From: DeveloperX <nntpDev@xxxxxxxxxxxxx>
- Date: Wed, 01 Aug 2007 15:25:54 -0700
On 1 Aug, 14:58, "Larry Smith" <no_spam@xxxxxxxxxxx> wrote:
I think it's interesting that you think that. I don't strictly
disagree, and with the amount of P/invoke questions in this forum
alone this is probably a valid point. But given the points the OP
tried to make at the beginning I think we can see other areas that
mean a C++ programmer is not necessarily going to make a totally clean
transition. "Where are my pointers!!! Waaa!!!" being an example of a
fundamental conflict in mind sets.
Seasoned C++ professionals won't cry over the lack of pointers. They might
(rightfully) point out weaknesses such as a lack of "const"
references/functions, no covariant return types (though MSFT has hinted it
might remedy this), etc., but a real professional will try to put his biases
aside. There are certainly things that C++ could learn from C# as well IMO.
Nevertheless, C++ programmers will move to C# much easier than anyone else.
This is based on my own experience and those of many others I've talked to.
It just makes sense given that C# is already syntactically very close to C++
(obviously its progenitor). Combine that with the (vastly) superior
knowledge of Windows itself and C++ programmers have a significant advantage
over all other programmers.
I could make the point that a good VB6 developer will already be
pointer free, will be quite comfortable with p/invoke as he's probably
been doing it since day 2,
Absolutely not. A VB programmer's exposure to the WinAPI is almost
non-existent. The WinAPI is in C itself so C/C++ programmers are in the best
position to deal with P/Invoke issues.
Ultimately, as long as the developer is capable I don't care what
their background is.
While many C++ programmers are arrogant about the skills of VB developers
(frequently malicious in fact), it is generally true that VB programmers are
weaker than C++ programmers (in my long experience). While you and others
might disagree with this, IMO you'll improve your odds of finding a more
skilled and talented programmer in the C++ pool (certainly much more
knowledgeable about Windows itself)
Well, I don't want to keep this thread alive longer than necessary, in
fact I've booked the abattoir and there will be a remembrance service
shortly.
My experience differs from yours. C++ developers I've worked with have
generally worked server side or in quant type positions. I've only
worked with one team who actively developed GUI's in C++ and it was a
nightmare. Partly down to the technology, mainly down to their severe
incompetence. Server side code was always about speed and looked
pretty much like C in wolves' clothing. OO was a smiley denoting their
blank eyed expressions rather than our anything oriented around
objects.
On the VB side, I've worked with developers working mainly on GUI's,
but also server side code and also similar quant type stuff.
On the GUI side the amount of knowledge you need to be a good GUI
developer in VB, to bypass the bottlenecks and restrictions VB imposed
required a significant understanding of what Windows was doing. I also
wasted lots of time interviewing alleged "programmers" with a VB
background who had actually just figured out that you could make
buttons... So in a way you're right, there's a high noise to sound
ratio with VB programmers, but that's no reason to dismiss them.
Both groups, and I make them distinct groups purely for this
discussion, had strong and weak members. I'm talking only about those
I've worked with/employed here, not the noise.
If I wanted a GUI developer or ASP developer to work in C# I would not
immediately look for C++ on their CV. I'd be after GUI oriented or web
based experience respectively. If I wanted a server guy I'd be looking
for that sort of related experience. In both cases I'd be open to
anyone who appeared to demonstrate skill and an ability to learn
regardless of their background, but also an understanding of the
technology they'll be using. So C# developers will need to show they
understand C# and the "modernity" that comes with it.
Then there's the question of business knowledge, related skills (SQL
as an example). That's just two for the trifecta.
I do understand where you're coming from, but spotting wheat in the
chaff is not directly related to previous language experience unless
you can almost directly map it to your current new world requirements
and don't need to engage your potential employee outside of that box.
.
- References:
- What I don't like about C# so far, compared to C++ (managed or otherwise)
- From: raylopez99
- Re: What I don't like about C# so far, compared to C++ (managed or otherwise)
- From: Jon Skeet [C# MVP]
- Re: What I don't like about C# so far, compared to C++ (managed or otherwise)
- From: Larry Smith
- Re: What I don't like about C# so far, compared to C++ (managed or otherwise)
- From: Larry Smith
- Re: What I don't like about C# so far, compared to C++ (managed or otherwise)
- From: DeveloperX
- Re: What I don't like about C# so far, compared to C++ (managed or otherwise)
- From: Larry Smith
- What I don't like about C# so far, compared to C++ (managed or otherwise)
- Prev by Date: Re: Pass by reference vs Pass by Value (is 'data aliasing' a problem in C#?)
- Next by Date: SSL BIND
- Previous by thread: Re: What I don't like about C# so far, compared to C++ (managed or otherwise)
- Next by thread: Re: What I don't like about C# so far, compared to C++ (managed or otherwise)
- Index(es):
Relevant Pages
|
