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

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

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.

Answer 2

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.