I am working with a .NET development team and I am looking for reasons,
that I can present to management, as to why we should develop our
software using C# rather than VB.NET.
49  1804 
This has been asked & answered thousands of times in various places.
There is no clear reason to prefer ANY .NET language over another.
It comes down to preference. In a corporate environment, the language
decision usually gets made based on the esiting skill sets that are already
in-house. Java and C/C++ developers are going to have a bit of an easier
time going to C#, because the language syntax is very similiar. VB 6.0
developers and those with little or no programming experience might prefer
going to VB.NET.
All .NET languages work off of a Common Language Specification and a Common
Type System. They all compile to the same Intermediate Language and the all
have (more or less) the same performance and capabilities.
-Scott
"Emmett" <eo********@eircom.netwrote in message
news:11*********************@s13g2000cwa.googlegro ups.com...
>I am working with a .NET development team and I am looking for reasons,
that I can present to management, as to why we should develop our
software using C# rather than VB.NET.
Emmett wrote:
I am working with a .NET development team and I am looking for reasons,
that I can present to management, as to why we should develop our
software using C# rather than VB.NET.
Hi Emmett,
Do you like coding in C#, or do you like coding in VB .NET?
Choose the one you like. It makes no difference. :-)
--
Hope this helps,
Tom Spink
Google first, ask later.
Just curious though...Why do you *want* to talk management into C#?
"Scott M." <s-***@nospam.nospamwrote in message
news:eR**************@TK2MSFTNGP03.phx.gbl...
This has been asked & answered thousands of times in various places.
There is no clear reason to prefer ANY .NET language over another.
It comes down to preference. In a corporate environment, the language
decision usually gets made based on the esiting skill sets that are
already in-house. Java and C/C++ developers are going to have a bit of an
easier time going to C#, because the language syntax is very similiar. VB
6.0 developers and those with little or no programming experience might
prefer going to VB.NET.
All .NET languages work off of a Common Language Specification and a
Common Type System. They all compile to the same Intermediate Language
and the all have (more or less) the same performance and capabilities.
-Scott
"Emmett" <eo********@eircom.netwrote in message
news:11*********************@s13g2000cwa.googlegro ups.com...
>>I am working with a .NET development team and I am looking for reasons,
that I can present to management, as to why we should develop our
software using C# rather than VB.NET.
Exactly Scott, what does management to do with what programming language to
use. The software architect should.Yet, if the software architect does not
know about why C# and VB.NET I bet you really can ask the management to fire
him/her.
chanmm
"Scott M." <s-***@nospam.nospamwrote in message
news:Oc**************@TK2MSFTNGP05.phx.gbl...
Just curious though...Why do you *want* to talk management into C#?
"Scott M." <s-***@nospam.nospamwrote in message
news:eR**************@TK2MSFTNGP03.phx.gbl...
>This has been asked & answered thousands of times in various places.
There is no clear reason to prefer ANY .NET language over another.
It comes down to preference. In a corporate environment, the language
decision usually gets made based on the esiting skill sets that are
already in-house. Java and C/C++ developers are going to have a bit of
an easier time going to C#, because the language syntax is very similiar.
VB 6.0 developers and those with little or no programming experience
might prefer going to VB.NET.
All .NET languages work off of a Common Language Specification and a
Common Type System. They all compile to the same Intermediate Language
and the all have (more or less) the same performance and capabilities.
-Scott
"Emmett" <eo********@eircom.netwrote in message
news:11*********************@s13g2000cwa.googlegr oups.com...
>>>I am working with a .NET development team and I am looking for reasons,
that I can present to management, as to why we should develop our
software using C# rather than VB.NET.
as far as I know they are similiar in output <in sysntax. I have been
working on VB my whole life and starting with vb.net 2003 there is nothing
related to windows that I could not achieve....
If no previous exprience in C, I would recommend VB.NET becuase it is so
much easy to learn and Microsoft is commited to it, so do nt be afraid to go
for it.
"Emmett" wrote:
I am working with a .NET development team and I am looking for reasons,
that I can present to management, as to why we should develop our
software using C# rather than VB.NET.
True, but not really my point. The OP said he *wanted* to present to
management reasont to use C# over VB.NET. Sounds like the OP has some
reason in mind for this. I was interested to know what it was.
As for management being involved. I can see a few factors that are
managerial and not technical for choosing a programming language....
Cost to train developers in a new programming language and loss of
productivity while they are in training and get ramped up.
Ditto for developer support personnel.
Also, if current developers and support people have to have a new language
in their skill set, it not only means getting those people trained, but it
means that future people hired for those positions will need to have skills
in more than one programming language. That could mean that these positions
must pay more than they may pay now.
But I do agree that management doesn't see things from a technical point of
view, the see things from a "bottom line" point of view.
"chanmm" <ch*****@hotmail.comwrote in message
news:Od**************@TK2MSFTNGP05.phx.gbl...
Exactly Scott, what does management to do with what programming language
to use. The software architect should.Yet, if the software architect does
not know about why C# and VB.NET I bet you really can ask the management
to fire him/her.
chanmm
"Scott M." <s-***@nospam.nospamwrote in message
news:Oc**************@TK2MSFTNGP05.phx.gbl...
>Just curious though...Why do you *want* to talk management into C#?
"Scott M." <s-***@nospam.nospamwrote in message
news:eR**************@TK2MSFTNGP03.phx.gbl...
>>This has been asked & answered thousands of times in various places.
There is no clear reason to prefer ANY .NET language over another.
It comes down to preference. In a corporate environment, the language
decision usually gets made based on the esiting skill sets that are
already in-house. Java and C/C++ developers are going to have a bit of
an easier time going to C#, because the language syntax is very
similiar. VB 6.0 developers and those with little or no programming
experience might prefer going to VB.NET.
All .NET languages work off of a Common Language Specification and a
Common Type System. They all compile to the same Intermediate Language
and the all have (more or less) the same performance and capabilities.
-Scott
"Emmett" <eo********@eircom.netwrote in message
news:11*********************@s13g2000cwa.googleg roups.com...
I am working with a .NET development team and I am looking for reasons,
that I can present to management, as to why we should develop our
software using C# rather than VB.NET.
But, let's just be clear and impartial here....
as far as I know they are similiar in output <in sysntax.
This only applies when you are talking about ASP.NET. For client and
componenet development, this statement doesn't have any meaning.
I have been working on VB my whole life and starting with vb.net 2003
there is nothing
related to windows that I could not achieve....
If no previous exprience in C, I would recommend VB.NET becuase it is so
much easy to learn
Well, I happen to personally agree with you, but there are those that
disagree and think that VB.NET is too verbose and cumbersome. There are
many that believe that C# is more "elegant" and simple. Remember, you did
say that you've worked with VB for quite a while, so you are biased towards
it. I am too :).
and Microsoft is commited to it, so do nt be afraid to go for it.
Microsoft is committed to C# as well. In fact, many of the major changes to
the VB lanaguage you are now learning in VB.NET have to do with making VB
more C/C#/Java - like. That is one feather in the cap of knowing C#. The
syntax is very similar to C amd Java. Can't say that for VB.NET.
>
"Emmett" wrote:
>I am working with a .NET development team and I am looking for reasons,
that I can present to management, as to why we should develop our
software using C# rather than VB.NET.
Scott M. <s-***@nospam.nospamwrote:
I have been working on VB my whole life and starting with vb.net 2003
there is nothing
related to windows that I could not achieve....
If no previous exprience in C, I would recommend VB.NET becuase it is so
much easy to learn
Well, I happen to personally agree with you, but there are those that
disagree and think that VB.NET is too verbose and cumbersome. There are
many that believe that C# is more "elegant" and simple. Remember, you did
say that you've worked with VB for quite a while, so you are biased towards
it. I am too :).
I would say that it's not the verbosity of VB.NET which in my view
makes it harder to learn than C# - it's all the "extras" which are part
of it: the odd nature of Nothing when applied to String (where Is and =
do different things for legacy reasons); the way that you can call
static methods as if they were instance methods; the numerous functions
which are mostly there for backwards compatibility, but which you'll
need to have a grip on if you're going to read other people's code
(etc).
C# had a definite advantage in being a new language. It has a few
things left over from C which I'm not too happy with (particularly
regarding switch) but mostly it was able to form a clean break with the
past.
It also doesn't help that VB.NET uses different terminology to what
most other languages use for various things (Nothing instead of null,
shared instead of static, MustInherit instead of abstract, etc). You
need to know the VB.NET terminology in order to write VB.NET, but you
need to know the .NET terminology in order to communicate with anyone
who doesn't use VB.NET.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Well, as others have pointed out, it's a matter of preference. Some things
to consider:
- C# was built from the ground up to be a modern .NET language. VB.NET,
while a completely new language, has some leftover baggage from VB.
- C# has had more involvment with standards comittees than VB.NET. This
could suggest that C# will be a more stable language.
- C# is closer to C/C++. <g>
Perhaps others have more items they can add.
Then you might ask a similar question about VB.NET in the VB.NET groups.
That's probably the most objective approach.
--
Jonathan Wood
SoftCircuits Programming http://www.softcircuits.com
"Emmett" <eo********@eircom.netwrote in message
news:11*********************@s13g2000cwa.googlegro ups.com...
>I am working with a .NET development team and I am looking for reasons,
that I can present to management, as to why we should develop our
software using C# rather than VB.NET.
Agreed. But, with regard to:
"the way that you can call static methods as if they were instance methods"
We would make these static (shared in VB.NET) inside of a sealed
(NotInheritable with a Private constructor) class to avoid this problem.
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Scott M. <s-***@nospam.nospamwrote:
I have been working on VB my whole life and starting with vb.net 2003
there is nothing
related to windows that I could not achieve....
If no previous exprience in C, I would recommend VB.NET becuase it is
so
much easy to learn
Well, I happen to personally agree with you, but there are those that
disagree and think that VB.NET is too verbose and cumbersome. There are
many that believe that C# is more "elegant" and simple. Remember, you
did
say that you've worked with VB for quite a while, so you are biased
towards
it. I am too :).
I would say that it's not the verbosity of VB.NET which in my view
makes it harder to learn than C# - it's all the "extras" which are part
of it: the odd nature of Nothing when applied to String (where Is and =
do different things for legacy reasons); the way that you can call
static methods as if they were instance methods; the numerous functions
which are mostly there for backwards compatibility, but which you'll
need to have a grip on if you're going to read other people's code
(etc).
C# had a definite advantage in being a new language. It has a few
things left over from C which I'm not too happy with (particularly
regarding switch) but mostly it was able to form a clean break with the
past.
It also doesn't help that VB.NET uses different terminology to what
most other languages use for various things (Nothing instead of null,
shared instead of static, MustInherit instead of abstract, etc). You
need to know the VB.NET terminology in order to write VB.NET, but you
need to know the .NET terminology in order to communicate with anyone
who doesn't use VB.NET.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
No body has to use old constructs of VB. However, they are there for
compatibilty....Remmeber that all .NET are compiled into CLR, so there is no
differene at the end.
"Jonathan Wood" wrote:
Well, as others have pointed out, it's a matter of preference. Some things
to consider:
- C# was built from the ground up to be a modern .NET language. VB.NET,
while a completely new language, has some leftover baggage from VB.
- C# has had more involvment with standards comittees than VB.NET. This
could suggest that C# will be a more stable language.
- C# is closer to C/C++. <g>
Perhaps others have more items they can add.
Then you might ask a similar question about VB.NET in the VB.NET groups.
That's probably the most objective approach.
--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
"Emmett" <eo********@eircom.netwrote in message
news:11*********************@s13g2000cwa.googlegro ups.com...
I am working with a .NET development team and I am looking for reasons,
that I can present to management, as to why we should develop our
software using C# rather than VB.NET.
No body has to use old constructs of VB. However, they are there for
compatibilty....Remmeber that all .NET are compiled into CLR, so there is
no
differene at the end.
The fact remains that VB.NET has some degree of baggage left over from VB. I
know first hand because I was involved up at Microsoft in discussions with
the developers on how VB.NET could be more compatible with VB. And this
includes constructs that are virtually unavoidable (for example, logical and
bitwise operators, etc).
I know it's all the same in the end. But the OP was asking about comparing
the two, and the language makes a difference.
--
Jonathan Wood
SoftCircuits Programming http://www.softcircuits.com
The idea is VB is now as powerful as c# and Microsoft is as committed to it.
The only point that I find C# more powerful in it is the Mono project on
Linux.....Whatever is the case, I agree with you that it is a matter of
preference.
"Jonathan Wood" wrote:
No body has to use old constructs of VB. However, they are there for
compatibilty....Remmeber that all .NET are compiled into CLR, so there is
no
differene at the end.
The fact remains that VB.NET has some degree of baggage left over from VB. I
know first hand because I was involved up at Microsoft in discussions with
the developers on how VB.NET could be more compatible with VB. And this
includes constructs that are virtually unavoidable (for example, logical and
bitwise operators, etc).
I know it's all the same in the end. But the OP was asking about comparing
the two, and the language makes a difference.
--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
The only point that I find C# more powerful in it is the Mono project on
Linux.....
But that's not true .NET.
Scott M. wrote:
>The only point that I find C# more powerful in it is the Mono project on
Linux.....
But that's not true .NET.
The Mono project is fully CLI compliant. What's not true about it? In
fact, I use the Mono C# Compiler GMCS, because I don't own Windows or
VS .NET. I get to use the IDE at University, but my late-night coding is
done by the light of Debian and GMCS.
--
Hope this helps,
Tom Spink
Google first, ask later.
Scott M. <s-***@nospam.nospamwrote:
Agreed. But, with regard to:
"the way that you can call static methods as if they were instance methods"
We would make these static (shared in VB.NET) inside of a sealed
(NotInheritable with a Private constructor) class to avoid this
problem.
That doesn't solve the problem at all. For one thing, it doesn't do
anything about static methods which exist in other classes. For a
second thing, it severely limits your options - if you can't have any
static methods on classes where you *can* have an instance, you've
really limited yourself artificially.
I'm not sure we're talking about the same thing. I'm talking about the
ability to call Thread.Sleep "on" a different thread, even though it
ends up making the currently executing thread sleep. In C# you couldn't
do:
// Will not compile!
Thread t = new Thread (someThreadStart);
t.Start();
t.Sleep(1000); // Error! Thread.Sleep is static!
The equivalent VB.NET code would compile. Fortunately this is
(optionally) a warning in VS 2005, but I can't see the usefulness of it
being allowed at all - unless it's for legacy reasons.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
naraby <na****@discussions.microsoft.comwrote:
No body has to use old constructs of VB. However, they are there for
compatibilty....Remmeber that all .NET are compiled into CLR, so there is no
differene at the end.
You could use C# and never know how a "for" loop works, sticking only
to "while" loops - but you wouldn't know C#. Unless you're only ever
reading code that you've written yourself, you can't really work with
VB.NET (or claim to know it) without having at least a passing
knowledge of the "old constructs".
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
I meant that it is not what MS intended.
"Tom Spink" <ts****@gmail.comwrote in message
news:e3**************@TK2MSFTNGP05.phx.gbl...
Scott M. wrote:
>>The only point that I find C# more powerful in it is the Mono project on
Linux.....
But that's not true .NET.
The Mono project is fully CLI compliant. What's not true about it? In
fact, I use the Mono C# Compiler GMCS, because I don't own Windows or
VS .NET. I get to use the IDE at University, but my late-night coding is
done by the light of Debian and GMCS.
--
Hope this helps,
Tom Spink
Google first, ask later.
Emmett wrote:
I am working with a .NET development team and I am looking for reasons,
that I can present to management, as to why we should develop our
software using C# rather than VB.NET.
Because C# developers get paid more than VB.NET developers. Oh wait,
that's a *bad* thing to point out to management...
One thing has me confused though. You say you are working with "a .NET
development team" - so what are they using at the moment? Presumably
it's one or the other, so whatever you're using at the moment must have
been chosen initially for some reason. What was that reason? Have any
of the facts on which that decision was made changed? What is the
skillset of the developers in the team?
--
Larry Lard
Replies to group please
Following is an interesting article on the subject. http://www.cmswire.com/cms/featured-...cle-000591.php
Basically is says the VB.Net and C# are functionally equivalent now and
from a language standpoint there isn't much difference. The main
difference is the culture of the developers behind the language.
Basically VB developers are sloppy, less skilled and do not have good
design skills. The above is a long article but I found it very interesting.
Emmett wrote:
I am working with a .NET development team and I am looking for reasons,
that I can present to management, as to why we should develop our
software using C# rather than VB.NET.
Scott M. wrote:
I meant that it is not what MS intended.
"Tom Spink" <ts****@gmail.comwrote in message
news:e3**************@TK2MSFTNGP05.phx.gbl...
>Scott M. wrote:
>>>The only point that I find C# more powerful in it is the Mono project
on Linux.....
But that's not true .NET.
The Mono project is fully CLI compliant. What's not true about it? In
fact, I use the Mono C# Compiler GMCS, because I don't own Windows or
VS .NET. I get to use the IDE at University, but my late-night coding is
done by the light of Debian and GMCS.
--
Hope this helps,
Tom Spink
Google first, ask later.
Hi Alan,
On the contrary,
Have you heard of the Rotor project? A shared-source project by Microsoft
which has a fully compliant CLI and compiler? I've never looked at it
because it would violate the rules of me developing on the Mono project,
but it's an initiative by Microsoft to get developers interested in the
workings of the CLI and ultimately giving rise to the CLI being developed
for different platforms.
--
Hope this helps,
Tom Spink
Google first, ask later.
Leon Lambert wrote:
Basically VB developers are sloppy, less skilled and do not have good
design skills.
Thank you for insulting every VB developer on the planet. Until you
have examined the code of every VB programmer you cannot possibly
justify this statement. No matter what language you are talking about
there are good coders and bad coders.
Chris Dunaway <du******@gmail.comwrote:
Leon Lambert wrote:
>Basically VB developers are sloppy, less skilled and do not have good
design skills.
Thank you for insulting every VB developer on the planet. Until you
have examined the code of every VB programmer you cannot possibly
justify this statement. No matter what language you are talking about
there are good coders and bad coders.
Metaphorical generalizations will get your into political trouble every time.
The truth is irrellavent at that point.
--
Thomas T. Veldhouse
Key Fingerprint: 2DB9 813F F510 82C2 E1AE 34D0 D69D 1EDC D5EC AED1
Basically VB developers are sloppy, less skilled and do not have good
design skills.
A statement like that just tells us that you really don't have a clue as to
what is actually going on out in the real development community. I've seen
just as much bad and sloppy C# as I have VB.NET.
My point was that there is a way to separate static methods from instance
methods.
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Scott M. <s-***@nospam.nospamwrote:
>Agreed. But, with regard to:
"the way that you can call static methods as if they were instance
methods"
We would make these static (shared in VB.NET) inside of a sealed
(NotInheritable with a Private constructor) class to avoid this
problem.
That doesn't solve the problem at all. For one thing, it doesn't do
anything about static methods which exist in other classes. For a
second thing, it severely limits your options - if you can't have any
static methods on classes where you *can* have an instance, you've
really limited yourself artificially.
I'm not sure we're talking about the same thing. I'm talking about the
ability to call Thread.Sleep "on" a different thread, even though it
ends up making the currently executing thread sleep. In C# you couldn't
do:
// Will not compile!
Thread t = new Thread (someThreadStart);
t.Start();
t.Sleep(1000); // Error! Thread.Sleep is static!
The equivalent VB.NET code would compile. Fortunately this is
(optionally) a warning in VS 2005, but I can't see the usefulness of it
being allowed at all - unless it's for legacy reasons.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
"Tom Spink" <ts****@gmail.comwrote in message
news:eK**************@TK2MSFTNGP03.phx.gbl...
Choose the one you like. It makes no difference. :-)
Unless you need pointers / unmanaged code...
Scott M. <s-***@nospam.nospamwrote:
My point was that there is a way to separate static methods from instance
methods.
But that is entirely orthogonal to my point that VB.NET lets you write
confusing code for no reason other than (presumably) supporting legacy
code. I've seen plenty of people trying to make other threads sleep in
Java due to this exact same flaw (which fortunately many IDEs highlight
these days).
It's that kind of thing which I think I'd find confusing if I were
learning VB.NET and reading bad examples (which are everywhere, let's
face it).
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mark Rae wrote:
"Tom Spink" <ts****@gmail.comwrote in message
news:eK**************@TK2MSFTNGP03.phx.gbl...
>Choose the one you like. It makes no difference. :-)
Unless you need pointers / unmanaged code...
Hi Mark,
;-) I'll assume you meant "unsafe" code, not "unmanaged" code.
I was waiting for that comment. VB .NET is equally expressive as C#, minus
that feature, but it's not often that unsafe code is used in everyday
applications, and the chances are, if you're coming _from_ VB .NET, then
you'll have little use for pointers anyway.
--
Hope this helps,
Tom Spink
Google first, ask later.
Mark Rae <ma**@markNOSPAMrae.comwrote:
Choose the one you like. It makes no difference. :-)
Unless you need pointers / unmanaged code...
If you need unmanaged code, neither VB.NET nor C# will help you. C# has
unsafe code, but not unmanaged code.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
I guess he wrote VB, not VB.NET. The worst code the world has ever seen was
written in VB. And it's because VB was made so incredibly easy to learn that
every single idiot was able to learn the If Then Else syntax and work as a
contractor for some big venture delivering information systems and producing
code like you can see on thedailywtf.com. This is not true for languages
like C, which seem to attract much fewer idiots.
"Scott M." <s-***@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...
>Basically VB developers are sloppy, less skilled and do not have good
design skills.
A statement like that just tells us that you really don't have a clue as
to what is actually going on out in the real development community. I've
seen just as much bad and sloppy C# as I have VB.NET.
"Tom Spink" <ts****@gmail.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
;-) I'll assume you meant "unsafe" code, not "unmanaged" code.
LOL! Yes, you're quite right - my slightly drunken error... :-)
I was waiting for that comment. VB .NET is equally expressive as C#,
No question.
minus that feature, but it's not often that unsafe code is used in
everyday
applications, and the chances are, if you're coming _from_ VB .NET, then
you'll have little use for pointers anyway.
Agreed.
But that is entirely orthogonal to my point that VB.NET lets you write
confusing code for no reason other than (presumably) supporting legacy
code.
Didn't someone say, "confusing is in the eyes of the beholder"? LOL. I
just mean that, as all in this thread agree, what's confusing and
non-intuitive to some, is perfectly logical and intuitive to others. It
depends on what angle your coming from.
:)
Scott M. <s-***@nospam.nospamwrote:
But that is entirely orthogonal to my point that VB.NET lets you write
confusing code for no reason other than (presumably) supporting legacy
code.
Didn't someone say, "confusing is in the eyes of the beholder"? LOL. I
just mean that, as all in this thread agree, what's confusing and
non-intuitive to some, is perfectly logical and intuitive to others. It
depends on what angle your coming from.
:)
So who exactly is going to find it perfectly logical and intuitive that
if you appear to call Sleep on a specific thread, you actually make a
completely different thread (the current one) sleep? What is the
*possible* benefit in that?
Some things are indeed subjective, but we really shouldn't let that be
a catch-all excuse for things which just shouldn't be the way they are.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
I've worked extensively with both languages and functionally it doesn't
make a lick of difference one way or the other. C# has a few features
that you don't get in VB, mainly pertaining to the use of pointers and
"unmanaged" code which more or less manipulates memory directly.
You're probably not going to need to do it anyway.
Don't worry about the sale to management, they don't care what you use
one way or the other as long as they can get everything in
Excel/PowerPoint at the end of the day.
What you should do is discuss it with your team, discuss the merits and
pitfalls of working with either language and decide what you want to
use and tell management that you want to make the move to this language
or that because it's what your developers want to be working in.
As far as learning a new language goes, the important thing (and the
difficult thing) is learning the .NET framework and how to leverage it.
The languages themselves are easy. I think that VB.NET is more
different from VB6 than it is from C#. VB.NET even supports all the
same C/C++ operators now.
Also, there is no reason why you can't work in both languages as they
are completely interoperable. If you're working with VB.NET currently,
you could try a few small projects in C# and see how you like it. It
does take some getting used to coming from a VB background but
personally I prefer the C# syntax because it lets me write more concise
code, and because I like curly braces.
I've also worked on projects where both languages were employed. For
example a project where the ASP.NET page classes were written in VB.NET
and the middle tier and data access layers were done in C#.
"allfyre" <al*****@hotmail.comwrote in message
news:11**********************@m79g2000cwm.googlegr oups.com...
I've worked extensively with both languages and functionally it doesn't
make a lick of difference one way or the other. [...]
What you should do is discuss it with your team, discuss the merits and
pitfalls of working with either language
But what -are- the merits and pitfalls, especially if there's no functional
difference?
///ark
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Mark Rae <ma**@markNOSPAMrae.comwrote:
Choose the one you like. It makes no difference. :-)
Unless you need pointers / unmanaged code...
If you need unmanaged code, neither VB.NET nor C# will help you. C# has
unsafe code, but not unmanaged code.
Yes I know - another senior moment - apologies...
Well, one example is that C# enforces strict type safety at all times
so you'll have to do a lot of casting & conversion operations that you
might not have had before, this is both a merit and a pitfall insofar
as that you may have to write some extra code, but that type safety is
ultimately a good thing.
Another example perhaps is that some people find C to be cryptic or
perhaps just difficult to read. This may be because the whole "C"
family substitutes symbols for a lot of words, I can't really tell
because I've been doing this for a while now, I've worked with a lot of
different languages and they pretty much all look the same to me now.
The tradeoff here is that C# code can be more concise, you can view
more C# code on screen at once because it's shorter.
One more thing to discuss is case-sensitivity. This makes VB
programmers especially nervous, but trust me it's not that bad and it
gives you more flexibility in choosing names for member variables.
In C#, you have to end each line of code (different from a line of
text) with a semicolon. So you have to type a lot of semicolons.
However, you can insert carriage returns in a line of code which can
make a lengthy call more readable. In VB.NET, you have to enter the
line continuation character '_' if you want to split lines.
So ask yourself, would I rather type a semicolon at the end of every
command? Or do I want to type an underscore every time I want a
command to span multiple lines.
In C# you also have more options for formatting in your code, this can
be a benefit or a curse as it can make code easier or harder ot read
depending one your perspective.
There are a few other technical differences but really nothing major.
I think if you are comfortable with VB.NET already you should be able
to get handy with C# in a couple of days with an ample supply of
coffee. The important thing, once again, is that you understand the
..NET framework.
There are other things to consider. Most modern languages, including
VB.NET and Java owe much of their lineage to C and it's progeny. It is
good to become familiar with the C-style syntax. Even a VB.NET
programmer is going to learn how to read C# eventually, so much of the
sample code you'll look at online is posted in both languages right
next to each other you're just going to absorb it naturally anyway so
you might as well take a direct approach and learn both.
If you learn C#, you should at least be able to read and understand
Java source code which is a useful skill for a developer these days
too.
Here's two examples, which one do you like better? Really, are they
even that different?
Sample VB.NET class:
Public Class VbNetClass
Private _alpha As String
Public Property Alpha()
Get
Return _alpha
End Get
Set(ByVal value)
_alpha = value
End Set
End Property
Public ReadOnly Property Beta()
Get
Return "Vb.Net is the best language. Semicolons are for fake-ass
hoes."
End Get
End Property
End Class
Sample C# Class:
public class CSharpClass
{
private string alpha;
public string Alpha
{
get { return alpha; }
set { alpha = value; }
}
public string Beta
{
get { return "You talk too much."; }
}
}
Well, one example is that C# enforces strict type safety at all times
so you'll have to do a lot of casting & conversion operations that you
might not have had before, this is both a merit and a pitfall insofar
as that you may have to write some extra code, but that type safety is
ultimately a good thing.
But, it is considered by most unthinkable to *not* turn Option Strict on in
VB.NET, which effectively makes VB.NET type-safe as well. This means that
the same casting and additional code would be needed in VB.NET as well as
C#. So the bottom line is that type safety isn't really something that
would/should tilt the scales in favor of any one language.
Fair enough, I was just trying to list some of the differences between
VB.NET and C#. As I've said for all practical purposes the two
languages are the same so my preference for C# really just comes down
to me preferring the C# syntax.
By the same token though, if you're using option strict in your VB code
(I think you'd be surprised how many developers choose option sloppy)
then you really wouldn't be writing any extra code in C# to handle the
all the casting.
allfyre wrote:
I've worked extensively with both languages and functionally it doesn't
make a lick of difference one way or the other. C# has a few features
that you don't get in VB, mainly pertaining to the use of pointers and
"unmanaged" code which more or less manipulates memory directly.
You're probably not going to need to do it anyway.
Don't worry about the sale to management, they don't care what you use
one way or the other as long as they can get everything in
Excel/PowerPoint at the end of the day.
What you should do is discuss it with your team, discuss the merits and
pitfalls of working with either language and decide what you want to
use and tell management that you want to make the move to this language
or that because it's what your developers want to be working in.
As far as learning a new language goes, the important thing (and the
difficult thing) is learning the .NET framework and how to leverage it.
The languages themselves are easy. I think that VB.NET is more
different from VB6 than it is from C#. VB.NET even supports all the
same C/C++ operators now.
Also, there is no reason why you can't work in both languages as they
are completely interoperable. If you're working with VB.NET currently,
you could try a few small projects in C# and see how you like it. It
does take some getting used to coming from a VB background but
personally I prefer the C# syntax because it lets me write more concise
code, and because I like curly braces.
I've also worked on projects where both languages were employed. For
example a project where the ASP.NET page classes were written in VB.NET
and the middle tier and data access layers were done in C#.
Hi allfyre,
It's unsafe code that's available in C#, not unmanaged.
--
Hope this helps,
Tom Spink
Google first, ask later.
Jon Skeet [C# MVP] wrote:
Scott M. <s-***@nospam.nospamwrote:
But that is entirely orthogonal to my point that VB.NET lets you write
confusing code for no reason other than (presumably) supporting legacy
code.
Didn't someone say, "confusing is in the eyes of the beholder"? LOL. I
just mean that, as all in this thread agree, what's confusing and
non-intuitive to some, is perfectly logical and intuitive to others. It
depends on what angle your coming from.
:)
So who exactly is going to find it perfectly logical and intuitive that
if you appear to call Sleep on a specific thread, you actually make a
completely different thread (the current one) sleep? What is the
*possible* benefit in that?
Some things are indeed subjective, but we really shouldn't let that be
a catch-all excuse for things which just shouldn't be the way they are.
Hi Jon,
What is the *possible* benefit in that?
Absolutely none.
--
Hope this helps,
Tom Spink
Google first, ask later.
I prefer "Unmanaged" but feel free to call it whatever you like. I
think "unmanaged" or "partially managed" code is a more accurate term
than "unsafe."
Better yet, how about "managementally challenged" code?
Unmanaged and unsafe mean completely different things. It's not a matter of
preference. They are accepted terms that have definate and different
meanings.
Unmanaged code is code that is not run within the context of the CLR.
Unsafe refers to code that does not enforce type casting until runtime.
"allfyre" <al*****@hotmail.comwrote in message
news:11**********************@i3g2000cwc.googlegro ups.com...
>I prefer "Unmanaged" but feel free to call it whatever you like. I
think "unmanaged" or "partially managed" code is a more accurate term
than "unsafe."
allfyre wrote:
I prefer "Unmanaged" but feel free to call it whatever you like. I
think "unmanaged" or "partially managed" code is a more accurate term
than "unsafe."
Hi allfyre,
Unfortunately, the two are actually different concepts, calling one the
other would be incorrect.
Unsafe code is code that is called within managed code (i.e. code executed
by the CLI) that manipulates memory directly, e.g. using pointers.
Unmanaged code is native code that is not JIT compiled by the CLI. It's
code that can be natively executed, on the CPU.
--
Hope this helps,
Tom Spink
Google first, ask later.
I see your point, however:
What the CLI "manages" is the memory required to sustain objects in
your application, no? By using the "unsafe" keyword, you are
essentially bypassing the management infrastructure therefore provided.
I don't like calling it "unsafe" because it's not, unless you make it
so. Perhaps "unmanaged" would have been a better keyword.
On the occasions where my team and I have to resort to this kind of
barbarity, we generally refer to the situation as "performing an
unmanaged operation," as in "This passes control to the Transform()
function which performs a few unmanaged operations."
We do this since the "Wayne Incident," whereby a mid-level manager
stumbled in on an IT meeting while we were discussing such a solution.
He heard the words "unsafe code" and "production servers" and his
little manager ears perked up and he stuck his head in and started
wanting to know what we were talking about.
We tried for a while to explain, but it just wasn't working so we had
to just throw letters and numbers at him for a few minutes until his
eyes finally glazed over, sending him into a blissful, managerial
trance that made him forget everything he heard and leave the room
smiling, confident that he was complete in control of the situation.
Tom Spink wrote:
Hi allfyre,
Unfortunately, the two are actually different concepts, calling one the
other would be incorrect.
Unsafe code is code that is called within managed code (i.e. code executed
by the CLI) that manipulates memory directly, e.g. using pointers.
Unmanaged code is native code that is not JIT compiled by the CLI. It's
code that can be natively executed, on the CPU.
--
Hope this helps,
Tom Spink
Google first, ask later.
allfyre wrote:
I see your point, however:
What the CLI "manages" is the memory required to sustain objects in
your application, no? By using the "unsafe" keyword, you are
essentially bypassing the management infrastructure therefore provided.
I don't like calling it "unsafe" because it's not, unless you make it
so. Perhaps "unmanaged" would have been a better keyword.
On the occasions where my team and I have to resort to this kind of
barbarity, we generally refer to the situation as "performing an
unmanaged operation," as in "This passes control to the Transform()
function which performs a few unmanaged operations."
We do this since the "Wayne Incident," whereby a mid-level manager
stumbled in on an IT meeting while we were discussing such a solution.
He heard the words "unsafe code" and "production servers" and his
little manager ears perked up and he stuck his head in and started
wanting to know what we were talking about.
We tried for a while to explain, but it just wasn't working so we had
to just throw letters and numbers at him for a few minutes until his
eyes finally glazed over, sending him into a blissful, managerial
trance that made him forget everything he heard and leave the room
smiling, confident that he was complete in control of the situation.
Tom Spink wrote:
>Hi allfyre,
Unfortunately, the two are actually different concepts, calling one the
other would be incorrect.
Unsafe code is code that is called within managed code (i.e. code
executed by the CLI) that manipulates memory directly, e.g. using
pointers.
Unmanaged code is native code that is not JIT compiled by the CLI. It's
code that can be natively executed, on the CPU.
--
Hope this helps,
Tom Spink
Google first, ask later.
Hi allfyre,
I don't like calling it "unsafe" because it's not, unless you make it
so .
But it /is/. Even if you code defensively, your code is unsafe. That is,
it's not protected by the runtime.
Performing an unmanaged operation could be viewed as calling some interop.
routine, like a 'public extern void Foo();', implemented in an /unmanaged/
DLL, like 'user32.dll'.
--
Hope this helps,
Tom Spink
Google first, ask later. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Dieter Vanderelst |
last post by:
Dear all,
I'm currently comparing Python versus Perl to use in a project that
involved a lot of text processing. I'm trying to determine what the most
efficient language would be for our...
|
by: Joshua D. Drake |
last post by:
Hello,
I think the below just about says it all:
http://www.commandprompt.com/images/mammoth_versus_dolphin_500.jpg
Sincerely,
Joshua Drake
|
by: Andrew Robinson |
last post by:
I need to create a shared static field for use within a number of different
classes. Which one should I be using or are they all really the same thing?
public class Widget
{
private Widget() {}...
|
by: Jon Lapham |
last post by:
I have a table that stores TEXT information. I need query this table to
find *exact* matches to the TEXT... no regular expressions, no LIKE
queries, etc. The TEXT could be from 1 to 10000+...
|
by: Xah Lee |
last post by:
Tabs versus Spaces in Source Code
Xah Lee, 2006-05-13
In coding a computer program, there's often the choices of tabs or
spaces for code indentation. There is a large amount of confusion about...
|
by: johnpa60 |
last post by:
Hello
Anyone here has seen any materials on comparing DB2 CM versus Domino
Doc Server? Can you please point me?
If any of you have worked on both products, can you please spend few
minutes...
|
by: John Doty |
last post by:
I realized that I have a little job on the table that is a fine test of
the Python versus Standard Forth code availability and reusability issue.
Note that I have little experience with either...
|
by: blangela |
last post by:
I have decided (see earlier post) to paste my Word doc here so that it
will be simpler for people to provide feedback (by directly inserting
their comments in the post). I will post it in 3 parts...
|
by: John LaRusic |
last post by:
Hi all,
I'm fairly new to the world of schemas, but I have a question that I
hope someone can help answer for me. I'm curious as to what the
difference is between an element and a complexType?...
|
by: aj |
last post by:
DB2 8.2 LUW FP14
Is there any real difference between
select blahblahblah... where blah IN (select blah......)
versus
select blahblahblah... where blah = ANY (select blah.....)
versus
select...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
