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.
Related
First, let me ask you to consider this as a real question, and not a subjective one.
That out of the way, here's my situation: We are looking to port our existing classic ASP application to .NET, but we're unsure of what language to use for the new app.
I personally would 'prefer' C#, as I'm more familiar and comfortable with that languages way of doing things, but, the original code is VBScript, so it would possibly be easier to port to VB.NET ... One possible situation I fear would be that, because the code is so similar between the two variants of VB, that we might end up getting stuck on something that is not similar between the two, even though it looks like it would work. A shift to a wholly different language might avoid that kind of situation.
Does anyone have any practical examples of this kind of situation? Insights to illuminate the issue with? Do the potential benefits of a complete paradigm shift outweigh the gains from a high degree of 'copy-and-paste-ability' ?
I have used C#.NET and just recently learned VB.NET and I have to say that once you get around the small syntactical differences, VB is also a very good language. So for you, this is a win win.
That being said, I think a syntax change will help protect the project from any careless copy pastes from the old dirty code base. I believe a fresh start with a fresh language is your best bet for a top notch re-write.
There are 10X as many questions re: C# as there are VB.NET on StackOverflow. That seems to indicate there are more developers using C#, or perhaps a more thriving community (or maybe it just means C# is harder or C# developers don't know as much).
Any gains made due to the similarity of VBScript to VB.NET are far outweighed by the fact that you need to learn the new data types, .NET namespaces, and a new style of web development using webforms or MVC (my preference).
For this reason I think the choice of language should be made independently of what was used before.
3 years ago I had to make this same decision. My preference would have been C# but we ultimately went with VB.Net because that was the closest language available to the developer base we had. All of the developers had experience with VBScript, so learning VB.Net was easier for them. While the framework is the framework and the rest is just syntax and best practices, you'd be surprised the difference in learning curve just by adding a few curly braces for VB developers (the reverse seems to be exactly the same for C# developers going the other way with an itchy semi-colon finger, learning new keywords and relearning event syntax).
You should look at your developer pool and consider what is the easiest for your team to perform development and maintenance. If this is not a serious criteria (because the developers are proficient equally in both), then I would recommend a C# approach. The primary reason is that the VBScript will be relying on outdated methodologies, but converting to VB.Net will not necessarily throw exceptions for these methods whereas C# will. It will also force you to touch every aspect of your application, which (while tedious) will provide your team an opportunity to evaluate how older methods may be refactored into more efficient processes.
Just keep in mind - the "easiest" seeming solution seldom is.
When moving to ASP.NET, I believe that less focus needs to be on the page itself, and more on how you're going to write the business logic. This is a subjective question because different units will have different results.
That said, always play to your strengths. If your team is more familiar with C# than VB.NET, use C#. If they're more familiar with VB.NET, use VB.NET. If they have no real .NET Experience, then you probably want to set up some sample projects with which they can play to see which will be easier to learn. You want the most bang-for-your-buck, and that means making sure the team is as comfortable as possible.
Further, I wouldn't worry too much about copy & paste code, as there are enough differences that any professional developer (as in one who acts professional, not just one who gets paid) will see how much he/she is changing and go back through the rest of the code to ensure it is working properly.
The difference between an ASP.NET and Classic ASP application is already so big, that it will not be an easy copy/paste port anyway.
So I think you should go for the language that you feel most comfortable with (and as another answer suggests, there is a much larger community using C# than VB.Net).
Why are you rewriting the application? What are the short and long term objectives you hope to achieve through this change?
At a high level there is not much to choose between VB and C# - both are extremely functionally rich labguages that compile to teh same IL code.
Personally I moved to C# a few years ago because the vast majority of code examples found on the net are in C#, and the programmer's best friend is the internet where you may just find that nugget of useful information that save you hours of head scratching.
In your situation, by fircing yourself to rewrite the code in a different language will force you to possible rething the implementation and therefore review carefully the code and functionality required - if yuo have the time and budget. If you are up against tight deadlines then VB would be the natural choice, but may negate the benefiots if the rewrite.
I have been in exactly this position, and I urge you not to translate the app in two ways at once--from VB to C# and from classic ASP to ASP.NET.
You have chunks of business logic in your code that will not need to change much, so why change it? You are guaranteed to introduce new bugs in the translation.
I can't count how many times I thought, "this looks exactly the same, why isn't it working?"
Just adapting your code to the new codebehind pattern will be challenging enough. A vast and worthwhile improvement, of course, but not trivial.
VB.NET and C# are so incredibly similar that technically the choice is almost irrelevant. Each language has some minor things they excel in, but overall, the two are practically identical, just with wildly different syntax.
With that said, I highly recommend going with C#, just because it's the language the .NET community really got behind. It will have the most books, websites, blogs, forums, you name it. Not having to translate the oodles of examples out there on the net into VB.NET alone makes C# a better choice. I think in my 10 years of being a .NET developer, I could count the number of people I've ran into that genuinely chose VB.NET on one hand. Most people that are using VB.NET are using it in a "stop gap" fashion, with the intention of ultimately going to C#.
Many people go for C# because they think that VB.Net and C# is only syntactically different which is just not true. VB.Net has better features for handling interactions with COM components for example, like optional parameters (these are now available in C# 4.0). But there are catches too in a line by line conversion of VB to VB.net. A very simple example is the array index. If I'm not mistaken array indexes start from 1 in vb and in vb.net it starts from 0 which causes horrible bugs. Overall, I'd definitely consider going for VB.Net even though I work basically in C#.
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'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
In a progression of languages, I have been learning C and C++. Now I would like to learn C#. I know there are some drastic differences between them - such as the removal of pointers and garbage collection. However, I don't know many of the differences between the two.
What are the major differences that a C++ programmer would need to know when moving to C#? (For example, what can I use instead of STL, syntactic differences between them, or anything else that might be considered important.)
C# for C++ Developers is a great place to start. It is a table that lists the most important comparisons between the two languages.
Once you have explored some of these differences, you might choose a self-contained project you have written in the past in C++, and re-write it in C#. In your first pass, you will probably just end up translating directly across, using the same design and algorithms. As you become more comfortable with C#, you will recognize ways to take advantage of language features only available in C#, as well as the incredibly versatile .NET Framework.
I think it's important to note that pointers weren't really removed from C#, but that they still exist, they are everywhere, and they are called references.
Charles Petzold has a .NET Book Zero that is designed specifically for the C/C++ Windows programmer who wants to learn C# and .NET. It is a free PDF download from his site. All of the source code used in the book is available as a separate Zip-file download.
There was a similar question that has lots of pointers (pun inteded :-)) and resources about the differences between C++ and C# and what to pay attention when learning transitioning - Linux/C++ programmer to Windows/C# programmer.
Look at the Generic collections and LINQ (all the related technology to LINQ) for STL like functionality.
The number one thing to note is that ~/Destructor is c++ is nothing like the ~/finalizer in c# -- See IDisposable/using.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Has anyone ever written an application bigger than its .NET luggage?
People used to criticize VB6 for its 2 MB runtime but it rarely dwarfed the app it accompanied.
Today despite having Vista on my machine I had to download 35 MB of the 3.5 framework and reboot to then try out an app half that size.
When you factor in the decreased source code security I wonder why anyone would anyone develop a windows application in .NET rather than in a language that allowed for the building of native executables.
What is superior about .NET that outshadows these drawbacks when it comes to writing applications to run on Windows?
PEOPLE: Please note that this was written in February, 2009, and what is said was appropriate at that time - yelling at me in late 2012 (3+ years later) is meaningless. :-)
Delphi has some considerable advantages for Win32. Not that .NET apps are inherently bad, but try:
running a .NET app (any version) on Win95/ME, where .NET doesn't exist (AFAIK)
distributing any small ( < 1.5 MB) .NET app (yes, floppy drives still exist)
providing any .NET app on a system that has no Internet access (yes, they exist)
distributing your .NET apps in countries without widespread high bandwidth
keep people from seeing your source code without spending a ton of dough (Reflection, anyone?)
Garbage collection in .NET might be really nice, but anyone who knows anything about programming can also handle manual allocation/deallocation of memory easily with Delphi, and GC is available with reference-counted interfaces. Isn't one of the things that brought all of the non-programmers to proliferation the pseudo-GC of VB? IMO, GC is one of the things that makes .NET dangerous, in the same way VB was dangerous - it makes things too easy and allows people who really have no clue what they're doing to write software that ends up making a mess. (And, before I get flamed to death here, it's great for the people who do know what they're doing as well, and so was VB; I'm just not so sure that the advantage to the skilled outweights the hazards to us from the unskilled. )
Delphi Prism (AKA Rem Objects Oxygene, formerly Chrome) provides the GC version of Delphi that those who need it are looking for, along with ASP.NET and WPF/Silverlight/CE, with the readability (and lack of curly braces) of Delphi. For those (like me) for which Unicode support isn't a major factor, Delphi 2007 provides ASP.NET and VCL.NET, as well as native Win32 support. And, at a place like where I work, when workstations are only upgraded (at a minimum) every three years, and where we just got rid of the last Win95 machine because it wasn't a priority to upgrade, the .NET framework is an issue. (Especially with company proxy requirements only allowing Internet access to a handful of people, limiting bandwidth and download capabilities, and proper non-admin accounts with no USB devices allowed, all still running across a Netware network - no such thing as Windows Update, and never a virus so far because nothing gets in.)
I work some in .NET languages (C#, Delphi Prism), but the bread and butter both full-time and on the side, comes from Win32 and Delphi.
Okay, I doubt this will persuade you as you don't want to be persuaded, but here's my view of the advantages of .NET over older technologies. I'm not going to claim that every advantage applies to every language you mentioned in the question, or that .NET is perfect, but:
A managed environment catches common errors earlier and gives new opportunities:
Strong typing avoids treating one type as another improperly
Garbage collection largely removes memory management concerns (not totally, I'll readily admit)
"Segmentation fault" usually translates to "NullReferenceException" - but in a much easier to debug manner!
No chance of buffer overruns (aside from the potential for CLR bugs, of course) - that immediately removes a big security concern
A declarative security model and a well-designed runtime allows code to be run under a variety of trust levels
JITting allows the CLR to take advantage of running on a 64 bit machine with no recompilation necessary (other than for some interop situations)
Future processor developments can also be targeted by the JITter, giving improvements with no work on the part of the developer (including no need to rebuild or distribute multiple versions).
Reflection allows for all kinds of things which are either impossible or hard in unmanaged environments
A modern object-oriented framework:
Generics with execution time knowledge (as opposed to type erasure in Java)
Reasonable threading support, with a new set of primitives (Parallel Extensions) coming in .NET 4.0
Internationalisation and Unicode support from the very start - just one string type to consider, for one thing :)
Windows Presentation Framework provides a modern GUI framework, allowing for declarative design, good layout and animation support etc
Good support for interoperating with native libraries (P/Invoke is so much nicer than JNI, for example)
Exceptions are much more informative (and easier to deal with) than error codes
LINQ (in .NET 3.5) provides a lovely way of working with data in-process, as well giving various options for working with databases, web services, LDAP etc.
Delegates allow a somewhat-functional style of coding from VB and C#; this is better in C# 3.0 and VB9 due to lambda expressions.
LINQ to XML is the nicest XML library I've used
Using Silverlight as an RIA framework allows you to share a lot of code between your lightweight client and other access methods
A mostly-good versioning story, including binding redirection, runtime preference etc
One framework targeted by multiple languages:
Simpler to share components than with (say) COM
Language choice can be driven by task and team experience. This will be particularly significant as of .NET 4.0: where a functional language is more appropriate, use F#; where a dynamic language is more appropriate, use IronRuby or IronPython; interoperate easily between all languages
Frankly, I just think C# is a much cleaner language than VB or C++. (I don't know Delphi and I've heard good things about it though - and hey, you can target .NET with Delphi now anyway.)
The upshot of most of this - and the soundbite, I guess - is that .NET allows faster development of more robust applications.
To address the two specific issues you mentioned in the question:
If your customer is running Vista, they already have .NET 3.0. If they're running XP SP2 or SP3, they probably have at least .NET 2.0. Yes, you have to download a newer version of the framework if you want to use it, but I view that as a pretty small issue. I don't think it makes any sense to compare the size of your application with the size of the framework. Do you compare the size of your application with the size of the operating system, or the size of your IDE?
I don't view decompilation as nearly such a problem as most people. You really need to think about what you're afraid of:
If you're afraid of people copying your actual code, it's usually a lot easier to code from scratch if you're aware of the basic design. Bear in mind that a decompiler won't give local variable names (assuming you don't distribute your PDB) or comments. If your original source code is only as easy to understand as the decompiled version, you have bigger problems than piracy.
If you're afraid of people bypassing your licensing and pirating your code, you should bear in mind how much effort has gone into stopping people from pirating native applications - and how ineffective it's been.
A lot of the use of .NET is on the server or for internal applications - in neither of these cases is decompilation an issue.
I've written more on this topic in this article about decompilation and obfuscation.
To name a few:
Automatic memory management, garbage collection
Type safety
Bounds checking
Access to thousands of classes that you will not have to create
OK first up, No one language/platform is ever going to be universally superior.
Specialization will always provide a better use case in certain areas but general purpose languages will be applicable to more domains.
Multi-paradigm languages will suffer from complex boundary cases between paradigms e.g.
Type inference in any functional language that also allows OOP when presented with sub classes
The grammar of C++ is astonishingly complex, This has a direct effect on the abilities of its tool chain.
The complexities of co/contra variance coupled with generics in c# is very hard to understand.
Older languages will have existing code bases that work, this is both positive (experience, well tested, extensive supporting literature) but also a negative (the resulting inertia against change, multiple different ways to do things leading to confusion for new entrants).
The selection/use of both languages and platforms is, as are most things, a balancing of the pros and cons.
In the following lists Delphi has some of the same pros and cons, but differs on many too.
Potential Negatives of .Net (if they are not an issue to you they aren't negatives)
Yes, you need the runtime deployed (and installed), and it's big.
If you wanted a language with multiple inheritance you're not going to get it
The BCL collections library has some serious flaws
Not widely supported outside the MS universe (mono is great but it lags the official implementation significantly)
Potential patent/copyright encumbrance
Jitted (ignoring ngen) start up time is always going to be slower and more memory will be needed.
There are more but these are the highlights.
Potential Positives (again if they don't matter to you)
A universal GC, no reference counting that prevents certain data structures being usable, I know of no widely used Functional language without GC, I can't think of significant language of the last 10 years without at least optional GC. If you believe this is not a big deal you would appear to be in a minority.
A large BCL (some parts not so good as others but it's very broad)
Vast numbers of languages (and a surprising number of paradigms) can be used and interact with each other (I use c#, f#, C++/CLI within one wider application using each where it makes most sense but able to easily use aspects of one from another).
Full featured introspection combined with declarative programming support. A wide variety of frameworks become much simpler and easy to use in this manner.
Jitted - alterations in underlying CPU architecture can be largely transparent, sophisticated runtime optimizations not available to pre-compiled languages are possible (java is doing rather better on this currently)
memory access safety
Fusion dll loading and the GAC for system dlls
Likewise specifically for c#
Con:
Syntax based on C underpinnings
(pre 4.0) late binding solely via inheritance
More verbose than some imperative languages
poor handling of complex embedded literals (regexes/xml/multi line strings)
variable capture within closures can be confusing
nested generators are both cumbersome and perform appallingly
Pro:
Syntax based on C underpinnings
Much functional support through lambdas
Expressions allowing compile time validation of non code areas such as Linq to SQL
Strongly typed but with some Type inference to make this easier
if you really need to unsafe is there for you
interaction with existing C++ ABI code via P/Invoke is both simple and clear.
multicast event model built in.
light weight runtime code generation
The C underpinnings really is a pro and con. It is understandable by a vast number of programmers (compared to pascal based style) but has a certain amount of cruft (switch statements being a clear example).
Strong/Weak/Static/Dynamic type systems are a polarising debate but it is certainly not contentious to say that, where the type system is more constraining it should strive to not require excessive verbosity as a result, c# is certainly better than many in that regard.
For many internal Line of Business applications a vast number of the .Net platform Cons are absolutely immaterial (controlled deployment being a common and well solved problem within corporations).
As such using .Net (and this does largely mean c#, sorry VB.Net guys) is a pretty obvious choice for new development within a windows architecture.
The "simplicity" of developing complex(and simple) applications using it. A lot of basic stuff is already coded for you in the framework and you can just use it. And downloading 35mb file today is much easier than 2mb file 8-6 years ago.
There are a lot of reasons. I don't know much about RealBasic, but as far as Delphi goes:
Less widespread than .NET, smaller development community. Many of the Delphi resources on the net are ancient and outdated.
Until Delphi 2009, Delphi didn't have full unicode support.
I don't know about Delphi 2009, but 2007 didn't have very good garbage collection. It had some sort of clunky reference counting that required some intervention on behalf of the developer. .NET has a much more advanced GC that does virtually everything for you.
.NET has a larger standard library and more up-to-date 3rd party libraries.
.NET languages like C# are arguably better, and certainly easier to understand for those new to the language.
There's a lot of supposed advantages cited by .NET developers here that shouldn't be in that comparison, simply because Delphi has them as well:
Type safety
Bounds checking
Access to thousands of classes (components) that you will not have to create
There are however some things in .NET that Delphi doesn't have out-of-the box, and only some of those can be added by libraries and own code. To name a few:
Support for multiple languages working on top of the same runtime - allowing to choose the matching language for the problem (e.g. functional programming using F#)
Dynamic source code generation and compilation - this is something so alien to Delphi programmers that they probably don't even see how it could be useful [1]
Multicast events
Better multi-threading support (for example BackgroundWorker class, asynchronous delegates)
Seamless support for both 32 and 64 bit processes
Weak references
[1] If you don't know but are interested, check out the home page of Marc Clifton, especially the articles about declarative programming.
Edit: I'd like to respond to the comment by Mason Wheeler:
Re dynamic code: I know that there are solutions to have Pascal scripting embedded in the application. There is however a distinct difference between making parts of your internal object hierarchy available to the scripting engine, and having the same compiler that is used for your code available at runtime as well. There are always differences between the Delphi compiler and the compiler of the scripting engine. Anyway, what you get with .NET goes far beyond anything that is available for Delphi. And anyway, it's not the point whether one would be able to code similar infrastructure for Delphi, the point is that with .NET it's already there for you, when you need it.
Re Multicast events: Exactly, there's ways to code it, but it's not part of Delphi / the VCL out-of-the-box. That's what I was saying above.
Re weak references: You are sadly mistaken. Try to use interfaces in a non-trivial way, creating circular references on the way. Then you have to start to use typecasts and wish for weak references.
Well, the .NET Framework is shared for all .NET applications, so you have it only once on your machine and 35MB are nothing today (compare it to the size of your Vista installation). For your second .NET application you don't have to download it again.
For Windows app, .NET (using C# or whatever) gives you more direct access to the latest and greatest Windows features. It's also very well supported by Microsoft, has a huge community and lots of books written about it.
REALbasic (now Xojo) is for cross-platform apps. Using it just on Windows can sometimes be useful, but that would not be its strength (which is that it's amazingly easy to use).
I don't know much about Delphi.
From what I can see RealBASIC doesn't have much (if anything) in the way of Object Relational tools and probably wouldn't be as good a choice for n-tier, database-centric applications.