 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / General / April 2008C# or VB.NET?
Hi, I am a beginner in .NET. I have been coding in plain asp before, using VBScript, and now when i'm migrating to .NET, i obviously chosed VB.NET. But.... when i see code samples on net, they are mostly in C#, i also saw a post in this newsgroup where someone mentioned that it was a very "heated topic back in 2002 about VB.NET vs C#". So, my question is... what was the result of that topic? What is best to go for, VB.NET or C#? and why? Thanks and regards Which language you choose depends on a number of factors. If you are a professional and have career in mind, C# is going to give you better odds at advancing your career. In addition, as you've noticed, it is much easier to find examples and samples written in C#. On the other hand, if you are a casual or part-time developer, and you have little or no experience with the C or Java language families, and are familiar with VB or VBScript, and you are not familiar with object-oriented programming, it might be easier for you to ease into ASP.Net with VB.Net, and worry about learning or not learning C# later on. The difference between the programming paradigm of ASP classic and ASP.Net is quite a learning curve. However, it might be argued that learning C# when you start learning ASP.Net will help you keep from falling into the trap of thinking in ASP classic terms when doing ASP.Net. Ultimately, it's entirely up to you, and, as Led Zeppelin once said, "there are 2 paths you can go by, but in the long run, there's still time to change the road you're on."  SignatureHTH, Kevin Spencer Chicken Salad Surgeon Microsoft MVP > Hi, > [quoted text clipped - 9 lines] > > Thanks and regards > I am a beginner in .NET. I have been coding in plain ASP before, using > VBScript, and now when I'm migrating to .NET, I obviously chose VB.NET. Obviously??? You've clearly fallen into the trap that VB.NET is somehow an upgrade of Visual Basic and that ASP.NET is somehow an upgrade of ASP Classic. Apart from some peripheral syntactic similarities, nothing could be further from the truth. The reason, of course, is the .NET Framework... Since you're familiar with ASP Classic, you no doubt enjoy the comfort factor of Dim This As That, If...Then...Else...End If etc... But, since you're familiar with ASP Classic, you've almost certainly had some exposure to JavaScript, so basic C# syntax will already be totally understandable to you... > But.... when i see code samples on net, they are mostly in C#, i also saw > a post in this newsgroup where someone mentioned that it was a very > "heated topic back in 2002 about VB.NET vs C#". That was me... > So, my question is... what was the result of that topic? There was no result, because there is no right or wrong answer... Both languages are (almost) identical in terms of functionality - the only main advantage that C# had over VB.NET was support for unsafe code i.e. pointers. The reason that both languages are (almost) identical is because they both target the .NET Framework. At it most simplistic level, it really doesn't matter at all what .NET language you use - they are all identical... > What is best to go for, VB.NET or C#? and why? Both, and then decide which you prefer. It's my personal opinion that VB.NET is a totally unnecessary language, and it exists purely for reasons of marketing. Back in early 2002, outside of Microsoft and a tiny beta test community, there were no C# programmers at all. But there were millions and millions of VB programmers, and Microsoft weren't about to alienate them by releasing a new development suite with no flavour of Basic... Prior to .NET, I'd made my living almost exclusively with the various dialects of Basic right back as far as QuickBasic and on through VB for DOS, VB for Windows, VBScript, AccessBasic, WordBasic, VBA etc. But, after about a day with C#, I knew that I never wanted to write another line of Basic again! And, apart from one piece of work in 2004 that I simply couldn't turn down, I never have... However, that's just my opinion... SignatureMark Rae ASP.NET MVP http://www.markrae.net I disagree with you. Although I like C#, it's only because of a sense of cachet that it gives you that you probably feel the way you do (because of the fuzzy feeling you get when you think it's somehow related to C++ in some way-- when really it's not). Aside from C#'s pointer and rudimentary unmanaged code ability (useless in most business solutions), VB does MORE than C#. VB event wiring is better (withevents), intellisense + syntax checking much much better (background compiling as you type), built in functions that wrap a lot of code up (for example, Asc, Left, Mid etc... that handle exceptions gracefully) in both the VisualBasic Library namespace and the handy "My" namespace. Add to that VB2008's superior LINQ/XML implementation and you have a clear superior. Now, you're perfectly welcome to prefer the C# syntax. But in terms of functionality VB is not "identical" to C#... it's better. C. Moya http://www.cmoya.com >> I am a beginner in .NET. I have been coding in plain ASP before, using >> VBScript, and now when I'm migrating to .NET, I obviously chose VB.NET. [quoted text clipped - 46 lines] > > However, that's just my opinion... >I disagree with you. Although I like C#, it's only because of a sense of >cachet that it gives you that you probably feel the way you do (because of >the fuzzy feeling you get when you think it's somehow related to C++ in >some way-- when really it's not). Not true at all - I've never used C/C++ at all in my entire career... > Aside from C#'s pointer and rudimentary unmanaged code ability You mean unsafe code, not unmanaged code... > VB event wiring is better (withevents), WithEvents is totally unnecessary in C#, otherwise it would have it: http://www.thescripts.com/forum/thread255585.html > Asc http://www.thescripts.com/forum/thread441566.html > Left, Mid http://www.thescripts.com/forum/thread246103.html > Now, you're perfectly welcome to prefer the C# syntax. But in terms of > functionality VB is not "identical" to C#... it's better. We'll have to agree to disagree... :-) SignatureMark Rae ASP.NET MVP http://www.markrae.net You missed the point.... with your links. For example: The replacement for VB's "str2 = Left(str, 5)" is not string.Substring(...). It's if (str != null) { if (str.Length >= 6) { str2 = str.Substring(0, 5); } else { str2 = str; } } else { str2 = string.Empty; } The C# way! ;) Sure you can encapsulate this (and everyone will do it differently... and forget a conditional here or there... and u might see the encapsulation in a bunch of places if many developers work on the same project). But, this is just one of example of VB's "moreness" and robustness compared to C#. :) >>I disagree with you. Although I like C#, it's only because of a sense of >>cachet that it gives you that you probably feel the way you do (because of [quoted text clipped - 24 lines] > > We'll have to agree to disagree... :-) > But, this is just one of example of VB's "moreness" and robustness > compared to C#. :) OK. SignatureMark Rae ASP.NET MVP http://www.markrae.net > But, this is just one of example of VB's "moreness" and robustness > compared to C#. :) My understanding is that those functions are there for the VB->VB.NET conversion utility, and also so that VB programmers can use vb.net without having to change their coding syntax, style or methods. Just cos you can doesn't mean you should. >> But, this is just one of example of VB's "moreness" and robustness >> compared to C#. :) [quoted text clipped - 4 lines] > > Just cos you can doesn't mean you should. Absolutely! SignatureMark Rae ASP.NET MVP http://www.markrae.net >>> But, this is just one of example of VB's "moreness" and robustness >>> compared to C#. :) [quoted text clipped - 6 lines] > > Absolutely! "Just cos you can doesn't mean you should" implies there's something wrong with the function (whose equivalent you'd find in many a C#'s developer's "snippet's library"... all different... and all redundant... and often buggy). If the wrapper was written for you (by the Microsoft VB.NET Team).... it's fast (rewritten in .NET), it works well, and it has (ohhhh I dunno over 25 years worth of track record), why not use it? Again, as I noted in another thread... the Microsoft.VisualBasic .NET namespace is not the same as the VisualBasic.Compatibility namespace. Signature-C. Moya http://www.cmoya.com > "Just cos you can doesn't mean you should" implies there's something wrong > with the function What would you rather do? Call "string.Length" or call "len (string)" that then calls "string.Length" internally? And I don't know how the len function handles nulls cos I didn't write it and haven't seen the source. However I know how myString.Length will react if myString is null and I don't need trial and error or consulting docs to tell me. Using those functions also makes it harder to understand c# examples. If you at least use vb.net as intended then reading c# shouldn't be too much problem, and switching to c# if you want to should be easier. >> "Just cos you can doesn't mean you should" implies there's something >> wrong with the function [quoted text clipped - 4 lines] > However I know how myString.Length will react if myString is null and I > don't need trial and error or consulting docs to tell me. I'd rather call Len(str) than do the following in a bunch of places in code: if (str != null) { num = str.Length() } else { // do something else. in this case assign: num = 0 } //(Even worse if I want to duplicate Left/Mid/Right) What's wrong with calling a reusable Len() "utility" function that does the same thing as the conditionals above? > Using those functions also makes it harder to understand c# examples. If > you at least use vb.net as intended then reading c# shouldn't be too much > problem, and switching to c# if you want to should be easier. Is it any different than using utility functions written by other developers in your team or written by developers employed before you joined the team... or worse, copy and pasted from the web? Do all C# developers work alone and bring their redundant encapsulated utility functions to a project? What a nightmare (that I've personally seen.... at least back in the day VB coders did this a lot with API vodoo calls-- but C# guys do it for the most rudimentary things). These built-in utility (standard) functions are designed to make your life easier and manage projects easier.... the goal of all high-end computer languages. Except perhaps C#? I dunno. Signature-C. Moya http://www.cmoya.com > I'd rather call Len(str) than do the following in a bunch of places in > code: So you'd rather your code was vague rather than explicit? What happens when, in "version x", Microsoft change the way Len is written and you need to handle your own nulls? If you find you do that code a lot, then write your own Len function and use it. > These built-in utility (standard) functions are designed to make your life > easier and manage projects easier.... the goal of all high-end computer > languages. Except perhaps C#? I dunno. Fair point. My goal isn't to make things "easier" in terms of coding or management. My goal is to write tight, explicit, strongly typed code that is easy to extend, re-use and has a lower chance of introducing bugs. If I need to put a little extra effort in to do that then so be it. Signature-C. Moya http://www.cmoya.com >> I'd rather call Len(str) than do the following in a bunch of places in >> code: [quoted text clipped - 3 lines] > to handle your own nulls? If you find you do that code a lot, then write > your own Len function and use it. The Len utility function hasn't changed in over 25 years. It's intrinsic. It's like expecting the ++ operator to change in C. I don't see C# guys writing var = var + 1 wrapper functions to replace ++. >> These built-in utility (standard) functions are designed to make your >> life easier and manage projects easier.... the goal of all high-end [quoted text clipped - 4 lines] > is easy to extend, re-use and has a lower chance of introducing bugs. If > I need to put a little extra effort in to do that then so be it. And as a manager, it's my job to make sure that my developers aren't wasting time reinventing the wheel.... duplicating code, violating the basic tenets of encapsulation, and neglecting to use tried and true functions. Whether they're written by other developers in my team or put into the VB runtime by the VB.NET team. > And as a manager, it's my job to make sure that my developers aren't > wasting time reinventing the wheel.... duplicating code, violating the > basic tenets of encapsulation, and neglecting to use tried and true > functions. Whether they're written by other developers in my team or put > into the VB runtime by the VB.NET team. Yes, but loosely typed and coupled code may speed up development but you lose in the long-run on bug fixing and future updates. >> And as a manager, it's my job to make sure that my developers aren't >> wasting time reinventing the wheel.... duplicating code, violating the [quoted text clipped - 4 lines] > Yes, but loosely typed and coupled code may speed up development but you > lose in the long-run on bug fixing and future updates. Nobody is talking about loosely typed code. I am employed to code in C# but in my own time and when I'm paid for jobs outside of work, I use VB. I have never come across any reason not to, and it much more fun to use, Visual studio is much more friendly to VB >>> And as a manager, it's my job to make sure that my developers aren't >>> wasting time reinventing the wheel.... duplicating code, violating the [quoted text clipped - 6 lines] > > Nobody is talking about loosely typed code. > Visual studio is much more friendly to VB In what way(s)...? SignatureMark Rae ASP.NET MVP http://www.markrae.net better intellisence better code completion better snippets, just to name a few >> Visual studio is much more friendly to VB > > In what way(s)...? That's wrong. The VisualBasic.dll library (where those functions reside) is not the same as the VB Compatibility Library (that has truly deprecated things like old VB.Classic control arrays). Stuff in the Visual Basic.dll library are fully supported, and completely rewritten stuff.... along with new stuff like the very handy "My" namespace, which resides in the same library with Left/Right/Mid. Signature-C. Moya http://www.cmoya.com >> But, this is just one of example of VB's "moreness" and robustness >> compared to C#. :) [quoted text clipped - 4 lines] > > Just cos you can doesn't mean you should. What I'm getting at is that to convert VB to vb.net every line like; if len(myString) > 100 then myString = mid(myString, 1, 50) end if would need to be changed to if myString.Length > 100 then myString = myString.Substring(1, 50) etc So by creating len, mid etc functions, the VB code still works with very little change. > That's wrong. The VisualBasic.dll library (where those functions reside) > is not the same as the VB Compatibility Library (that has truly deprecated [quoted text clipped - 11 lines] >> >> Just cos you can doesn't mean you should. >> VB event wiring is better (withevents), > WithEvents is totally unnecessary in C#, otherwise it would have it: > http://www.thescripts.com/forum/thread255585.html Also, I guess VB doesn't need WithEvents/Handles either since it supports both the C# manual += adding of events (via AddHandler... remember to remove it too at some point!) AND a cleaner "declarative" WithEvents / Handles way. Private Sub Button1_Click(...) Handles Button1.Click ... End Sub or (to similate old school VB control arrays) Private Sub Buttons_Click(...) Handles Button1.Click, Button2.Click, Button3.Click ... End Sub No need to tear down the event handler either. >>I disagree with you. Although I like C#, it's only because of a sense of >>cachet that it gives you that you probably feel the way you do (because of [quoted text clipped - 24 lines] > > We'll have to agree to disagree... :-) Hi, Just as i was about to be convinced to go with c#, CMoya's comments have again put me back at 0-point :-) Well, i am a part-time/casual developer. By profession i am a SysAdmin. Developing is something i just like doing in my free time, and i create small applications for internal use i our company, which are often appreciated, since the full-time developers are always working for customers. The reason why i started with vb.net is because of the familiar syntax of VBScript (Dim, if then else, for each etc etc...). I do have very good knowlege og Javascript and a bit knowlege of J2EE as well. So, i dont really think it will be much of trouble for me to switch to c#. Also because i'm still a beginner with .NET. But again, CMoya's comments sounds quite promising in favour of VB. Though honestly, i didn't understand a few things he mentioned :-). But all i'm looking for is "best" way to choose. Thank you all for your helpful replies. Regards. >> I am a beginner in .NET. I have been coding in plain ASP before, using >> VBScript, and now when I'm migrating to .NET, I obviously chose VB.NET. [quoted text clipped - 46 lines] > > However, that's just my opinion... Just as i was about to be convinced to go with c#, CMoya's comments have again put me back at 0-point :-) Well, i am a part-time/casual developer. By profession i am a SysAdmin. Developing is something i just like doing in my free time, and i create small applications for internal use i our company, which are often appreciated, since the developers are always working for customers. The reason why i started with vb.net is because of the familiar syntax of VBScript (Dim, if then else, for each etc etc...). I do have very good knowlege og Javascript and a bit knowlege of J2EE as well. So, i dont really think it will be much of trouble for me to switch to c#. Also because i'm still a beginner with .NET. But again, CMoya's comments sounds quite promising in favour of VB. Though honestly, i didn't understand quite a few things he mentioned :-). But all i'm looking for is "best" way to choose. Thank you all for your helpful replies. Regards. > Hi, > [quoted text clipped - 9 lines] > > Thanks and regards > But all I'm looking for is "best" way to choose. Why do you actually have to choose at all...? SignatureMark Rae ASP.NET MVP http://www.markrae.net > Why do you actually have to choose at all...? Maybe that was wrong choice of words. "Best way to begin" maybe :-) Well, i have alot to learn in .NET yet, and if i go to c#, then syntax will be yet another thing to learn. Besides, most of the samples online are in c#, and by converting them always to VB for me will give me some knolege of c# as well. But since you are an MVP in asp.net. What would you suggest a beginner with my background. VB or C# to begin learning? Regards. >> But all I'm looking for is "best" way to choose. > > Why do you actually have to choose at all...? >> Why do you actually have to choose at all...? > Maybe that was wrong choice of words. "Best way to begin" maybe :-) Fair enough. > But since you are an MVP in asp.net. What would you suggest a beginner > with my background. VB or C# to begin learning? I would suggest you begin with C#, for no other reason that it will force you to think in an object-orientated .NET way and prevent you from carrying over any of the VBScript baggage... I've known quite a few new (to .NET) developers who have begun with VB.NET and then switched to C# - I've never known the reverse... And, if ever you find yourself thinking "How would I have done this in ASP Classic?", then have a five-minute break and approach the problem again from the beginning... :-) SignatureMark Rae ASP.NET MVP http://www.markrae.net > I would suggest you begin with C#, for no other reason that it will force > you to think in an object-orientated .NET way and prevent you from > carrying over any of the VBScript baggage... How is VB any less object-oriented than C#? Inheritance? Check. Interfaces? Check. Namespaces? Check. And what exactly is VBScript baggage and how is it different than JScript baggage? I mean, I'm not trying to be argumentative.... but you don't really posit any real reason why C# is better than VB. >>> Why do you actually have to choose at all...? >> Maybe that was wrong choice of words. "Best way to begin" maybe :-) [quoted text clipped - 14 lines] > Classic?", then have a five-minute break and approach the problem again > from the beginning... :-) > I mean, I'm not trying to be argumentative.... OK. SignatureMark Rae ASP.NET MVP http://www.markrae.net > I mean, I'm not trying to be argumentative.... but you don't really posit > any real reason why C# is better than VB. Good point. >> I would suggest you begin with C#, for no other reason that it will force >> you to think in an object-orientated .NET way and prevent you from [quoted text clipped - 26 lines] >> ASP Classic?", then have a five-minute break and approach the problem >> again from the beginning... :-) > I mean, I'm not trying to be argumentative.... but you don't really posit > any real reason why C# is better than VB. there is only 2 reasons (listed bellow) why (I think) C# is better than VB.NET. 1. Less characters to type. I would kill the person who came up with "Then", "End if", "Select Case". Well, i am kidding, not kill of course, but make him write 1000 times IF ... THEN ... ELSE :) For me { }, "switch" are more easily to read and i understand code better. The type casting is a killing compare C# (int)a; with CType(a, int) I have a big "thank you" to developers of C# for coming up with "using" and "lock" keywords. And i can go on...... Implements/Inherits keywords in VB, "Dim B as Integer" vs "int b", IList.Item vs [], ....... 2. As it been for years C# compiler is less guessing/forgiven than VB.NET compiler. I was cought couple time when my code would produce result i did not expect because VB.NET compiler "guessed" for me what i want to do. And guesses incorrectly. I agree that my code was ambigious but C# would give me an error at compile time as apposed to VB that would throw an error when my customers using the program. Biggest example: Option Explicit. It is a mad man invention. Thanks though that it's "On" by default now. I used to use non-dictionary words every time I saw it's Off in old VB programs...Still see people using it.... I guess hardcode VB programmers that life did not tach anything :) ------------------------------------------------------------------- If you can put up with #1 and #2 then Vb.NET and C# languages pretty much the same. George. >> I mean, I'm not trying to be argumentative.... but you don't really posit >> any real reason why C# is better than VB. [quoted text clipped - 8 lines] > > For me { }, "switch" are more easily to read and i understand code better. Ugh. But the "Break;" in every single case block drives me mad. It's so..... 1982. ;) The C switch statement is the equivalent of the VB goto in terms of ugliness. > The type casting is a killing compare C# (int)a; with CType(a, int) Yeah, C#'s way is definately prettier. But VB's casting is still casting. C# folks think they're function calls, but they're not. They compile to straight MSIL code. > I have a big "thank you" to developers of C# for coming up with "using" > and "lock" keywords. VB has the "Using" (automatical disposal) keyword too. Plus, VB has the "With" keyword.... which is beautiful. C# doesn't. And VB has the SyncLock keyword. > And i can go on...... Implements/Inherits keywords in VB, "Dim B as > Integer" vs "int b", IList.Item vs [], ....... Yes, VB is more verbose. > 2. As it been for years C# compiler is less guessing/forgiven than VB.NET > compiler. [quoted text clipped - 7 lines] > time I saw it's Off in old VB programs...Still see people using it.... I > guess hardcode VB programmers that life did not tach anything :) Everybody knows to turn on Explicit/Strict options. And turning them off (on a class by class basis) can under *some* circumstances be an asset... like when you need to create an MS Office automation solution and you don't want to bind to one particular version, but rather have it work with all versions of MS Office. No can do in C# (AFAIK). > ------------------------------------------------------------------- > If you can put up with #1 and #2 then Vb.NET and C# languages pretty much > the same. > > George. Signature-C. Moya http://www.cmoya.com > Plus, VB has the "With" keyword.... which is beautiful. C# doesn't. Now there I fundamentally disagree with you! I think the With keyword is positively horrible... As you know, a 'with' statement would make C# more complex. As you will also know, VB.NET had to add new language syntax to address the potential ambiguity between a local variable (Text) and a property on the "with" target (.Text), and other ways of solving this problem also introduce language complexity. A different approach is to push a scope and make the property hide the local variable, but then there's no way to refer to the local without adding some escape syntax. SignatureMark Rae ASP.NET MVP http://www.markrae.net What "new language syntax" are you refering to? With (statement) is just shorthand. I'm not aware of any caveats with it... or ambiguity between what appears in the block and what's scoped.... Please explain. As for ambiguity between scoped variables... (Me, the equivalent of C#'s "this" removes all ambiguity). Signature-C. Moya http://www.cmoya.com >> Plus, VB has the "With" keyword.... which is beautiful. C# doesn't. > [quoted text clipped - 10 lines] > local variable, but then there's no way to refer to the local without > adding some escape syntax. > Please explain. http://msdn2.microsoft.com/en-us/vcsharp/aa336816.aspx Near the bottom... SignatureMark Rae ASP.NET MVP http://www.markrae.net Ah. I see. You just copy and pasted.... verbatim. That doesn't explain what the "new language syntax" means. Do you know what that post means and thus why you don't like it? I sure don't. Signature-C. Moya http://www.cmoya.com >> Please explain. > > http://msdn2.microsoft.com/en-us/vcsharp/aa336816.aspx > Near the bottom... >>> Please explain. >> >> http://msdn2.microsoft.com/en-us/vcsharp/aa336816.aspx >> Near the bottom... > > Ah. I see. You just copy and pasted.... verbatim. Not quite... :-) > That doesn't explain what the "new language syntax" means. Do you know > what that post means and thus why you don't like it? I sure don't. I don't like the 'with' syntax because I don't find it particularly readable or intuitive - but that's just my opinion. On a different syntactical subject, I like placing the opening curly bracket on a new line as opposed to the end of the previous line - again, that's just a preference. But back to the plot; the C# team felt that a 'with' statement would add little, if anything, to improve the language so didn't include it, especially since it's extremely easy to simulate it if you absolutely must, e.g. OpenFileDialog dlgOpen = new OpenFileDialog { AddExtension = true, CheckFileExists = true, CheckPathExists = true, DefaultExt = ".bmp" }; See here http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2362686&SiteID=1 for more on this and, yes, that's where I lifted the above snippet from... :-) SignatureMark Rae ASP.NET MVP http://www.markrae.net > Ugh. But the "Break;" in every single case block drives me mad. It's > so..... 1982. ;) The C switch statement is the equivalent of the VB goto > in terms of ugliness. Agree that C# has a lot of semicolumns. But the whole point is that on average you have less to type with C# than .NET. And for me it's easier to read C# program than .NET but that might be just me. > circumstances be an asset... like when you need to create an MS Office > automation solution and you don't want to bind to one particular version, > but rather have it work with all versions of MS Office. No can do in C# > (AFAIK). Reference the earliest version of MS Office your program would work with and all newest versions will work as well. ------------------------------------------------ Late binding is possible in C# http://support.microsoft.com/kb/302902 It might be not so intuitive as in VB, but for me it falls under "compiler trying to guess what you want to do" category. Which I consider a really bad thing. I would rather know how staff works/done and have some control over it. George. >> Ugh. But the "Break;" in every single case block drives me mad. It's >> so..... 1982. ;) The C switch statement is the equivalent of the VB goto [quoted text clipped - 4 lines] > And for me it's easier to read C# program than .NET but that might be just > me. Perhaps in pure syntax alone (though the common switch statement alone belies that assertion), I agree mostly. But you do have to code *more* to achieve the same functionality in C#. There is no equivalent to the intelligent CType for instance (other than littering your code with conditionals to cover it's functionality). Event wiring and tearing down (declaratively done in VB-- though it also supports manual) and all the "utility" wrappers in the runtime and My namespace that save oodles of code and time IMO. And, what's funny is that VB supports all the manual C# ways as well (Direct casting, manual event wiring via AddHandler, etc,)... so you lose nothing. Here's my experience in 10 years coding and leading teams: I've seen lots of (what I personally thought) really horrible VB code.... but that worked well with 0 bugs. It just worked. And it worked well. On the other hand my experience with C# is I've seen some really spartan, clean, pretty code frought with bugs because the developer never thought (or was too lazy) to add a conditional or two to handle things C# doesn't handle intrinsically. >> circumstances be an asset... like when you need to create an MS Office >> automation solution and you don't want to bind to one particular version, [quoted text clipped - 3 lines] > Reference the earliest version of MS Office your program would work with > and all newest versions will work as well. By having the earliest version installed on your machine to bind to? Good luck. I don't ever want to have to install Office 2000 just because I need to write a solution that uses a couple of it's well established COM methods. I guess you can steal the OLB files from an Office 2000 installation on another machine and reference them (I've done it... it works well... but is also prone to gotchas). > ------------------------------------------------ > Late binding is possible in C# [quoted text clipped - 3 lines] > bad thing. I would rather know how staff works/done and have some control > over it. Oh wow... that code... that is just... just... horrid. Using reflection like that to access late bound COM objects. Not only is that not as "intuitive," it's downright "hack-ish" and frought with many opportunities for bugs IMO. > George. > Perhaps in pure syntax alone (though the common switch statement alone > belies that assertion), I agree mostly. But you do have to code *more* to > achieve the same functionality in C#. There is no equivalent to the > intelligent CType for instance (other than littering your code with > conditionals to cover it's functionality). It might help if you provide some examples, but writing strongly typed code is usually seen as a good thing. It removes ambiguity and the possibility for bugs. VB does give you more leeway but that doesn't make it good. For example VB can do this, but is it good? dim x as variant x = 123 x = "Hello World" Of course it's not good. If one object can be converted to another type then it's usually possible in C# too, just with different syntax. >> Perhaps in pure syntax alone (though the common switch statement alone >> belies that assertion), I agree mostly. But you do have to code *more* to [quoted text clipped - 13 lines] > Of course it's not good. If one object can be converted to another type > then it's usually possible in C# too, just with different syntax. VB.NET does not support the Variant data type. Perhaps you meant "Object" type. Which, BTW, C# allows just fine too. See my reply to Mark. We're all coders, we really should read posts before commenting and be more pedantic :) >>> Perhaps in pure syntax alone (though the common switch statement alone >>> belies that assertion), I agree mostly. But you do have to code *more* [quoted text clipped - 16 lines] > VB.NET does not support the Variant data type. Perhaps you meant "Object" > type. Which, BTW, C# allows just fine too. > dim x as variant > x = 123 > x = "Hello World" That's actually not valid VB.NET... In VS.NET 2008, if you type or paste the above code IntelliSense will change Variant to Object. At that level, there's no difference between the above and: object x = new object(); x = 123; x = "Hello World"; SignatureMark Rae ASP.NET MVP http://www.markrae.net > That's actually not valid VB.NET... "For example VB can do this" :) I know, I was harking back to the history of VB where your typing can be as loose as you want. It seems like MS are trying to carry that forward with vb.net too. >> That's actually not valid VB.NET... > [quoted text clipped - 5 lines] > as loose as you want. It seems like MS are trying to carry that forward > with vb.net too. No, not really. Signature-C. Moya http://www.cmoya.com //Quote Everybody knows to turn on Explicit/Strict options. // NO THEY DON'T. I REPEAT..NO THEY DON'T. I still get arguments why some developers don't want to use it that way. Because its "easier". One time I turned it on, and found 200+ issues with basically: Dim X situations. (Aka, no datatype). And since Option Strict/Explicit sometimes related to your IDE setup under "solutions and projects", I find this particuliarly deficient in a team environment. If Vb.Net had a Option JustLikeCSharp On then that would be acceptable. Just because I want the compiler to find the most errors/situations it can. //With Keyword// I didn't like this keyword in VB6. And if anyone nested them, good gosh. I much prefer it not being around in C#. ........ //Using// In VS2005 (2.0) it is there, but not in 1.1 Anyways. I find Option Explicit/Strict being optional ... one of the reasons I dislike development in a group situation. The "with" keyword is ... opinion for the most part. >>> I mean, I'm not trying to be argumentative.... but you don't really >>> posit any real reason why C# is better than VB. [quoted text clipped - 58 lines] >> >> George. Agreed. I hardly ever use "With" anymore either (since the performance advantage in the old COM world doesn't exist in VB.NET). Still, in my ORM entities and stuff, where I need to map huge sets of class properties to dataset fields, it sometimes comes in handy... and makes for way more readable code. I also agree that Strict/Explicit should be turned on by default. As with so many things in the development world, it comes down to good coding guidelines that you and your team must agree to follow. I'm sure C# has its share of "dont's" as well that must be agreed upon in a team's coding standards at the outset. For instance, I insist that my developers use "this" in a class when referring to Properties (and only Properties, btw). It makes for very readable code and is also part of Microsoft's Coding Guidelines. But, I hardly ever see C# (or VB guys for that matter) use it. Signature-C. Moya http://www.cmoya.com > //Quote > Everybody knows to turn on Explicit/Strict options. [quoted text clipped - 99 lines] >>> >>> George. > I would suggest you begin with C#, for no other reason that it will force > you to think in an object-orientated .NET way and prevent you from > carrying over any of the VBScript baggage... I think this point has alot of weight. I do still think about "how i would have solved a perticular issue in classic ASP" Why i even touched this "heated topic" here is because i just wanted to know what is "best". During my learning also i've been trying to stick with "best-practices". using n-tier application structure etc... But i must say, VB.NET and C# is not a "choice" one can make. One way or another, in the end i'll actualy be having my hands on both. Thank you everyone for very helpful input. I've learnt alot from this discussion. >>> Why do you actually have to choose at all...? >> Maybe that was wrong choice of words. "Best way to begin" maybe :-) [quoted text clipped - 14 lines] > Classic?", then have a five-minute break and approach the problem again > from the beginning... :-) The thing is, having a background in VB, you will get a quicker start in .Net, using VB.Net. I did and it worked well for me. I know there are a lot of sites with C# samples, but I can think of one with mainly VB.Net (hint) Having said all that, I don't see why, once you get started, and somewhat understand the basics, you don't also try C#. It's not a One or the Other type of situation. If you know both, you become more knowledgeable. Therefore, at that point, if you want to stick with one or the other, you can make your own decision based on what you've learned yourself. David Wier http://aspnet101.com http://iWritePro.com - One click PDF, convert .doc/.rtf/.txt to HTML with no bloated markup >> I would suggest you begin with C#, for no other reason that it will force >> you to think in an object-orientated .NET way and prevent you from [quoted text clipped - 31 lines] >> ASP Classic?", then have a five-minute break and approach the problem >> again from the beginning... :-) My two sides of the coin are: If you have a asp/vb6 background..then Side 1 : You'll be more used to using the "dim x" syntax. You'll get "on board" slightly quicker. Side 2 : You'll be more likely to bring bad habits with you, most of which resolve around non OO practices. Creating a billiion concrete classes is not OO development. And asp.net is NOT an upgrade or extension of asp. Accept that truth early, and you'll get on board faster. Here is an article to look at: http://www.cmswire.com/cms/featured-articles/not-another-c-versus-vb-article-000 591.php Its your choice ultimately. The last small tid-bit thing is.... google searches. When you search for C# tidbit and syntax, you'll only have to filter through 1.1 vs 2.0 stuff for the most part (ok, maybe 3.0 and 3.5, but 3.0 and 3.5 are more extensions of 2.0). which isn't that hard. When you do a syntax search for vb/vb.net, you'll have to wade through 10+ years of vb snipplets (non vb.net stuff) to find the vb.net stuff you're looking for. To put it another way, it is (IMHO) easier to find what you're looking for when faced with an issue...googling C# syntax. Heck, sometimes ...4-5 years ago when I did vb.net, the only way I could find .Net specific stuff was to artificially translate my snipplet into C#...to avoid that "google overload syndrome"........ Last advice: If you're ever interested in anything like WCF....or similar (more 3.0 and 3.5 stuff), then most (not all but most) examples are in C#. And you will save time...because you don't constantly have to artificially translate the syntax every single time you find a great C# snipplet. This was finally the thing that I said "Ok, c# it is", because I got tired of translating samples into vb.net just for the sake of translating samples into c#. And after I used c# for 2 months......it was over. The language feels "cleaner" to me. (Which I would say you can figure out why alot of people feel this way from the article above "not another". The article above isn't perfect, but I like the historical aspect of it. Good luck with your decision. > Hi, > [quoted text clipped - 9 lines] > > Thanks and regards > My two sides of the coin are: > [quoted text clipped - 28 lines] > find .Net specific stuff was to artificially translate my snipplet into > C#...to avoid that "google overload syndrome"........ Now this is certainly true. And I agree. It's a good point. Although sometimes all that old VB classic knowledge base on the web comes in handy too..... especially when you find that the .NET framework doesn't do something you want and you need to use Win32 API's via p/invoke. Lots of old good stuff there.... no C# examples. :) > Last advice: > If you're ever interested in anything like WCF....or similar (more 3.0 and [quoted text clipped - 9 lines] > "cleaner" to me. (Which I would say you can figure out why alot of people > feel this way from the article above "not another". I agree here too. C# is definately aesthetically cleaner than VB. It's not always easier to read, but it is sparse ... while VB is verbose. I hate having to type CType or DirectCast instead of C's beautiful casting way. But even here too when I'm reading discussions on this topic (I lurk a lot), C# folks' ignorance rears its ugly head... when, for instance, they call VB's casting "function calls" (they're not... the compiler treats them as inline casts... just like C#..... we just have to type a little more to do it. :) > The article above isn't perfect, but I like the historical aspect of it. > [quoted text clipped - 14 lines] >> >> Thanks and regards > Side 2 : You'll be more likely to bring bad habits with you, most of which > resolve around non OO practices. This is probably the best argument against VB. Nothing was worse than working with a bunch of programmers that went from VB6 to .NET with no learning at all. Every single horrible thing they could do in VB6 (it was bad then too) went directly over to .NET. When you force yourself to learn a new language you can to wield it the correct way from the beginning dumping those bad habits from the beginning rather than "knowing" how you can do something and it be bad. This is even more true with VB since they carried over the functions from older versions into .NET (i.e. LTrim() Mid() cInt) whereas the .NET way is different. The advantage to going to C# and having a VBScript background is you should be able to read/write VB.NET fairly from knowing C# and VBScript while it doesn't work as well the other way (only VB with no C# learning). > beginning dumping those bad habits from the beginning rather than > "knowing" how you can do something and it be bad. This is even more > true with VB since they carried over the functions from older versions > into .NET (i.e. LTrim() Mid() cInt) whereas the .NET way is > different. But, see, this is what I don't get. And I think C# folks put out a lot of misinformation about this. Mid, Trim, etc. are suppossed to HELP. They have no functional equivalents in .NET. No, Substring(...) isn't the same because 1) you need to make sure the string isn't a null reference first, and 2) exceptions are thrown if you pass values larger than the string. So everytime you'd like to do the equivalent of Left(...) you have to do: if (str != null) { if (str.Length >= 6) { str2 = str.Substring(0, 5); } else { str2 = str; } } else { str2 = string.Empty; } How does that beat Left(str, 5)? Ah. You can write your own function, sure. But, I can't count the number of different times I've seen this done 3 different ways by 3 different C# developers in the SAME project who didn't realize another developer had already written it. That's BAD. And what's this .NET way for CInt that mention? All CInt is shorthand for CType(var, Integer)... which is a more robust inline compile operator (a cast, not a function call) that mimics System.Convert(object, IFormatProvider) (a function call). The VB way produces faster msil than the equivalent. Signature-C. Moya http://www.cmoya.com >> Side 2 : You'll be more likely to bring bad habits with you, most of >> which [quoted text clipped - 13 lines] > knowing C# and VBScript while it doesn't work as well the other way > (only VB with no C# learning). >> Side 2 : You'll be more likely to bring bad habits with you, most of >> which >> resolve around non OO practices. what nonsence very weak argumnet > This is probably the best argument against VB. they the argument is lost >Nothing was worse than > working with a bunch of programmers that went from VB6 to .NET with no [quoted text clipped - 9 lines] > knowing C# and VBScript while it doesn't work as well the other way > (only VB with no C# learning). Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.