What are the advantages of c# over, say, delphi/realbasic for windows applications

Question

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.

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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 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.

Answer 6

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.

Answer 7

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:

1. 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.

2. 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.

3. 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.

Answer 8

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.

Answer 9

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.

Answer 10

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.