Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie
Why C# over VB.NET
Options
-
06-12-2008 11:13pm#1
Comments
-
-
-
-
-
-
Advertisement
-
-
-
-
-
-
Advertisement
-
VB.Net can be every bit as strongly typed as C#, and with the right compiler options it can be every bit as strict and catch all the same errors and warnings you will get with C#.C# is far more strongly typed. Altjough the new version allows the "var" keyword for using anonymous types. So as the posters above suggest, it catches far more errors and lets you get away with far less in terms of sloppy code which leads to good habits (hopefully).
Of course if you're relying on the compiler to enforce good coding, you already have far bigger problems than what language you use.
Lambda expressions are coming to VB.Net too, I might be wrong but I'm not aware of any functionality in C# that is not available in VB.NetIt is gaining a huge functionality footprint now with the newest versions supporting stuff like lambda expressions etc (some would argue that its footprint is now too big)
VB.Net is every bit as true an OO language as C#.It is a true OO (object orientated) language. If you learn it you realy are learning OO and that may well stand to you in the future.
I've found that intellisense actually works slightly better in VB.NetIt's a fun language. I still get a kick out of writing a class and just seeing it pop up in intellisense - never mind actually running.
VB.Net is also widely used in those platforms. It doesn't matter what language third party APIs are written in, if it's written in C# you can still use it in VB.Net, if it's written in VB.Net you can still use it in C#.It is far more widely used in traditional and non traditional platforms such as ASP.Net, Windows Mobile, Robotics. Third parties support and develope API's much more so in C# than in VB. If you go searching for examples on the web as a learner, you will find far more c# examples than VB.
I actually heard the exact opposite rumour at one point, although I didn't believe it.There are rumours that VB is not being taken as seriously as C# in MS and that there may come a day when VB gets put to bed (as I say these are rumours, nothing official).
VB.Net is quite handy too,steveire wrote:Increments and decrements in C# is so handy: i++;i+=1
which also makes it very easy if you want to increment by something other than 1 or by a variable value.
I prefer C# myself, but that's really just personal preference. There's no real reason to knock VB.net, for almost all practical purposes it's entirely equivalent to C#. The only differences are a matter of taste.0 -
I first started to look at VB about a year ago now and I came across this article that gives a very good article for choosing C# over VB.NET, had it in my bookmarks ever since!:VB.Net IDE is great and background compiler rocks, but IMO C# is a better designed lenguage, and VB focuses on ease at the expense of simplicity.
All the lacks I've found in VB are a first-day-candy second-day-snare: features allowing people to start coding faster but generating some confusion about OO desings and, at the end, what your code do. IMO VB is a always-compile-never-works lenguage.
Some examples:
- Assignment and equality are different things. Using the same symbol is hazy
bool a = 2 == 3; // simple
Dim a as Boolean = 2 = 3 // not so much
- Allowing static methods be called as if they where instance methods it's a great idea if you want to confuse people. A VB programmer usually tries to override a static method. C# syntax teaches C# programmers that this is a senseless.
- Overrides, MustOverride, Overrideable and NotOverrideable keywords are scientific but more confusing and hard to write than the c# equivalents:
override, abstract, virtual an sealed. Just as 1, 2 an 5 cents Euro coins.
- Overloads. The only utility of this keyword its to increase the confusing with the override keyword family
.
- Implicit casting everywhere it's a bad idea, but Option Strict it's very severe and having thousand of casting functions (DirectCast, CType, CInt, CBool...) so nobody uses it. The result is that visual basic code usually converts to string and go back. No body knows what the type of a individual sub expression.
Furthermore, the 'implicit casting everywhere idea' make generics a bit harder to understand to VB programmers.
By the way, it's funny to see CInt to cast to Integer, and CBool to cast to Boolean, Why not using Int and Bool data types instead?
- Everything can be Nothing. In VB you can assign Nothing to an integer, a char, a DataTime and they get it's default value. This is an asymmetric behaviour with some problems:
- VB programmers understand worst value-types.
- VB programmers think on String class as a value-type just because VB return true when comparing Nothing and "", another surprising behaviour.
- Everything can be Nothing idea makes Nullable types difficult to understand.
- Writing ByVal everywhere makes ByRef hard to find.
- Not writing ByRef on calling it's a mistake. Writing it is clearer to understand.
- Allowing passing a Property ByRef it's a great idea if you want to never understand what a Property is, and what ByRef really means.
- Even more, allowing passing a literal as a ByRef parameter its a daring to the logic. Passing Nothing ByRef it's the climax of the stupidity.
What's supposed to do this code?
Function IncAndReturn(ByRef a As Integer) As Integer
a += 1
Return a
End Function
IncAndReturn(Nothing)
- Visual Basic events / delegates syntax make Visual Basic programmer to forget delegates. Delegates are first class types in .Net, but not for visual basic programmers.
- Object default return type. If I forgot to write the return type, please compiler, remind to me, probably it's not just an 'object'
- Some code path without return. If I've forget to return something, please remind to me, don't return nothing.
- Not Initialized local variables should be marked. Write '= null' when you are coding cost 1 second. Take notice of a lost initialization at runtime cost 2 minutes.
- References in VB.Net 2005 are hidden. The average VB programmer builds a one project solution?
- Visual Basic allow not writing parenthesis on methods without parameters, writing parameters on properties and arrays are acceded with parenthesis, this is a more confusing approach than the C# one:
¿What People is?
Visual Basic
- People() -> A Method or a Property
- People(2) -> A Method, a Property, a Array, a Collection with a default parameterized property or a Named property.
- People -> A Method, a Property or a field
C#
- People() -> A Method
- People(2) -> A Method
- People[2] -> A Array (or a collection with an indexer)
- People -> A Property or a Field
With these examples, I want to show the problems of the Visual Basic "first-day-candy second-day-snare" philosophy, not a deep C# - Visual Basic comparison.
I've not mentioned for example missing features of VB 2003 like using statement, unsigned data types, unsafe code... and VB 2005 missing features like anonymous methods, Iterators and Nullable<T> special synthax.0 -
-
-
Not really, C# is a more well defined language than VB.NET.
In C# the line ends when I type the semicolon.:
string sql = @SELECT *
FROM myTable
WHERE mainID=12
ORDER BY FirstName ASC ";
So when someone hands you a SQL statement you can just paste it into your code and the output (i.e. carriage returns) will still keep the format.
In VB.NET, it looks like this:
dim sql as string = "SELECT *" & _
"FROM myTable" & _
"WHERE mainID=12" & _
"ORDER BY FirstName ASC "
I work with VB and testing sql statements is an absolute nightmare, i usually put the program in debug mode and copy the string to the clipboard to get the sql statement out. Saves a lot of time
C# catches a lot more errors than VB.NET, such as uninitialized variables, etc... (Hence allowing bad coding practices with VB)
You can develop apps for OS' other than Windows, such as Linux and MacOS with C#. (using a C# compiler from Novell)
Increments and decrements in C# is so handy: i++;
in comparision to VB.NET: i = i + 1;
Don't get me wrong im not anti-VB. I've done and still do a bit of work with VB.
Try i +=1 in VB.NET just saved you a load of time :P
Couple of things.. certain techs are C# only (BizTalk, XNA if you want to port to the XBOX for example)
Otherwise, somethings are much easier in VB.NET such as XML, its a freaking doddle compared to C#.. But I am from a VB.NET background and I moved to C#.
I dont see the fuss, being honest. I will code in whatever language I am paid to do 0 -
Before I post, my background is that I worked for 3 years in industry developed .net web apps in C# and moved to development in VB.Net about a year ago. My opinion is that there are no clear advantages to either language beyond syntactic preference and developer snobbery.C# is in short, a simple object oriented language. imo vb.NET is not an OOL language.
Can you explain how you have come to this conclusion? I have never found any realistic way that I can be more Object Oriented in C# than I can be in VB.Net. Are you sure that your lack of knowledge of VB isn't the cause of the problem here?vb.NET allows some awful coding and it is not quite as powerful as C#.
Languages don't create awful coding, awful coders create awful coding. A good carpenter doesn't blame his tools.vb.NET imo is not a language for any serious develper to major in. Very few college courses have not got any hint of VB in the curriculum.
If we are to use what college courses teach as the benchmark then Java blows both VB.Net and C# out of the water. I think you'll find that the colleges decide on which languages to use in their courses based on licensing costs.
If you want to see what "serious developers" develop in, you need to quantify what a serious developer is! I know a lot of "serious developers" who would tell you that anything compiling into the .NET CLR is not a "serious language".VB does not support that many OS' and is not as powerful. VB is quick and easy for standalone programs, for built in tools/plugins or for supporting and getting the best out of an API look to an object oriented language.
VB.Net compiles into the same number of languages as C#, one. Unless you try to use Mono, which I've never been too successful at doing
I can assure you that I have gotten just as much out of the .NET framework in VB as I have in C#.
My finally response to you is this:Not really, C# is a more well defined language than VB.NET.
In C# the line ends when I type the semicolon.:
string sql = @SELECT *
FROM myTable
WHERE mainID=12
ORDER BY FirstName ASC ";
So when someone hands you a SQL statement you can just paste it into your code and the output (i.e. carriage returns) will still keep the format.
In VB.NET, it looks like this:
dim sql as string = "SELECT *" & _
"FROM myTable" & _
"WHERE mainID=12" & _
"ORDER BY FirstName ASC "
I work with VB and testing sql statements is an absolute nightmare, i usually put the program in debug mode and copy the string to the clipboard to get the sql statement out.
I think another poster has said this already, but writing SQL in your code like this is Hell World level stuff. If you consider the above to be well written and acceptable code, then I don't think you should be adopting such an authoritative tone in a discussion on the merits of VB.Net versus C#.
Final point is, someone mentioned that C# developers make more money than VB developers. I can confirm that this might be the case in the majority of positions but there are certainly VB jobs were the money is better, the language rarely dictates salary, your experience, abilities and the prospects of the company are far more likely to influence your salary.
My answer to VB versus C#, both are for all intents and purposes equal, I prefer C# for syntactic ease.0 -
-
-
-
-
Advertisement
-
-
-
Advertisement