Related
I know this question could be similar to others but really I'm looking for reasons why VB6 developers should switch to C#.
My company recently approved project to be written in C#, so we have a lot of VB.Net programmers, however, we have some legacy app developers as well that are in VB6. We have a time frame to re-write those apps into .Net web apps. So no matter what they will have to learn new stuff.
One of the developers today specifically asked "why should we switch to C#?"
I responded that the community largely has decided that C# is the way to go with about 80% of the examples in C#. I am a VB.Net programmer and I am excited to finally cut my teeth on C#, however, being that I'm so new I'm not sure I can answer the "why?" question. My reasons are more because I want to learn it.
So without descending into a VB verses C# I really am curious if there are any resources that I can send to these developers to calm their nerves.
Looking forward to your input!
As far as the migration over to .NET goes, better late than never! As far as my advice goes, your mileage may vary, it's worth every penny you're paying for it!
I personally believe you are making the correct choice. The first instinct for VB developers is to switch to VB.NET. That sounds entirely reasonable, but in my opinion, it's the wrong choice. You really have to break down the reasons for the switch into two categories: Why switch to .NET, and why switch to C#?
Why switch to .NET over VB6:
Multithreading in VB6 is technically possible from a programming perspective, but just about impossible if you want to use the IDE.
I do not believe you can create a 64-bit native application in VB6. That rules out a lot.
No new enhancements are being made to VB6.
OK, there are so many reasons I can think of, I'll probably just stop there.
Why switch to C# instead of VB.NET
Developers may be lulled into a false sense of familiarity with VB.NET - treating resources like they did in VB6 without understanding the full concepts. An example: you often see new converts to VB.NET setting objects to Nothing, believing that it's a magical way to release resources. It is not.
It's true that most examples are now in C#. More importantly, Jeff Richter's book is only in C# now. If you want to understand how .NET really works, IMO his book is pretty much mandatory.
In .NET, you'll find that you will use lambda expressions all of the time, especially when operating with Linq. IMO VB's verbosity really becomes a barrier to comprehension and readability here, in ways where it simply wasn't before: foo.Select(x => x > 50) is, by just about any standard, much more fluent and readable than foo.Select(Function(x) x > 50). It gets worse as the expressions get more complex.
Some of the worst practices with VB6 are impossible or at least much less accessible in C# (such as ReDim Preserve and On Error Resume Next).
VB is saddled with some syntax which makes it pretty cumbersome and confusing to use when creating general-purpose CLR libraries. For example, in C#, you use indexers with brackets[]. In VB, you use parens. That makes it pretty difficult for the user of a subroutine to tell if it's an indexer or a function. If someone tried to use your library outside of VB, the difference would be important, but a VB developer might be inclined to create subroutines which should be indexers as functions, since they look similar.
I don't have any data on this, but if you are trying to hire a good set of programmers, the best ones will generally be less inclined to work in a shop which writes VB.NET over C#. They usually fear that the code their colleagues will be generating is likely to be substandard .NET code, and let's be frank here -- there's a stigma against VB.NET developers and the quality of their code in the community. There. I said it. Let the flames begin...
As a footnote, from my perspective, VB.NET was a real missed opportunity for MS. What it should have been was a way to seamlessly convert your old VB6 code to the .NET world - with dynamic invocation and high-quality COM interop from the start. What it ended up being was a near-clone of C#'s feature set with a more verbose syntax and little to no backward compatibility. Sad, really. It locked a lot of organizations out of .NET for a long time. Then again, maybe it forced a "cold-turkey" clean break from the past...
I've done a LOT of VB6 in the past, and a lot of C/C++, and when our big .NET migration happened I had no doubts that C# was the way to go. Having said that, what the VB6 guys should really be learning is .NET, and the CLR (a proper object-oriented runtime rather than a dumb COM front-end), and not a syntax. Focus on that, and sidestep the religious war.
This may not answer your question, in fact it may even contradict your response and prove your friend right, but here is a good list of the similarities (and differences) between VB.NET and C#:
C# / VB.NET comparison
As you go down this list, you will notice just how similar the two languages have become and with each new version, there may be less and less of a reason to switch. But, in the end, if you do make the switch, the Wikipedia article pretty much summarizes the advantages that C# has over VB.NET quite well:
Wikipedia article listing advantages of C# over VB and vice versa
The VB.net events syntax seems much nicer than C#; though the lack of any means for a class to either unsubscribe all WithEvents handlers to which it has subscribed, or kill all subscriptions other objects have to its events, makes it a little tough to avoid event leaks, it's no worse than C# in that regard.
Also, in vb.net, it's possible to have a Finally handler know what exception occurred (if any) in its Try block without having to actually catch it. If any exceptions occurs in the Finally block, the original exception can be included in the CleanupFailedException (along with the other exception(s) that occurred in the Finally block). That seems like a nice advantage.
"Developers may be lulled into a false sense of familiarity with VB.NET - treating resources like they did in VB6 without understanding the full concepts." (#Markle)
I haven't used this for an argument before, but it's a very good point. When I picked up a VB.NET app written by a bunch of new-to-.net VB programmers, it was littered with legacy compatibility calls to the old VisualBasic namespace. CStr(), VbNewLine, Mid(), etc... Working in a language which isn't designed to support legacy code conversion prevents the use of those relics. (So does removing the reference to the legacy namespace, FYI.)
I switch between VB.NET and C# pretty regularly. Whenever I go from VB to C#, I think "This is different, it'll take me a few minutes to adjust." Whenever I go from C# to VB, I think "This is an inefficient programming language; there's way too much typing required, how annoying."
I think the other answers have done a good job of covering the technical points. I would also point out to your vb6 developers that there are not only more books aimed at c# and more questions on SO on c#, but perhaps more importantly to them, more job listings as well.
A quick search on SO careers:
92 job postings for c#
11 job postings for vb.net
1 job posting for vb6
reasons why VB6 developers should switch to C#
Others have given technical reasons for C# over VB.NET, but I think you are dealing with a people issue, so I'll offer what I think is the most compelling reason why the developers should prefer it:
C# developers get paid more than VB.NET developers, for doing exactly the same thinking, just typing different source code after doing that thinking
Also
ReSharper for C# is better than ReSharper for VB.NET
Other than technical / social advantage is more business oriented,
Mainstream support for VB6 already ended and Extended support which is surely expensive would end soon.
Moving to a new platform in this case make more business sense.
Also the IDE is no more supported by microsoft so in case of issue you would be SOL, and installing it on shiny new laptop might provide an unenjoyable experience.
Note that they don't need to port every application, only deprecate the part that need to be replaced with com exposed .Net assemblies.
On the other hand having experience in porting software from obsolete platform to a new one will make these guys rich, providing they are willing to learn the new platform.
The biggest advantage C# has over VB6 proper has got to be inheritance.
(OK, to be fair it's my personal favourite, so I am totally biased.)
Other advantages:
Formal accessors
Exception types (I don't think VB6 has exception types, but please correct me if I'm wrong)
Generics
Lambda expressions
And the following are more related to the .NET platform than languages themselves:
Very rich library
Visual Studio refactoring and other goodies
Finally, the popularity argument is always icky (popular <> good), but it does give an idea of the community size of each and therefore what help is available out there and what the industry is going towards in general.
Questions on SO:
[C#]: 116,337
[VB.NET]: 11,740
[VB6]: 1,897
VB6 is not fully object oriented and lacks a decent set of collections/structures. VB.Net and C# are both fully object oriented and include a decent set of collection classes as a part of .NET. .NET 2 also added generics for even more flexibility.
I would agree with those who think VB.Net is a bit superfluous - it fixed the problems with VB6 and ended up being a bit of a "me too" alongside C#. Having said that, I do a lot of COM interop and find VB.Net's old fashioned ON ERROR construct a convenient way of handling timeouts and function retries. You can do it with try...catch just it is more complex.
Questions on SO:
[C#]: 116,337
[VB.NET]: 11,740
[VB6]: 1,897
That proves nothing.
VB6 existed long before SO did. All the good VB programmers learned what they need to know and MSFT had done away with VB6. Most of the new MSFT beginners flocked to C# because of their irrational hatred of anything BASIC (that still exits - just look at Xojo) and of course MSFT marketing.
But how do they feel now with C# getting short change compared to C++ on the Windows 8 platform? (eg XNA is gone).
The market pretty much demands C# over VB.net.
I'm not interested in starting another "who has the bigger member" VB vs C# debate (https://stackoverflow.com/questions/158229/what-are-the-pros-of-vb-net seems to cover that already) though I am interested in indirect differences which may influence developing in one vs the other. All my commercial .NET development was desktop apps in VB until the last 3 months where I had a web project and decided it was a good opportunity to force myself to learn C#. In the course of doing so I've noticed a few non-technical differences:
A lot more mature open source apps and thorough examples are available in C# than for VB.
Third party vendors of add-ins for things like refactoring and documentation tend to support C# better than VB (if at all), with VB support for similar features from comparable C# versions often lagging behind or absent.
ASP.NET jobs targeting C# seem to pay around 15-20% more on average than otherwise identical jobs in VB (at least in Australia, looking on seek.com.au and careerone.com.au for reference).
The jump to ASP.NET, MVC and C# presented a lot of speed humps at once but I think was well worth it. The decision I need to make now is whether to put more energy into pursuing C# for future .NET development or if I might as well stick to VB. Are there any other points of difference between the language (other than direct language feature comparisons already covered) that one should consider in this instance?
I find that VS does more automatic code completion for VB than C#.
It's very useful to know both languages and I personally have to get better acquainted with C# so that I'm comfortable applying for C# jobs which should triple my options.
At the Microsoft 2009 Mix Web
developer conference, all the
presentations that I attended
included code examples in C#, not VB.
In StackOverflow, notice how
questions tagged c# largely outnumber vb.net and
vb.
John Skeet wrote C# in Depth, not VB in Depth.
One thing that has been widely stated when I have participated in hiring (both as a hiring manager, as well as a candidate) is that C# and Java are close enough that converting a candidate from one to the other is fairly easy, and that this is not true for a VB.NET candidate to C#, or Java. This statement has even been extended to C++, saying training a C# or Java developer (to code in C++) is easier than a VB.NET developer.
Though I tend to disagree (I think it is more about how the person sees programming in general) I know that several large, reputable firms will accept candidates for C# or Java jobs that list C++, C# or Java experience. These same firms will in general not look at candidates who only list VB.NET, or list VB.NET as their primary language.
Specifically for web development, becoming proficient in C# made writing javascript (and doing complex things using jQuery) much easier because the syntax is so similar.
I agree with your points, particularly the first. I would add that it seems there are more C# developers out there than VB.NET. If you are looking to hire another developer, you may get more (quantity or quality) from the C# pool. And employers, perceiving that C# is more popular, will go in that direction, and there will be more demand for C# programmers (hence the higher salaries/rates you noticed)
I know that this is an old post but I'd like to add one other factor: all the new stuff gets done in C# first. This comes from my experiences with early WPF development. All the examples where in C# and we were working in VB.Net. It just took extra time to translate. Another example is lambdas, initially you could use expressions (single line) or statements (multi-line) in C# but only expressions in VB.Net.
When .Net was first rolled out, I think that there were a lot of VB6 folks who didn't really get .Net and that it was a whole different animal. I think that those people were partially responsible for the negative perceptions of VB.Net. But that was 10 years ago now and no longer a factor.
I've been jumping from C# to Java an awful lot and the "differences" between the two are a bit of an annoyance.
Would it be possible to write a set of extentions/plugins that would merge the two languages syntaxes.
I'm talking about adding either IDE support or using language constructs that would for example:
treat these two lines equivalently:
System.out.println("Blah");
Console.out.writeline("Blah");
Automatically notice that when you type in string you mean String
Recognise common API calls and translate them in the background.
The end goal being to be able to write a java/C# program and to pick at compile time which VM/Runtime you are targeting.
If you could do this would it be a good idea?
If not why not?
The two languages are so similar it's painful in some aspects but in other aspects they are really different.
I've seen Code that will translate a C# project into Java and I'm assuming there is probably the reverse, what I am proposing is a middle ground, so we can all just "get along".
No, absolutely not. Certainly not in the languages themselves (as implied by the title) and preferably (IMO) not in the IDEs (as requested in the body).
They are different languages. The idioms and conventions are subtly different. I don't want to be thinking in Java when I'm writing C# or vice versa. I believe developers should be actively encouraged to separate their thinking. It's not too hard to switch between the two, but that switch should be present, IMO.
While I totally agree with Jon Skeet, if you must have this why not create your own library of Java API so you can create System.out namespace which has a method call printLn which calls Console.Writeline()?
That gets you close to what you want.
Just because Java and C# share some similar syntax you need to see past this and think in terms of Java Platform and .NET Platform. The two are distinctly different, so my answer is definitely not.
There actually already is a Java language for the .NET framework, developed by microsoft: J#
This way you get the java-syntax but you are still developing with the .NET framework.
But i am not recommending anyone to use it.
I knew Java before i knew C# so i tried out J# because i thought it would be an easier transition. At first I liked it but after I tried C# I'm never going back. First of all, nobody uses J# so it's kinda hard to find examples and tutorials. Second, C# has (IMO) much more convenient syntax, specially for events, properties, lambda, anonymus methods and alot of other things, it's also being updated every now and then with even more syntax sugar which i don't think J# is.
Maybe if you often write Java and sometimes have to write a .net app it might be a good option.
I think no. I also switch from java to c#. But if the syntax is identical was is to stop someone from trying to compile c# in a Java compiler, or vice-versa.
Visual Studio actually ships with a Java to C# converter, which tries to do some of the things you mention. Unfortunately it fails miserably (1) for anything beyond the simple hello world application.
Despite being very similar on the surface, there are many significant differences between Java and C#, so you would achieve very little by doing what you suggest imo.
(1) To be fair, it actually does a fairly good job if you consider the limitations given for such a task, but in practice the resulting code is of limited use and you have to do a lot of clean up after the conversion.
Firstly what you are describing is not a difference in language syntax but a differences in class libraries. Both languages are relatively simple in terms of keywords and features but understanding or knowing the libraries and how they operate requires considerable learning.
The mistakes you are describing are things that the developer should not be making to begin with - the IDE should not be guessing. There are going to be many cases where you can't easily / trivially translate between java or dotnet. In the end a skilled developer learns and knows when and which class libraries to use.
Actually in the beginning there was no dotnet - microsoft was behind java. They however proceeded to change java in ways not compatible with the java plstform standard. To paraphrase sun sued microsoft and won I'm court. Following that ms proceeded to create dotnet and particularly c# which became microsofts VM platform. Of course along the way a whole stack of things got changed. Microsoft introduced many things which broke Javas run anywhere etc. They have done the same thing with dotnet which have cause problems for the mono team to be able to faithfully reimplemwnt everything for other non windows platforms.
• String vs string.
• lowercase method names (java) v uppercase method names(dotnet).
• Giving java keywords new names - "package".
In the end dotnet was microsoft response so they can control the platform and do their own thing instead of following a standar
I know Java well. Which caveats and resources will help me cross to the other side (C#) as painlessly as possible.
Biggest tip: go with the .NET naming conventions from the word go. That way you'll constantly be reminded about which language you're in. (Sounds silly, but it really is helpful.) Embrace the idioms of the language as far as possible.
There are various books specifically for folks in your situation - search for "C# for Java" in Amazon and you'll get plenty of hits. It's worth reading carefully to make sure you don't assume that things will work the same in C# as in Java. (For instance, in C# instance variable initializers are executed before the base class constructor body; in Java they happen after. Subtle things like this can take a while to learn, and are easy to miss if you're skimming.)
If you're going to be using C# 3, I'd get a book which definitely covers that - everything in C# 3 will be new to you. Gratuitous plug: my own book (C# in Depth) covers C# 2 and 3, but assumes you already know C# 1. (In other words, it won't be enough on its own, but you may want it as a "second" book.)
See this great article on C# from a Java Developer's Perspective. It has several insights on the things that can be done in both sides to avoid minimum overhead. Having example in both the language you know and the language you want to learn eases the learning curve quite a bit.
Install Visual Studio 2008 and Resharper with IntelliJ IDEA key bindings. This gives you things like prompting you to include namespaces if you start using them.
Start a new project and start writing Java code, when you run into something that doesn't work properly or it's unable to find the class you're trying to use Google "PrintLn in c#".
Write tests or code snippets for sanity checks, like you may want to check if == works for strings (it does)
realize that c# alias Data Types (int is an alias for System.Int32, string for System.String)
look at other peoples code I recommend JP Boodhoos Google code
Take a job in C#, there's lots of jobs requiring both Java and C# especially in support.
Know your libraries, most Java libraries have been ported and most of the time the name is either like (Hibernate => NHibernate) or (Xstream => Xstream.Net). Not every library has an obvious name so just start looking into random ones you hear about here. ie (Rhino.Mocks,HTMLAgilityPack,MBUnit,Rhino.Commons,Castle Project)
Go to usergroup meetings look for a DNUG (Dot Net User Group) they'll be helpful and you can get some good advice.
There's a cheat-sheet from Microsoft for Java developers using C# :)
I know that a good answer has already been accepted. However, I'd like to make an addition...
I find that learning a new language typically involves learning subtle syntactic differences....especially when dealing with the difference between languages in the C/C++/Java/C# family.
In addition to a nice thick reference book I recommend getting a pocket reference like C# 3 Pocket Reference from O'Reilly. It won't help you with the design patterns etc...but will provide a very quick reference about the specific differences of the language you are using.
Here's a quick blurb about this book from that site:
C# 3.0 Pocket Reference includes plenty of illustrations and code examples to explain:
Features new to C# 3.0, such as lambda expressions, anonymous types, automatic properties, and more
All aspects of C# syntax, predefined types, expressions, and operators
Creating classes, structs, delegates and events, enums, generics and constraints, exception handling, and iterators
The subtleties of boxing, operating overloading, delegate covariance, extension method resolution, interface reimplementation, nullable types, and operating lifting
LINQ, starting with the principles of sequences, deferred execution and standard query operators, and finishing with a complete reference to query syntax-including multiple generators, joining, grouping, and query continuations
Consuming, writing, and reflecting on custom attributes
I used this book (well the original) to help me go from being a Java to a C# developer. While I was learning, I kept it by my desk at all times and it really helped.
I made the transition pretty easily by using C# at work, but one of the most important things to do is familiarize yourself with the .NET API and some of the powerful techniques available in C#.
After I learned the .net library I relied on it a lot more than I used to, so learning about the things it can do for you is very helpful. After that, if you work with db code at all, learn LINQ, and also techniques lambas, anonymous types and delegates are also a useful to pick up.
The language syntax is vary similar, so I should only read a small reference of the C# syntax. Like a simple book (for experienced programmers) or maybe wikipedia (http://en.wikipedia.org/wiki/Comparison_of_Java_and_C_Sharp) will tell enough.
The biggest difference is the library: Asp.Net websites are totally different from java servlets.
Don't read much, just start programming!
Here's a link that has syntax comparison between Java and C# (even though it's almost identical, there are a few differences).
http://www.harding.edu/fmccown/java1_5_csharp_comparison.html
Use Sharpen to convert your Java programs to C# and see the differences.
I learned Java in college, and then I was hired by a C# shop and have used that ever since. I spent my first week realizing that the two languages were almost identical, and the next two months figuring out the little differences. For the most part, was I noticing the things that Java had that C# doesn't, and thus was mostly frustrated. (example: enum types which are full-fledged classes, not just integers with a fresh coat of paint) I have since come to appreciate the C# world, but I can't say I knew Java well enough to really contrast the two so I'm curious to get a community cross-section.
What are the relative merits and weaknesses of C# and Java? This includes everything from language structure to available IDEs and server software.
Comparing and contrasting the languages between the two can be quite difficult, as in many ways it is the associated libraries that you use in association with the language that best showcases the various advantages of one of another.
So I'll try to list out as many things I can remember or that have already been posted and note who I think has the advantage:
GUI development (thick or thin). C# combined with .NET is currently the better choice.
Automated data source binding. C# has a strong lead with LINQ, also a wealth of 3rd part libraries also gives the edge
SQL connections. Java
Auto-boxing. Both languages provide it, but C# Properties provides a better design for it in regards to setters and getters
Annotation/Attributes. C# attributes are a stronger and clear implementation
Memory management - Java VM in all the testing I have done is far superior to CLR
Garbage collection - Java is another clear winner here. Unmanaged code with the C#/.NET framework makes this a nightmare, especially when working with GUI's.
Generics - I believe the two languages are basically tied here... I've seen good points showing either side being better. My gut feeling is that Java is better, but nothing logic to base it on. Also I've used C# generics ALLOT and Java generics only a few times...
Enumerations. Java all the way, C# implementation is borked as far as I'm concerned.
XML - Toss up here. The XML and serialization capabilities you get with .NET natively beats what you get with eclipse/Java out of the box. But there are lots of libraries for both products to help with XML... I've tried a few and was never really happy with any of them. I've stuck with native C# XML combined with some custom libraries I made on my own and I'm used to it, so hard to give this a far comparison at this point...
IDE - Eclipse is better than Visual Studio for non-GUI work. So Java wins for non-GUI and Visual Studio wins for GUI...
Those are all the items I can't think off for the moment... I'm sure you can literally pick hundreds of items to compare and contrasting the two. Hopefully this lists is a cross section of the more commonly used features...
One difference is that C# can work with Windows better. The downside of this is that it doesn't work well with anything but Windows (except maybe with Mono, which I haven't tried).
Another thing to keep in mind, you may also want to compare their respective VMs.
Comparing the CLR and Java VM will give you another way to differentiate between the two.
For example, if doing heavy multithreading, the Java VM has a stronger memory model than the CLR (.NET's equivalent).
C# has a better GUI with WPF, something that Java has traditionally been poor at.
C# has LINQ which is quite good.
Otherwise the 2 are practically the same - how do you think they created such a large class library so quickly when .NET first came out? Things have changed slightly since then, but fundamentally, C# could be called MS-Java.
Don't take this as anything more than an opinion, but personally I can't stand Java's GUI. It's just close enough to Windows but not quite, so it gets into an uncanny valley area where it's just really upsetting to me.
C# (and other .Net languages, I suppose) allow me to make programs that perfectly blend into Windows, and that makes me happy.
Of course, it's moot if we're not talking about developing a desktop application...
Java:
Enums in Java kick so much ass, its not even funny.
Java supports generic variance
C#:
C# is no longer limited to Windows (Mono).
The lack of the keyword internal in Java is rather disappointing.
You said:
enum types which are full-fledged classes, not just integers with a fresh coat of paint
Have you actually looked at the output? If you compile an application with enums in in then read the CIL you'll see that an enum is actually a sealed class deriving from System.Enum.
Tools such as Red-Gate (formerly Lutz Roeder's) Reflector will disassemble it as close to the orginal C# as possible so it may not be easily visible what is actually happening under the hood.
As Elizabeth Barrett Browning said: How do I love thee? Let me count the ways.
Please excuse the qualitative (vs. quantitative) aspect of this post.
Comparing these 2 languages (and their associated run-times) is very difficult. Comparisons can be at many levels and focus on many different aspects (such as GUI development mentioned in earlier posts). Preference between them is often personal and not just technical.
C# was originally based on Java (and the CLR on the JRE) but, IMHO, has, in general, gone beyond Java in its features, expressiveness and possibly utility. Being controlled by one company (vs. a committee), C# can move forward faster than Java can. The differences ebb and flow across releases with Java often playing catch up (such as the recent addition of lambdas to Java which C# has had for a long time). Neither language is a super-set of the other in all aspects as both have features (and foibles) the other lacks.
A detailed side-by-side comparison would likely take several 100s of pages. But my net is that for most modern business related programming tasks they are similar in power and utility. The most critical difference is probably in portability. Java runs on nearly all popular platforms, which C# runs mostly only on Windows-based platforms (ignoring Mono, which has not been widely successful). Java, because of its portability, arguably has a larger developer community and thus more third party library and framework support.
If you feel the need to select between them, your best criteria is your platform of interest. If all your work will run only on Windows systems, IMHO, C#/CLR, with its richer language and its ability to directly interact with Windows' native APIs, is a clear winner. If you need cross system portability then Java/JRE is a clear winner.
PS. If you need more portable jobs skills, then IMHO Java is also a winner.