 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / VB.NET / May 2008How easy is it to learn VB compared to C#?
How hard/easy is it to use/learn VB compared to c#? It's harder to learn VB well. This is due to the fact that VB offers more ways of doing most things. e.g., Setting the return value for a function - 2 ways (C# has 1 way) Wiring events to methods - 2 ways (C# has 1 way) String manipulation - 2 ways (VB 'legacy' functions vs .NET methods) Exception handling vs unstructured error handling (C# has 1 way) These are just examples - I could list a few dozen areas where VB offers multiple alternatives, sometimes based on a need to maintain legacy code. VB also has a few features not available in C# (such as XML literals and optional parameters), but C# also has some features not available in VB (unsafe code, anonymous methods, and iterators), so these kind of wash out.  Signaturehttp://www.tangiblesoftwaresolutions.com C++ to C# C++ to VB C++ to Java VB to Java Java to VB & C# Instant C#: VB to C# Instant VB: C# to VB Instant C++: VB, C#, or Java to C++/CLI > How hard/easy is it to use/learn VB compared to c#? What should you base the choice of what one to use off of? It's hard for me since I know a lot of c# but VB looks like plain old english sentence fragments to me and seems like it would be easier to understand than c#. > It's harder to learn VB well. > This is due to the fact that VB offers more ways of doing most things. [quoted text clipped - 13 lines] > >> How hard/easy is it to use/learn VB compared to c#? Speaking as someone who knows both fairly well and has worked in both a VB and C# environment I can say this. VB is generally easier to learn, the syntax is fluid for someone that doesn't want to learn a lot of technical terms. On the other hand C# isn't necessarily hard to learn, but it's strictness forces you to write stronger code. In all reality if you code VB without using the built in functions and with Option Strict on you'll be able to move between the two rather easily. I agree with cfps.Christian, But honestly it shouldn't matter too much which you start with. It's a matter of taste. Go seach for some code witten in each, and see how easy *you* find each to read. -- Rory I think I might give it a try and see how it turns out. Looks like I will be around for a little while ...:) > It's harder to learn VB well. > This is due to the fact that VB offers more ways of doing most things. [quoted text clipped - 13 lines] > >> How hard/easy is it to use/learn VB compared to c#? > How hard/easy is it to use/learn VB compared to c#? VB is a higher level language. SCNR ;) Barely - only if you consider 'unsafe' code. Other than unsafe code (used by a very small fraction of C# developers), I don't see how VB is higher level. You might be thinking of C. Signaturehttp://www.tangiblesoftwaresolutions.com C++ to C# C++ to VB C++ to Java VB to Java Java to VB & C# Instant C#: VB to C# Instant VB: C# to VB Instant C++: VB, C#, or Java to C++/CLI > > How hard/easy is it to use/learn VB compared to c#? > [quoted text clipped - 3 lines] > > ;) Andy, Depends on what you want to learn Programming: use C# as it is more strict with everything and does not automaticly change your typing mistakes, Learn to use a language to be productive: use VB as it does things that are time spending to do with C# in many cases in a more easy way. Just my opinion. Cor > How hard/easy is it to use/learn VB compared to c#? On May 29, 7:10 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl> wrote: > Andy, > [quoted text clipped - 11 lines] > > > How hard/easy is it to use/learn VB compared to c#? I agree, C# is much more strict in the way it enforces rules. I would say it would be very beneficial for new programmers to use C# and get a hold on how things should work and prevent many "stupid" mistakes (like implicitly returning value types and dumb casting errors). However, once you have a firm grasp on how to program, I feel VB (especially in VS 2008's IDE) makes it much, much easier to crank out code. It just seems to flow better and is much more natural to write. Thanks, Seth Rowe [MVP] > On May 29, 7:10 am, "Cor Ligthert [MVP]" <notmyfirstn...@planet.nl> > wrote: [quoted text clipped - 25 lines] > > Seth Rowe [MVP] I disagree. I think since vs2005, the C# editor is much more friendly. Even the autoimplement stuff seems to be a little bit nicer in C#. That's my opinion of course... The guy that LIKES case sensitivity. SignatureTom Shelton Tom, > That's my opinion of course... The guy that LIKES case sensitivity. Have a look at VB, there it is automaticly set in the right case. Kidding of course. :-) Cor It's hard to tell as for example it depends on what you already know and as personal preferences comes also in play... IMO your best bet is just to start both and pick the one you prefer. The more languages you know, the more asily you'll learn a new language (i..e. on a logner term you may want to use one as your primary, nknow the second enogh to be efficent plus perhaps JavaScript if you are doing web development etc...) -- Patrice "Andy B" <a_borka@sbcglobal.net> a écrit dans le message de groupe de discussion : ##UP5GUwIHA.4492@TK2MSFTNGP02.phx.gbl... > How hard/easy is it to use/learn VB compared to c#? > How hard/easy is it to use/learn VB compared to c#? In my opinion definately VB.NET rocks when compared to C#. There are easier (sure, almost every language has difficulties to learn of course like VB, but that's comparison with C#) and shorter ways to do the same thing in VB with less error-risk, especially because of not being case-sensitive, however both languages have some differences, no need to extend with these differences which are available and can be googled easily through the net. However, in my opinion, also not tested 2008 yet, VB 2005 IDE is much more developer friendly when compared to VC# 2005. Background compiler(real-time compiler in design mode) of VB 2005 brilliantly more accurate than C# IDE. In VC# 2005, you have to wait much longer to see if there are coding errors in error list at the bottom of the screen even for a semicolon mistake, plus you have to "build" your project for once if there are additional errors to be reported in error list, before starting debugging. In VB 2005 IDE i haven't had such problems, almost never. And also typing performance intellisense is a bit slower in C# than in VB on the same PC. Just my thoughts, Regards, Onur Güzel Frankly I like both. Some on our team pick VB, some pick c#. Those that pick c# tend to have tasted java or c in their past. Maybe that makes an easier migration. At least it should. Out of curriosity, why didn't you crosspost to the c# group? > How hard/easy is it to use/learn VB compared to c#? Hello Family, > Frankly I like both. Some on our team pick VB, some pick c#. Those > that pick c# tend to have tasted java or c in their past. Maybe that > makes an easier migration. At least it should. If we could create MultiLanguage projects, then this problem would go away. http://rorybecker.blogspot.com/2006/09/i-want-multi-language-projects-in.html The need to create a new project and therefore a new dll is massive overkill just to be able to use the features of another language. > Out of curriosity, why didn't you crosspost to the c# group? Probably didn't want to start a(nother) religious war :) -- Ror That's an interesting concept in your blog. We've been happy compartmentalizing our dlls fairly well (I hope...). I wouldn't recommend taking too far though. I could imagine someone wanting the next logical step, the following: #region "Language=c#" string message; int index; #end region #region "Language=vb" for index = 1 to 5 step 2 message = message & index.ToString() next #end region > Hello Family, > [quoted text clipped - 15 lines] > -- > Rory Hello Mike, > I wouldn't recommend taking too far though. I could imagine someone > wanting the next logical step, the following: [quoted text clipped - 8 lines] > next > #end region Yeah I could see that being a mess. I'm all up for partial classes of different languages though -- Rory > Hello Family, > [quoted text clipped - 15 lines] > -- > Rory Rory, I'm sure you know, it is technically possible to create multi-language assemblies - there just is no support in the ide. You have to compile from the command line to accomplish it. The problem is that, I just don't really see the point of it. There have been precious few times when I have wanted to mix languages, and solution level support was more then adequate. The only time, that I can really think of is using VB.NET for office automation, simply because it is much easier and cleaner to use VB.NET for late-bound scenarios - though, it looks as if that might change in C# v4. I just don't see this as a feature that many developers will be clamoring for. SignatureTom Shelton >> Hello Family, >> [quoted text clipped - 31 lines] >I just don't see this as a feature that many developers will be >clamoring for. I write mainly in VB.Net, but sometimes I just need to use those darn unsafe pointers (for just a few functions) and there is no substitute (that I know of) for those in VB.Net so I have to create a separate project/dll and use ILMerge in a post-compilation step if I do not want to distribute yet another dll :( /Joergen Bech Hello Joergen, > I write mainly in VB.Net, but sometimes I just need to use > those darn unsafe pointers (for just a few functions) and [quoted text clipped - 3 lines] > another dll :( > /Joergen Bech Annoying isn't it. Someone correct me if I'm wrong.... Isn't XAML another language whose forms are compiled into the dll along with C# Or VB.Net? Surely XAML compilation isn't done by both CSC and VBC? Isn't there a middle tier to the compilation already somewhere? -- Rory >Hello Joergen, > [quoted text clipped - 16 lines] > >Isn't there a middle tier to the compilation already somewhere? XAML is compiled into BAML using xamlc.exe. At the same time, this compiler generates a partial class using your favorite language. This partial class includes fields for the window, code loading the BAML, code that connects handlers, etc. After that, the csc or vbc takes over. Well, at least that was how it used to be. I believe it is all handled by MSBuild nowadays, but similar stuff happens behind the scenes. Regards, Joergen Bech Hello Tom, > I'm sure you know, it is technically possible to create multi-language > assemblies - there just is no support in the ide. You have to compile > from the command line to accomplish it. Absolutely. I'm also aware that there are command line tools to allow me to use GIT(Source Control) aswell as SVN. However the jump from SVN to GIT is considerably harder given that most of my shop uses TortoiseSVN. once TortoiseGIT becomes available I will see it as a reasonable alternative. I have to wait because I cannot afford the time to spend training me and the rest of my team on a concept that is so far from what they are already used to. Especially with everything else there is to process. Likewise Notepad and csc.exe or vbc.exe can be used but let's be fair, > 90% of us are using Studio. > The problem is that, I just don't really see the point of it. There > have been precious few times when I have wanted to mix languages, and > solution level support was more then adequate. I'm sure that's the case for you, but the languages will always be uneven. For example (IMHO): VB.Net could really deal with a Yield Keyword. C# could really deal with inline XML Support. Is MS really suggesting that I should have to choose ahead of time which of these I should choose to make available to myself? They are each concepts which force me to make a choice. I just feel that I should not have to make that choice. Even if each language should develop the feature that the other one is currently missing in the next version then there will be something else missing. I would have nothing against this if I were able to mix languages inside a given project. I'm not asking for multi-language files, just the ability to add .vb files and .cs files to the same project would be fine. Ok yes I would love to be able to have different language partial classes, but I could go without those if I had the basic version. Any sensible .Net programmer will recognise that there are relatively few differences between C# and VB.Net to make understanding one when you know the other fairly trivial. So why not include this as an optional possibility. You have stated that you don't think there is demand enough, and on this I agree. I do however find it unfortunate. I am curious why though, it has been possible in many languages in the past, to write inline assembler. Why was this feature deemed worth and my suggestion, not so? I would argue that both VB.Net and C# are, shall we say, a tad more popular than assembler ever was? > The only time, that I > can really think of is using VB.NET for office automation, simply > because it is much easier and cleaner to use VB.NET for late-bound > scenarios - though, it looks as if that might change in C# v4. If my idea was implemented you wouldn't have to wait for C# 4 VS10 (I'm guessing mid 2009 at best) > I just don't see this as a feature that many developers will be > clamoring for. Again this may be true, but it doesn't mean it's a bad idea. -- Rory > Hello Tom, > [quoted text clipped - 53 lines] > > Why was this feature deemed worth and my suggestion, not so? I don't think it is an unworthy suggestion... Especially since it is supported at the platform level. I just don't think that there has been enough user demand for MS to develop this feature. > I would argue that both VB.Net and C# are, shall we say, a tad more popular > than assembler ever was? [quoted text clipped - 6 lines] > If my idea was implemented you wouldn't have to wait for C# 4 VS10 (I'm guessing > mid 2009 at best) At best... >> I just don't see this as a feature that many developers will be >> clamoring for. > > Again this may be true, but it doesn't mean it's a bad idea. Don't get me wrong, I'm not down on the idea. I might use it if it was offered. I just don't think that there is enough demand for MS to spend the resources on developing the feature. SignatureTom Shelton I am already somewhat experienced in C#. I have been using it for about 2 or so years now and feel that I would have enough background to base a VB comparison on. I haven't messed with VB though, and have no idea about its learning curve. I didn't cross post either, because of reasons that I don't think is right to say on a public list other than that whenever I post there, I get harrassed with the idea that my posts and/or questions are too vague and never do reach the point of "intellegence" or "accuracy". Guess they are too lame to post overthere for some reason. Sorry for the short lived vent, will get off my soap box now... > Frankly I like both. Some on our team pick VB, some pick c#. Those that > pick c# tend to have tasted java or c in their past. Maybe that makes an [quoted text clipped - 3 lines] > >> How hard/easy is it to use/learn VB compared to c#? Then I suspect you will have an easy time migrating to VB.Net. As others have said, just turn on Option Strict. I think it helps everyone avoid common mistakes. > I am already somewhat experienced in C#. I have been using it for about 2 or > so years now and feel that I would have enough background to base a VB [quoted text clipped - 13 lines] > > > >> How hard/easy is it to use/learn VB compared to c#? 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.