Can some one tell me why is there more demand for C# vs VB .NET? Personally
i have programmed in VB .net a little bit and have found it easier to use.
Is there any hidden secret about C#?
Please let me know.
Thanks
Manny
C# has some great features, and from what I understand a lot of
things in the .Net Framework such as ASP.Net were written in it. VB has some
great features as well and is maturing nicely (well, not everyone would
agree). If you can do the same thing that you could do in C#, but slightly
faster in VB.Net then why not use VB? It comes down to comfort and skill. If
you're skilled and comfortable in one language, it doesn't matter how
powerful the other language is as it will take you longer to work with
something you're not as skilled in even if that language could let you do a
tad more.
--
Hope this helps,
Mark Fitzpatrick
Former Microsoft FrontPage MVP 199?-2006
"Manny Chohan" <Manny...@discussions.microsoft.com> wrote in message
news:4EBB1F6C-CFD5-4E74...@microsoft.com...
yes, it suffers from java envy
--
I hope this helps,
Steve C. Orr
MCSD, MVP, CSM
http://SteveOrr.net
"Manny Chohan" <Manny...@discussions.microsoft.com> wrote in message
news:4EBB1F6C-CFD5-4E74...@microsoft.com...
The main reason that most Java programmers are moving to C# is because
of the poor performance of the Java language/runtime files. It was
invented to "run anywhere" - but it "runs anywhere slowly".
VB & C# both compile to the same code, so run equaly faster - and
infinatly faster than Java ! Good luck with your choice.
Cheers
The Grand Master
Both languages are now very similar, with very little to choose between
them other than the obvious syntactic differences. C# is often
perceived as being more difficult and functional, whereas this isn't
really the case.
It really comes down to personal preference, if you have a VB
background then you'll find VB.NET more familiar, but if you come from
Java/C/Perl then you'll feel more at home with C#. If you're new to
programming then go with C# because there are more jobs with higher
salaries.
Once you've learnt the fundamentals of C# or VB.NET, it's not too
difficult to pick up the other language. The biggest challenge is
learning the .NET Framework, which is the same regardless of language.
Chris
Both languages are now very similar, with very little to choose between
them other than the obvious syntactic differences. C# is often
perceived as being more difficult and functional, whereas this isn't
really the case.
It really comes down to personal preference, if you have a VB
background then you'll find VB.NET more familiar, but if you come from
Java/C/Perl then you'll feel more at home with C#. If you're new to
programming then go with C# because there are more jobs with higher
salaries.
Once you've learnt the fundamentals of C# or VB.NET, it's not too
difficult to pick up the other language. The biggest challenge is
learning the .NET Framework, which is the same regardless of language.
Chris
No. Nobody can tell you, but you can start a useless debate all over again,
which happens about once a week on this forum, and others.
--
HTH,
Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com
A watched clock never boils.
"Manny Chohan" <Manny...@discussions.microsoft.com> wrote in message
news:4EBB1F6C-CFD5-4E74...@microsoft.com...
1. C# is more concise
2. C# has more refactoring support in Visual Studio
3. C# allows you to have unsafe code blocks (not used often, but a nice
feature)
4. C# has no training wheels that add weight (compatibility namespace
primarily in VB.NET)
5. C# forces you to make the paradigm shift from classic VB to .NET, as you
no longer attempt old syntax
I am currently doing some work in VB.NET. I occasionally run into problems
and then I code in C# and reverse engineer with reflector.
As for "why is C# more popular"? It is most likely because it is new. If we
are searching for a panacea, new is better, right?
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com
*************************************************
Think outside of the box!
*************************************************
"Manny Chohan" <Manny...@discussions.microsoft.com> wrote in message
news:4EBB1F6C-CFD5-4E74...@microsoft.com...
90% of what you do in a .NET project uses the .NET CLR, and 90% of the
code should be verbatem identical between a VB.NET and C# project.
So, if you're a good VB.NET programmer, spend a couple weeks
translating some of your VB code to C# and then go ahead and apply for
that C# job and tell them exactly what you did. If they don't want you
based on that, you don't want to be working for them.
http://www.codeproject.com/dotnet/CSharpVersusVB.asp
I think the java thing as been mentioned. Take for instance a college like
North Carolina State University.
CSC (Computer Science) students code in java for most classes.
If a student wants to jump into the Microsoft world, they're going for C#,
and never Vb.Net.
My experience is that a developer who starts in c#, seldom moves to VB.NET.
A developer who starts in vb.net, and goes to c#, doesn't look back.
Those are my observations. They're not a macroview, just what I've seen.
Now, from someone who has coded in both. Here is my list:
Here is my concrete list of differences. When someone says "There are not
differences", you need to ask if they've actually coded in both for an
extended time.
Here is my list. My company was solely a VB.Net shop, and this is the list
used to show some differences.
Here is as concrete as I could get, with no commentary.
This way my best attempt. If there are workarounds, please politely list
them.
I'm not trying to start an old and dead horse war, just listing what
concrete items I have found.
*** This is a 1.1 list ***. Some may or may not apply in 2.0.
VB.NET has no "using" directive.
VB.NET does not do automatic namespacing. Whenever you put in a new folder
and/or class, C# puts in "namespace MyCompany.Technology.Args" for you.
In VB.NET you have to ~remember to put in "namespace
MyCompany.Technology.SomethingElse". Or everything defaults to the default
namespace.
VB.NET does not provide pre-build or post-build steps.
(there is a work around available for this , one is build rules ex
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=a3326eb3-a468-4f67-91a8-f84469fc49e2
)
VB.NET has no built-in comment->documentation generator
(see previous forum post about GhostDoc)
(there is a work around available for the default c# functionality, but
there is no equivalent GhostDoc feature)
See demo at
http://channel9.msdn.com/Showpost.aspx?postid=121822
VB.NET regions are not as flexible as c# regions.
The key here is that you can place a region ~~inside a function (in C#),
thus breaking up the implementation into logical pieces.
VB.NET does not allow the application the <NonSerialized> attribute to
events (you can in C# by using the Field: modifier).
As a result, there is no simple way of telling the runtime not to serialize
the event fields.
This results in serializing objects that you didn't expect, resulting in a
larger stream.
If the object handling the events is not Serializable, then the
serialization process will throw an exception.
( See http://www.codeproject.com/vb/net/serializevbclasses.asp for more info
and workaround )
VB.NET has less features with its static code analysis (as in, when you go
to Build / Build Solution).
Issues like : functions that don't return values, uninitialized variables,
unused variable declarations, etc...
Development time (in c#) is slightly decreased by finding these issues at
compile time.
VB.NET does not have ... Increments/Decrements. a++;a--;
VB.NET does not have operator overloading. C# has Operator Overloading.
(see http://www.csharphelp.com/archives/archive135.html)
VB.NET has no multiline comment syntax
VB.NET has no within-the-line comment syntax
VB.NET has no multiline string syntax
VB.NET has a limit on line continuations (I think the limit is 10?)
"sloan" <sl...@ipass.net> wrote in message
news:OV08Kev5...@TK2MSFTNGP03.phx.gbl...
>
> *** This is a 1.1 list ***. Some may or may not apply in 2.0.
>
>
> VB.NET has no "using" directive.
Fixed.
>
>
> VB.NET does not do automatic namespacing. Whenever you put in a new
folder
> and/or class, C# puts in "namespace MyCompany.Technology.Args" for you.
> In VB.NET you have to ~remember to put in "namespace
> MyCompany.Technology.SomethingElse". Or everything defaults to the default
> namespace.
True, but the VB module statement is an equivalent. In C# 2005 everything
must be in a class, but in VB 2005 you can place functions and subs in
modules and they will be global or accessable via the module name .
function/sub name.
>
>
> VB.NET does not provide pre-build or post-build steps.
> (there is a work around available for this , one is build rules ex
>
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=a3326eb3-a468-4f67-91a8-f84469fc49e2
> )
Haven't tried, so I don't know.
>
>
> VB.NET has no built-in comment->documentation generator
> (see previous forum post about GhostDoc)
> (there is a work around available for the default c# functionality, but
> there is no equivalent GhostDoc feature)
> See demo at
> http://channel9.msdn.com/Showpost.aspx?postid=121822
>
Unfortunately still true as far as I can tell.
>
> VB.NET regions are not as flexible as c# regions.
> The key here is that you can place a region ~~inside a function (in C#),
> thus breaking up the implementation into logical pieces.
>
VB is still missing this capability. Also, in VB 6, you could have the IDE
display only the functoin/property/sub you're working on. This would be a
nice feature to add back to the IDE.
>
>
> VB.NET does not allow the application the <NonSerialized> attribute to
> events (you can in C# by using the Field: modifier).
> As a result, there is no simple way of telling the runtime not to
serialize
> the event fields.
> This results in serializing objects that you didn't expect, resulting in a
> larger stream.
> If the object handling the events is not Serializable, then the
> serialization process will throw an exception.
> ( See http://www.codeproject.com/vb/net/serializevbclasses.asp for more
info
> and workaround )
>
Status unknown - I haven't used the serialize features of dotNET.
>
>
> VB.NET has less features with its static code analysis (as in, when you go
> to Build / Build Solution).
> Issues like : functions that don't return values, uninitialized variables,
> unused variable declarations, etc...
> Development time (in c#) is slightly decreased by finding these issues at
> compile time.
>
No longer true. Also, the background compiler for VB 2005 is far superior
to the one for C# 2005.
>
> VB.NET does not have ... Increments/Decrements. a++;a--;
>
VB 2005 still doesn't have the increment/decrement operators, however, it
does have the more general += and -= operators.
>
> VB.NET does not have operator overloading. C# has Operator Overloading.
> (see http://www.csharphelp.com/archives/archive135.html)
>
VB 2005 has the same operator overloading abilities as C# 2005.
> VB.NET has no multiline comment syntax
>
> VB.NET has no within-the-line comment syntax
>
> VB.NET has no multiline string syntax
All three of the above are still true, and all would be welcome additions..
>
> VB.NET has a limit on line continuations (I think the limit is 10?)
>
In VB 2005, it's appears to be unlimited. I just tested 30 lines and the
documentation says a single line can be 65535 characters long and you can
create longer statements via line continuation..
In addition, VB 2005 has the following useful features:
Event Handlers added by the IDE include the clause "Handles <object.event>,
making it real easy to find orphaned event handlers.
When inheriting a class with MustOverride or Implements items (abstract in
C# terms), the IDE will automatically insert the correct prototype for you.
VB has inherited the VB6 C<type> features such as CInt, CLng, and has also
abstracted the System.Convert class in a single CType(object, <class>)
statement for a generalized C<type> interface.
The My classes, which can be used in C# via a using statement, are native to
VB.
Case insensative code. Foo and foo are the same. The IDE will correct the
case for you, but the compiler won't spit out a ton of errors if you forget.
One syntactical item sorely missing is the C# yield statement. It can be
worked around, but it should have been part of the language. I'm sure there
are other features of C# that VB is missing, but I'm currently unaware of
them.
C# still tends to have higher salaries because of the stigma surrounding VB
as a "toy" language, which it definitely hasn't been since at least VB 5.
One thing MS has done really well is supporting multi-language solutions in
that each project of the solution can be written in a different language and
they will seamlessly work together. Other venders have done this, but their
solutions didn't command the market share that MS does.
Mike Ober.
As for speed... I've done real-time 3D rendering in JAVA. With a
decent JIT compiler and some thought as to how it's programmed (i.e.
avoiding object instantiation in inner loops that run millions of times
a second) JAVA can be quite fast. The claim that the .Net languages
are "infinatly faster" (please learn to spell, master programmer) is
ridiculous.
I use C# most of the time, VB.Net when clients insist on it. I prefer
C# because it seems less verbose, i.e. "int c;" versus "Dim c As Int"
(what is a "Dim" anyway?) but I'd agree with the majority of posters
that you can use whichever you prefer with little or no practical
difference for nearly all tasks.
--Russell
[ducks for cover]