It's a difficult question to answer; from my personal experience of both Delphi V1 -> V2005 and C# in VS2005 I'd say the following,
1. I found delphi easier to learn; but I'd learnt pascal at school rather than Java, C or C++ so it depends on what you know already - in any case learning the Dot Net framework is the key to getting the best from either, grasping the language syntax is a minor effort in comparison IMO.
2. I don't think there's much difference (if any) in performance if you are using dot net. If you use the VCL then I suspect that Delphi would be faster; but any benefit would be overshadowed by good or bad design in your code and there are benefits to dot net, i.e. garbage collection etc.
3. I like some aspects of Delphi over c# for example native set handling; however c# has things like generics which have no equivalent in Delphi - so pick the best tool for the job, if you are writing a lexer/parser then Delphi is elegant, if you want to leverage dot net 2.0 then c# is the only way to go IMO.
4. I feel some uncertainty about the future of Delphi - I would still use it for personal projects because I like it, but for business I use c# because it's way more mainstream these days.
I pretty much agree with borthwis. The Delphi line after version 7 and Kylix should be evaluated as a different family of IDEs and compilers. Although they support native code too, Delphi 7 is the only thing on the universe that is easy, flexible, scalable yet produces highly optimized, high performance native code with low level control like C. (In which language other than C/C++ you can write kernel mode drivers ? In Delphi to some extend.) Kylix gives Delphi code native Linux portability but DotGNU and Mono projects claim .Net MSIL portability to Linux too.
Performance wise managed code is only negligably slower than native code, but JIT compiler causes a latency on the first run of an application.
The Win32 API integration and completness in Delphi surpasses even C but It is very unfortunate that Delphi 7 doesn't provide a general Garbage Collection for statically allocated variables, although it already has reference counting and automatic mem releasing logic for strings, dynamic arrays and many other types.
Delphi 7 is a state of art native code IDE/Compiler with transparent support for Windows Services, Web Applications, COM Objects, Win32 API, etc..
And C# + .Net CLR is the universal code done the right way and the next big thing. (I observe that with .Net 2 and .Net 3 on Vista they more and more alienate the framework from operating system and architecture, while abstraction and generalisation is one thing and trying to ignore the real mechanics is another.)
I can write a whole book on C# vs Delphi 7 issue, I constantly use both of them; keep posting if you have any questions.
Thanks for some very helpful information. What I think I am hearing is that since I already have my teeth partially sunken into C#, there's no advantage in trying to either switch to Delphi or try to learn both at the same time. In fact, it might be counterproductive at this point, a least until my understanding of .NET and C# are much more full than they are right now.
This thread is very interesting to me because I am starting a job developing & maintaining
custom software written in delphi for a large call center. This software responds to a new call
from whatever list dialer they have installed and brings up a UI for the customer service rep
to use while collecting information from the person on the other end. My boss, the senior IT guy has been using delphi forever & has written lots of different software for the company. Now, I do not have a Delphi background or anything but I have used Java before so I definately would rather change as little of his delphi as I can & just write C# components, so
my changes can be in the language that is better for me.
I know that C# is part of the .net family so I know it's web capable but what about working
with win32 api as desktop software? Can I write C# code that can use win32 api just like
Delphi? Also I am wondering if C# can use the same weird socket that delphi uses
to handle an instance of a new telephone call being provided to the delphi software & the customer service rep's desk from the list dialer.
last question: I know that much like vb6, Delphi has RAD featuring common windows UI components. Does C# have similair support for that kind of windows UI construction?
Or is using C# different than using RAD features in Delphi & vb?
I've used Delphi since version 1 and I've used C# for several years now. The ONLY reason I use C# is because it is a requirement of a big project I am working on. And, those requirements were specified for all of the wrong reasons, so far as I'm concerned.
The Delphi and C# languages are reasonably similar (both were designed by the same person). C# has generics, attributes and better handling of interfaces. Delphi (Object Pascal) has much better structure, class referencing, mathematical sets, data modules and so forth. I wish there was one language which had all of the above since all of those things are useful. In the end, you can get the work done with either language, you just have to go about things differently.
However the REAL difference is in the libraries. The Delphi VCL is far more mature and a much better design than NET. I have been continually frustrated by the poor design of some parts of NET. It is a huge and complex system, but it seems like much of it is of little use for real-world projects. On the other hand, it is missing a lot of things which VCL provides and some of what it does provide doesn't work as expected. I find ADO.NET to be particularly bad. There is no equivalent of the Delphi DataModule class, for instance. The "disconnected dataset" concept would be great if it could do all of the things a connected dataset can do, but it can't, and that causes a lot of problems. There is a general lack of useful events, and those which are included often do not work as expected. Data validation is tied to visual controls instead of the data classes. That would be a bad idea in the first place, but it proves to be even worse because there a lot of holes in the logic - it is all too easy for the end user of your program to cause errors which should be avoidable, and you must go to a lot of trouble to prevent them. Finally, the Help system is sub-standard, to say the least. You must do a lot of digging to find what you need. Often, you will only find answers to your questions by accident, if at all.
The one other big consideration, of course, is that technical superiority isn't the whole story. Microsoft is a lot bigger and their products are going to get used whether they are better or not. As I said at the start, I would never use NET if I could avoid it, but the truth is, there are times you cannot avoid it. So, I use Delphi when I can and C# when I must.
I know this is an older thread, but I thought I would reply anyway.
One thing to bear in mind is that .Net is a framework, C# is a language that sits inside this framework. So I am not sure if it is fair to compare Delphi with .Net.
With that said, Delphi is a very easy language to learn as a student. It teaches you everything you need to know about creating good, clean code. I wouldnt be shocked to hear that a lot of people learn Delphi at college or university. Comparing it to C# can be a little tricky - when this post was started there were a few things that C# had over Delphi, namely generics and anonymous methods. But, in the latest version these features are present.
One of the things I liked about Delphi was the speed at which a decent sized enterprise app could be developed compared to VB and the sheer amount of functionality available when working with databases.
Delphi does suffer a little though from a few things. The IDE isnt that great IMHO. When you compare it to other IDE's like Visual Studio, Eclipse and even SharpDevelop, it just doesnt do it for me. There is also the issue of using Delphi apps cross platform. When you compare it to .Net on these lines, or even compare it to Java, Delphi doesnt match up. This can be quite expensive for the enterprise and could put off smaller business from working with Delphi.
But, there is also Delphi.Net. So all the hard work that has been put into creating Delphi apps isnt lost. If you wanted to migrate Delphi from the desktop and out onto the Internet, Delphi.Net can work for you with very little effort. This also means that you can use .Net assemblies with Delphi and vice versa - so this means the libs available to Delphi can now also be used with other .Net apps... This is very attractive.
Essentially, dont discount Delphi. It is still very valid and Delphi.Net should be seen as a compliment to things like C# etc.
ive read some of the excerpts here. I was a Delphi developer for 7 years, and during Delphi v3-v2010 - it was good. BUT ! the reality is - no businesses want to develop in Delphi anymore, its a resource and business constraint. Microsoft pushed its .NET platform for a reason, this was Anders original idea to Borland, Borland wasn't enlightened by Anders vision, which of cause was apparent once Anders was poached by Microsoft and later release .NET 1.0, which of course Borland was forced to not allow and release of a similar platform for 1 year.
in Delphi you still have DLL HELL! and you are still subject to complicated COM Interfaces which can be a real pain for the light hearted. I personally started in Delphi in 1998, and was thrown directly into hard core API socket programming, later to develop multi-threading applications to the cinema arena. At the time Delphi was about - there was either C/C++ or Delphi, Java was still in the incubator. C was a hard learning experience and took ages to develop code, but Delphi at the time was a great RAD tool. However, as we all know - markets change, business changes and people trends change. In the initial release of .NET 1.0 i was intruiged, i was a Delphi lover at the time, but interested in .NET. 2 years down the line, i became conversant with .NET and became very comfortable quickly with .NET. Its designed simplicitly and it theres no headaches regarding garbage collection/threading/dll hell/COM-DCOM. Everything was so much more cleaner and easy to develop. Only issue was that the designated PC needed the .NET Framework. 12 years ago this was a little problem, nowadays - its hardly noticable.
SPEED WISE! Delphi was great for speed, compiled to native code. But as we all know know a days, we have to change our programming heads, and code to Multi-CORE/Quad-Core processors, 64 bit platforms, or consider Asyncronous programming. Server hardware nowadays is not restricted just to the 8086x instruction set, hardware now allows you to code to the platform and the hardware. THIS IS THE WHOLE POINT OF THE .NET FRAMEWORK, ASWELL AS BEING PLATFORM INDEPENDANT THAN DEPENDANT.
The carefully developed JIT Compiler does all the hardwork for you, creating native code specific to your hardware/platform demands. Only on the initial first execution of a particular method (class/procesure) is the program slow, this is because the JIT Compiler has to do the hardwork of compiling the best native code for the that particular codeset. Once its compiled, its stored in memory ready to be accessing again when its needed (thus the reduction in execution time).
So - i would actually say, in todays modern Times, .NET is a better as faster platform to program in than Delphi. what now with .NET 4.0, with the release of Async. implementation model, Parallelism, and ConCurrency Collections, aswell as advanced optimisation of the .NET CLR DLR etc....NET is a formiddable framework to work with and is constantly changing, something i can hardly say for Delphi - which is also STILL hasnt got a 64 compiler!!!!
And on top of that - There are alot more cheaper developers in .NET than Delphi - which is exactly why businesses prefer .NET now than Delphi. WHY ON EARTH would a company pay 60,000 a year for a Delphi developer when he can get a upto date young .NET Developer for 30,000.
Thats the thing with us IT tech heads, we concern ourselves with coding and performance and efficiency - but all the company cares about is MONEY/TIME/RESOURCE.