Related
I'm going to migrate my Android application into WP7 platform. Android one contains heavy enough calculation stuff (encryption/decryption), plus extensive usage of DB (SQLite) and some graphics (simple) and I'm trying to figure which language to select: either C# or VB
I have some experience both in C# and VB.net, but can't decide which one to select, any clues?
I would recommend C#, based on a couple of factors:
I assume the Android application is written in Java. Between C# and VB, C# is the most similar.
If you are doing lots of calculations, C#'s more terse syntax will probably make the code easier to read. VB is more verbose and thus tends to produce more clutter.
Since you are new to the platform, you will definitely find a lot more resources with C# code examples than with VB.
I went from VB.net to C# and wouldn't ever go back through my own choice!
Aside from the technical differences (see here for just one comparison), it's my personal opinion that C# is more readable, fluent and just plain better.
Do a search on google for heaps of comparisons on why one is better than the other. At the end of the day it's your personal preference... try both and see which you prefer.
There are no technical benefits or drawbacks to choosing either language; the complete set of APIs and platform features are available to you whether you choose C# or VB.NET, so it comes down to whichever you are most comfortable with or want to spend more time with.
The only thing that might sway it one way or another is that (in my opinion) there are more samples, blog posts, and general help written in C# than VB.NET, but that's about the only differentiator I can think of.
If you aren't particularly familiar with either then definitely use C#. By far and way the vast majority of code you will come across in the Web and in books on Silverlight will be written C#.
I'd go with C#, it's a far more popular language. Furthermore, Java to C# is an easier transition.
Edit:
Popularity of a language make's it easier to find information and perhaps more importantly, quality developers.
Choose the language you are more comfortable with.
I would suggest c# because it's more similar to java. So maybe you will manage to save code structure.
C# for sure. C# is a lot more alike Java, and syntax alike much more compatible.
Next to that C# is more popular so more resources for it, and because of the extra time they spend on C# the compiler slightly generates higher performance MSIL.
If you know Java you'll find C# very comfortable to transition to and work with, especially if you're having to maintain older Java code as well as working on the new project. I've worked in situations where I had to work with VB6, VB.NET and C# code within the course of a day and it can be tricky to remember not to use or to use semi-colons or that the variable type goes first or last.
I started my career coding in C/C++ on a vax system, but got into a few contracts where it was all VB and then became a specialist in VB, then to VB.net. Now I am aspiring to work for Microsoft and it seems that every job they post is in C/C++/C# and I can barely read C# code, it looks like the most convoluted mess to me and the inline syntax almost hurts my feelings.
I am looking for positive, non-flaming, helpful suggestions on how to pick up C# skills again. Books..Labs..etc? I have been coding simple projects using Silverlight and C# to try and work it out but it is extremely frustrating since there are very few examples that I can find that illustrate what each code set looks like. I've Googled but have yet to find anything helpful other than channel9 labs and working through some of the example code/projects from mix10.
I am not looking for a shortcut, but a good solid skills understanding. I swear it is easier to translate English to Latin than VB to C#.
I personally would start by converting a VB.NET project into C#, having done VB.NET it wouldn't be difficult once you got started as they both use the same underlying CLR.
Doing it this way step by step, looking up how to convert each bit you don't understand, you'll soon end up teaching yourself C# based on you're knowledge of VB.NET and you'll see they're really not that much different!
I find them very similar now I know them both, they just have a habit of doing things 'slightly' differently.
Also, have a look at this wiki page for a summary comparison of VB.NET and C#, and check out the examples at the bottom to see some basic syntax comparisons that will give you a starting point for converting VB.NET into C#.
Since VB.NET and C# are both first-class object-oriented .NET languages that compile down to the nearly the same CIL code, I find it fairly easy to switch between the two. Most of the learning curve in .NET comes from learning the myriad APIs; syntax doesn't take terribly long to pick up.
I'd recommend a good book that focuses on the language of C# (that is, not a framework such as Winforms, Silverlight, or WPF). A book that I really liked was Illustrated C# 2008 by Daniel Solis. It's great at exposing the C# language from end to end. (NOTE: Although it says "Illustrated" in the title, it's not filled with lots of pretty pictures. "Illustrated" simply means that the author uses lots of helpful diagrams to explain concepts).
Also, I spent a good deal of time solving math problems at http://www.projecteuler.net in order to learn C#. It helps to have real problems to solve to learn a language and Project Euler offers problems that are small enough that you can still focus on learning different aspects of the language.
It's odd that you are having this difficulty if you can still remember anything about C. I have a similar background but I don't find C# hard to read at all.
Are you getting confused by LINQ or lambdas / anonymous methods? EDIT you say it's LINQ: here are some links for LINQ.
The LINQ syntax is different in VB from C# and there's not much help out there for the VB syntax. The MSDN 101 VB LINQ samples are good, and I also liked the coverage in the book Programming VB 2008.
Lambdas are a way of writing methods inline that might be the "inline syntax" you are referring to? In which case, just read up on them and try them out: you could try them out in C# or VB.Net.
There were some useful articles on differences between C# and VB.Net in Visual Studio magazine back in Jan 2008.
What VB developers should know about C#
And for completeness, What C# developers should know about VB
You might also be interested in the question "what's allowed in VB that is prohibited in C# (or vice versa)"
Full disclosure: the bottom part of this answer is copied almost unchanged from this question on converting C# knowledge to VB.Net
Buy "Head first C#" and enjoy yourself coding. It is the best book (according to me and a few others) on the market learning C#.
Scott Hanselman posts a regular column of his blog called the "Weekly Source Code", which is made of source code -- generally C# --- which you can learn from by reading.
My first choice is that given by W69rdy: convert some project you've already done in VB to C#.
Second, I would skim the C# documentation, or an online source like that suggested by James, at least once a day looking for something you don't understand. Perhaps something as simple as a language keyword you don't recognize. Then write something that uses it: even something as simple as a small snippet.
If you are looking for a quick read and tutorial, this one will work. I agree with #TechNeilogy and #W69rdy that converting a program from VB.NET to C# will help with understanding the similiarities and differences between the languarges.
I converted a VB.NET Windows service to a C# Windows service and it helped greatly with trying to learn C#.
I was a VB .NET programmer as well. I found that using Jetbrain's Resharper Visual Studio plug-in really helped my learning curve. I was initially converting/optimizing a VB .NET project into C# and I found the coding assistance tools really helpful. Most of the time, I was just trying to find the C# equivalent so code completion usually put me in the right direction.
I've also recently been moving to C# from VB - I've found this converter invaluable as a learning tool when you don't know a bit of C# syntax but you can write it in VB.
You should start with some C# tutorials in internet to understand the how to work with c#, then read a book with maximum 300 pages.
After that you can start the converting from VB to C#. It is not difficult.
Good luck.
I use both vb.net and c# at work. Sometimes in the same project even. Honestly, when you switch back and forth, after the first couple misplaced or missing ; or Dim's, it's pretty easy to jump between the two. The rest of the stuff (class modifiers, event handlers, etc.) is only a quick google away.
The only way you are really going to make the step across, is to just make the step across and run with it!
Sure, check out a basic tutorial or read a guide on C# to learn the syntax basics, but then you need to find a reasonably simple, self-contained project to get stuck into. If you know some of the .NET framework (which you presumably do), then the jump won't actually be that great. Obviously, don't pick a vast, complex, mission-critical system to start with!
In fact, although my current project is my first c# project, I can't believe I didn't make the switch earlier. Apart from enjoying C#, I'm also finding it easier because I'm finding there are more good quality examples around.
I don't mean this patronisingly, but the answer is to simply start coding in C#!
There are plenty of books, resources, training CDs (check out AppDev.com for some great video based training) but nothing compares to just coding for real-life problems!
(And I agree with a previous comment about converting a recent project to C#.)
"That which we learn to do, we learn by doing" Aristotle
We are an team that are dedicated C#, and will start with an new project, there the customer really wants it in VB.NET.
Are there a bad choice to do the development in C# and then convert it and deliver in VB.NET.
Are there any tools that will make this easier to us than any simple converter?
I wouldn't recommend using a converter for a whole project. They're OK for code snippets and perhaps a class at a stretch, but even with two languages like C# and VB.NET based on a common runtime there'll be things that can't be converted.
As I see it you have the following choices:
Convince the customer that writing the application in C# is for the best - it's the language you know and you'll be able to deliver a higher quality product in a shorter time.
Write it in VB.NET, but point out that it will take longer to deliver.
Don't take the project. I'm assuming that this is not an option, but I'm including it for completeness.
Each language has its unique features and specialties. It is an illusion to believe that code written in C# can seamlessly be converted to VB.net. If you do automatic conversion, you'll have to fix it manually afterwards (because it is unlikely that your project will compile) and it will have poor quality, look bad and not be optimized.
I think it is a bad idea to rely on automatic conversion if your customer wants a solution in VB.NET. The code written by an automatic converter will often use a bad coding style for that language - even if the end result is the same.
It might be OK to use an automatic conversion tool occasionally to aid the development process if you are unsure of the exact VB syntax for a C# construct. You should check the result of the conversion is a best practice in VB.NET and not just copy and paste converted code without reading it. Conversion tools can make errors or produce ugly code that a human programmer would not write. Code committed to the project should be reviewed, preferably by one of the team members with the most experience in VB.NET.
You should strive to use the best practices for VB.NET so that your customer can easily understand and maintain your code.
If you feel that your team is unable to complete the project to a high quality in VB.NET then as ChrisF mentions you might want to consider:
Declining the project.
Convincing the customer to accept a high quality C# solution instead of a low quality VB.NET solution.
Alternatively you could try to gain the competences in VB.NET you are currently missing. Some examples of ways to approach this:
Attending courses on VB.NET so you at least know the basics.
Buying and reading books about programming in VB.NET.
Employing a new team member with VB.NET experience.
Using a consultant in the initial phases to help start your project and review code until your team is able to produce high quality VB.NET code on its own.
Attempting a smaller project in VB.NET first to gain some experience.
Are there any tools?
Kind of. I don't like any of them, as they don't look "trustworthy", but you can try your luck:
http://www.developerfusion.com/tools/convert/csharp-to-vb/
http://www.carlosag.net/Tools/CodeTranslator/
http://converter.telerik.com/
Would I recommend simply translating VB to C# ?
No. Because you're forced to trust in a converter. VB really, really isn't that much of a stretch from C#. If you are doing simple things, it should be pretty easy.
Regardless of your reasoning, it is possible to do this. Use RedGate's reflector http://www.red-gate.com/products/reflector/ and Denis Bauer's disassembler http://www.denisbauer.com/NETTools/FileDisassembler.aspx. You can pick your language, and the code that comes out, while not exactly what you coded, should compile back to the same IL.
You can decompile your C# binaries with JustDecompile export it as VB.net project, load the project file in VS and build.
This, however, does not usually work out of the box as you may have to fix some minor issues like:
Anonymous Types
Indexers
reimplement "unsafe" code
As you can adjust your (existing) C# test project to test the converted project along with your original implementation.
After fixing that you have the advantage to know your VB builds and runs well, which cannot be guaranteed by any automatic converter.
At a colleague's workplace, a decision is trying to be made about whether to use both languages in the workplace or to standardize on one? There are some VB.Net developers and some C# developers.
What advantages or disadvantages would there be to using both or to using one?
Edit: To clarify this question, the question is not asking the advantages of one over the other, rather what are the advantages/disadvantage of standardizing on both languages versus standardizing on one.
For instance, one point could be that C#/VB.Net may have more third party tools available and hence it may make sense to standardize all developers on that language.
We should probably put on our Reality Glasses for this discussion. It's not just Syntactic Sugar going on here.
You will find that you can write code very quickly in Visual Basic.NET. That is largely due to some features that it has that C# does not yet provide: namely, the My namespace, which provides a plethora of functionality that C# developers have to frequently code by hand. (And that's a damned shame, if you ask me.)
I code in both languages every day. Coding event handlers for forms in Visual Basic is a snap, and it's VERY obvious what methods handle which events. It's not always as clear in C#. On the other hand, you can't always be as explicit in Visual Basic as you want to be, because Visual Basic does so much of the work for you. C# has the advantage of just getting the heck out of your way, and letting you get down to the nuts and bolts. Quite often, that's extremely liberating.
VB will let you invoke static/shared methods on an object instance. C# won't. You'll learn that the hard way when you try to port your code. C# will complain about unreachable code; VB doesn't care one way or the other.
But under the hood, when you get right down to it, it's all .NET. It all compiles down to MSIL. There will be minor differences. Visual Basic, for example, doesn't care about the case-sensitivity of names, where C# does. And the big gotcha there is that the CLR does as well. You'll realize that when you try to use reflection. Does that mean you shouldn't use VB? Nope. Just make sure you case things consistently -- especially your namespaces. (Namespace "My" and namespace "my" are two completely different namespaces to C# and the CLR, but they're the same to VB.)
Choose the language that makes you most productive, that reduces ramp-up time and maintenance costs. You may find that that means working with both languages. (We do!)
EDIT TO ADDRESS OP'S EDIT:
Refactoring tools are available for both languages.
Automated unit testing tools are equally applicable.
3rd party controls are going to be available for both languages because they're compiled down to MSIL.
Now, for IDE productivity tools, the one thing that C# has at this time that VB doesn't is StyleCop. That may change soon (and I hope it does), but I don't view it as a roadblock by any stretch of the imagination.
This is personal experience mixed with workplace lore:
VB.NET is capable of being little more nimble, compared to C#, because there isn't a standards committee (except for any that may exist at Microsoft).
Most of the Google-able code hackery out there is done in C#, and most of the best resource books provide code samples in C# only.
VB.NET is tainted with a history of VB being accessible to even the most incapable of developers. This is unfair, imho, because VB.NET is much more a "real" language. But the taint isn't going to be washed away any time soon, and "real" programmers still generally despise it.
As for real life - I code in my own time in C# and VB.NET at work. I believe that because so much of the code one writes for .NET is calls against the framework objects, the differences are actually quite small. If you can declare variables in both languages you're 80% to being portable. If you understand the framework, the syntax of the languages is a small obstacle.
EDIT to directly answer your question: We happily use both (though mainly VB.NET) and haven't ever had any problems. We use Visual Studio which allows us to pretty freely mix code files/assemblies. I would encourage you not to limit to a single language - I think some diversity is good for the brain.
My workplace had traditionally been a VB.Net shop, but a decision was made a couple years ago to switch to C#. This happened mostly because the VB developers had either left or moved into other positions and most of the new hires preferred C#. We still have a large legacy VB.Net code base, but all new development is being done in C#.
I don't think there's a strong technical reason to choose one language over the other, as they are pretty equivalent in functionality, but I do feel there are some valid reasons to choose one type of developer over the other. While I believe VB and C# are equal, there's is the unfortunate perception that C# developers are better than VB developers. While there is some justification for this, it's overblown. (It was more applicable in the C++/VB days.) That said, the perception exists. This does cause some talented developers to avoid and bash VB (though they usually do so from ignorance). I do think it's harder to hire developers into a VB shop than visa versa, because a C# developer will often balk at the idea of having to use VB, but VB developers usually aren't as opposed to using C#. There is one significant disadvantage to choosing C# over VB and that's that C# developers generally get paid more.
In my experience, the best developers welcome using both languages. The more languages you know, the better.
After tracking your question for a little bit and noting your edit, I have to wonder if you're fishing a little bit...
Either way, I think it's fairly obvious that at least the latest third-party tools favor C#. I, like the other responders, code VB for work and prefer C# for other development. I have definitely noticed that the documentation for many third-party addins/plugins and in some cases the products themselves favor C#. ReSharper, even though 4.5 has better VB support, is still vastly more comprehensive when using C#. And other frameworks, like Fluent NHibernate, don't support VB at all. So for tooling, especially when considering late-breaking stuff, I believe that C# wins. Not to mention the fact that C# got a few new features in 3.0 that won't be available until VB 10 makes a wide release.
I still agree whole-heartedly with the others; if you can do it in C#, you can do it in VB. It's all the same CLR, in the end.
I'd say given that there are "some VB.NET developers and some C# developers," there really is very little benefit to forcing everyone to use one language. Frankly even a VB.NET developer who's never looked at C# should be able to read C# code with no more than a brief introduction to the syntax, assuming he/she has a reasonable understanding of the .NET framework; and a C# developer should be able to do the same with VB.NET.
(I should also add: this is assuming everyone has access to a development environment in which the .NET languages can co-exist harmoniously -- e.g., VS2005, VS2008, etc., as opposed to one of the Express Editions, which as far as I know don't allow multi-language solutions.)
Don't fall for the "most examples / books are written for C#". Working out how to apply a C# example to VB.NET is trivial -- you'll have more trouble trying to understand what the moron who wrote the example / book is trying to do and what their hideous coding (un)convention is all about than you will mentally flipping C# syntax to VB syntax.
Also I'd say don't worry about whether you hire C# or VB.NET programmers: if they are any good at all then they won't have a problem with reading / writing both languages.
We use both here, and after a little resistance from some (we were using C++ before) have settled down fine. As I had predicted, the hardest thing for our team was (and probably still is) the conversion from MFC to .NET, not the language used to access the libraries.
FWIW our main split is VB.NET for UI code, and C# for backend / database / computation code.
C# and VB.net are the same with a different syntax. You can convert from C# to VB.net and back very easily.
VB.net does have a few extra advantages that C# does not, such as inline XML.
Most places have C# because its the more popular language.
I started out as a VB developer so naturally I migrated to VB.Net when I first worked with .Net. In fact my first .Net application was made in VB.Net too. But I tried out C# and found myself liking it better in a matter of weeks.
So I made some of that app in C# (some libraries) and it didn't hurt me. Now though I hate going back to the older VB.Net code and working on it. I really wish I could change it all to C# somehow.
That's not going to happen.
So what I am telling you here is, irrelevant of what language you choose (VB/C#) stick to it. Don't do mixed language development unless you have a compelling reason I can't think of yet :)
The advantage of standardizing on a single language is that basically everyone will have 1/2 as much to learn. I think it's better to spend the time learning more features of .NET, within a single language, rather than learning 1/2 the features in both.
As far as hiring goes, it does not really restrict you as a good VB or C# programmer should be able to switch to the other language without difficulty (or else they aren't really a good programmer :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have just moved job and gone from VB 6 to VB.Net and found the learning jump fairly steep, have more a problem with the object / conceptual side of things .. but getting there now ... but as I was a assembler / C++ 10/15 years ago and was considering learning C++/C# .Net (XNA games library calls my name) but not sure if it would hinder my VB.NET learning .... or should I just get myself certified
I was (back in the day) a VB6 dev, and I would expect it to help. There is a much-commented tendency for VB6 developers to keep writing VB6 in .NET; even just a brief look at C# might help you think about VB.NET as a .NET language, rather than a Visual Studio 6 ancestor.
Of course, you might find (as I did) that you don't want to go back to VB.NET after C# ;-p
But as has already been mentioned - the framework is identical. And with C# 4.0, many of the differences will become even less (with "dynamic" making it easier for C# to talk to late-bound COM, and the named arguments / auto-ref stuff making it easier for typed COM).
There is a lot of drive for converging the feature sets of C# 4.0 and VB.NET in VS2010
To me the biggest obstacle for .NET is learn what is available in the framework. Therefore, if you find it easier to code in C# it will mean you only struggle with one thing instead of two. Once you know the framework it's just syntax really as 95% of the stuff you can do with C# can be done with VB.
Also, C# will force you to write code in a more object orientated manner as you can't fall back to coding in a VB6 style.
'yield return' is an example of something that doesn't have an equivalent in VB9 (there are rumours this is being added for VBX though).
Apart from the fact that a large part of what you need to know is about the Frameworks's libaries learning another syntax that targets the .NET's CLR is useful.
Seeing how another language expresses the same concepts helps you to separate the concepts from the language. This is always useful because the concepts are fairly constant, (for example a shadowed(VB) or hidden(C#) function) whilst different languages use different words to express them.
Understanding the concepts better will help you to utalise them when designing code.
IMX, learning C# helped me with learning VB. It's something about seeing the same concepts expressed in 2 ways rather than just 1.
EDIT: Anthony Jones beat me to it :-)
Well for one thing if your method does not return anything then you have to create a Sub in VB.NET and if it returns anything then call it a Function!
I just switched from C# to VB.NET (client requirement) and am still getting used to its nuisances :(
I would say coding in VB almost takes the OOPS out of .NET
I was also a VB6 developer before switching to .NET. First I tried to use VB.Net but it never felt comfortable so I tried C# and fell in love with it. :-)
There are some differences as noted in the previous replies, there are things you can do in VB.Net that you can't in C# (like indexed properties) and vice versa. But apart from that the differences are purely in the syntax. There are in fact several available translators that will convert C# to VB.Net and back.
So I would recommend you to try out C#. Since you know some C++ it shouldn't be very hard to get the syntax right, and the rest is learning to use the framework.
The only real hindrance learning C# would have to VB is documentation. There seems to be a lot more information out there for C# users and trying to find the VB equivalent syntax of sometimes pretty standard C# can be a pain.
That being said... it never hurts to know alot of different ways to do the same thing.
I agree with Garry, the biggest issue is the API.
The second biggest issue I have personally observed is VB6 developers writing VB6 code in VB.NET. That's a good reason in itself for VB6 developers to learn C# - it forces you to think in .NET style.
As a devoted .Net developer I have worked on big projects in both C# and VB.net. Having seen the strengths and weaknesses of both languages I have found VB to be the most frustrating at times.
The problem is that with VB (depending on your project settings) it will magically perform implicit operations such as casts. This can be helpful sometimes, but in the general case you do not want your code to do something unless you explicitly tell it to (this is how C# behaves, in an explicit manner). I would prefer a compiler time error to tell me I cannot convert from one object type to another rather than a runtime exception in our live deployment.
I have found that this implicit aspect of VB tends to hamper the "VB only" developer's understanding of what is going on behind the scenes. For these people, looking at C# seems to trigger some lightbulbs, where they say "aha!, that must be what VB is actually doing when I perform this operation".
I'd recommend you give C# a try, it'll give you a new perspective and you might find that you really like it.