|
Delphi compiles to stand-alone executables
Joel complains about a lack of a linker in .NET.
In fact, Joel is asking for something that Delphi does since 1995: stand-alone executables that don't require a runtime or other external components.
With Delphi, you can create reasonably sized application which don't require a runtime, and you don't have to worry one bit about DLL Hell and version incompatibilities, because you can use all the Delphi controls and components you want and everything will go into one .EXE.
Also, Delphi compiles to native code which is extremely fast - the speed is comparable with the speed of C++.
So, how do Delphi and C# / .NET compare, out of the box?
I have 7 years of Delphi experience, starting with Delphi 1.0, and 1 year of C# experience.
Delphi comes with a better set of components, and has a lot less bugs than .NET.
In WinForms, even the grid is broken and produces problems.
There are a lot of quality third-party components and controls for Delphi.
The speed of Delphi compiled code is higher than the speed of C# .NET code.
So, what do C# and .NET have, that Delphi 7 doesn't have?
- garbage collection, managed environment (but Delphi implements several ways to deal with the lack of gc)
- multicast events
- C-like syntax
It's an acceptable compromise, to me.
Max
Thursday, January 29, 2004
Also, about Pascal leaving people a bad taste in their mouth:
Delphi is based on ObjectPascal, which is a very much improved variant of Pascal.
I can understand why Pascal, Turbo Pascal or MS Pascal (yes, there was such a thing) left people a bad taste in their mouth - the language was restrictive, compared to C.
But in ObjectPascal, they fixed it by extending the language a lot.
You get dynamic arrays, an object model very similar to Java's and C#'s, and many other things.
Max
Thursday, January 29, 2004
A developer's skills in languages and development environments aren't "hot swappable" though are they?
For example, if you have invested a few years in building VB applications then your looking at months of work before you are as proficient in say Delphi as you were in VB.
Matthew Lock
Thursday, January 29, 2004
The inevitable second "use Delphi instead of (whatever) post". Here's hoping this trend continues!
Mister Fancypants
Thursday, January 29, 2004
If you want to persuade me to use Delphi tell me something you can do in Delphi that is very much harder in other languages?
I mean something concrete, for example it's very much easier in perl to rip though a file and extract data then any other language I've seen.
Matthew Lock
Thursday, January 29, 2004
It is a lot faster and easier to create an app with a good, usable, rich GUI in Delphi than in other languages, including VB 6 and Visual C#.
The standard Delphi controls also have a lot less bugs than the corresponding .NET controls, so you will spend a lot less time working around bugs.
Delphi has a lot of third-party components, many of which do non-trivial tasks and are of a very high quality. http://www.torry.net/
It is easy to write fast programs in Delphi, because it has a real, native compiler and the speed of your code will be comparable with the speed of C++.
In Delphi, you can call Windows API functions directly, without having to declare them, like you do in C# and VB 6.
Max
Thursday, January 29, 2004
I agree with Matthew.
We have a VB application (downloadable via internet) that would most probably work better in Delphi -- problem is it will take months to get where we are now. So we need to decide, will our future sales increase pay for the investment in year 1?
For us conservatively: 2 people x 2 months x $10k/month = $40k. So our sales (or rather our profit) must increase by $40k in year 1 else it is not worth it for us.
Re. .NET: What really put me off .NET was when I wanted to install an eval version of Vault (source control program) yesterday -- I go the message on my PC that the .NET framework is not installed. My PC is less than 1 year old and I am using Win XP Pro with Office XP & *I* have a problem! It will take many years before we can even think of rolling our applications out on .NET -- So Win32 development will be with us for *AT LEAST* another 3 years.
Laim
Thursday, January 29, 2004
I don't agree with Max in his first post.
I'm also a developer that started out with Delphi 1 until 6 and that now has a couple of years of C# on his resume.
I don't find .NET having more "bugs" than Delphi, especially if you consider the kind of hickups us Delphi developers have had to cope with (Delphi 4.0 anyone?). I'd like to talk to you about the MIDAS problems I've had to deal with. Talk about leaky abstractions!
I do understand that while Delphi compiles applications to a single executable (which has been a very strong selling point for quite a while) you can never really accomplish much without dependencies: a database driver, an AxtiveX/COM component you may need or a BDE (good Lord). Also, C/C++ developers often stated that while you get a single executable, the smallest empty single form application you can create still is 400K in size, while their MFC/C++ app can do the same with under a tenth of that.
Also, you can simply not compare a development tool producing "native" executables with one that produces "managed code". There are simply too many things different in the way you develop software for the two. I cannot even begin to list all the things I like in C# and the Framework that I didn't have in Delphi.
WinForms may have its problems today, but if you're a bit into C# you'll know that lots more are coming in our direction. True, visual inheritence is not what it was in Delphi yet, but they're working on it.
As for Joel's rant about the runtime, I bet he never had to use any decent Java application like Internet Banking yet.
Just my 2.29 cents.
Dave Van den Eynde
Thursday, January 29, 2004
Well, C# has all these neat features that Delphi doesn't have, I agree. I also agree that many of them are improvements (stuff like garbage collection comes to mind).
However, I can't help but realise that I was way more productive in Delphi 3 years ago than I am in C# (or heaven forbid, C++) now, even though I'm least experienced in Delphi.
Heck, I was probably as productive in the first week I started using Delphi as I've ever been in any other language. At least for writing apps with a GUI component (desktop in Delphi's case, desktop or web based for other languages).
That's just my experience though. I know it goes against how things should work in theory. But when practice mismatches with theory, I'm in favour of throwing out the theory, not the practice.
Sum Dum Gai
Thursday, January 29, 2004
I should also note that when I started using Delphi, I was somewhat of an anti-pascal bigot. I also whinged that it didn't have stuff like C++ has, such as templates.
In practice, I didn't really find I missed them. They would have been "nice", but I can't say it really made an appreciable difference to my ability to develop quality code quickly.
Sum Dum Gai
Thursday, January 29, 2004
Who let the Delphi users out of the box again? Well, when you've finished playing with them please remember to put them away again.
Thursday, January 29, 2004
What drives me crazy is that Borland is riding MS's wagon and missing out on the greatest opportunity they will ever have. Take the C# language and make it compile natively like Delphi, the VCLs would be the .net framework (with some naming changes). Borland would capitalize on their heritage as a harcore compiler company and would gain potentially huge market with C# developers and even C++ and VB developers.
Issam Elbaytam
Thursday, January 29, 2004
My thoughts exactly. When the news got out that Borland would release C#Builder my initial reaction was: why???
Then I decided that they must have implemented the killer feature: Being able to compile C# to both .NET and native Win32. That would be really hard to do, but Borland in the old days would have pulled it off. Unfortunately for Borland they are not up to their old standards anymore.
About the Delphi user flooding: Delphi topics on Joel On Software are often posted in the Delphi newsgroups.
Jan Derk
Thursday, January 29, 2004
A big thing for me in .NET has been the remoting.
How do you manage this in Delphi? Is it as easy to call singlecall and singleton objects?
What about web services? can you do the equivalent of this in Delphi?
Is Delphi fully OO (.NET is except for multiple inheritance) and is it strongly typed? (I LOVE strong typing. Every project is set to 'object strict on'. Sure it takes more code but it's saved me DAYS of debugging)
Gwyn
Thursday, January 29, 2004
I don't know what remoting is, and have never used it or needed it, so I don't know if Delphi supports it.
Web services: Delphi 6 and 7 fully support web services.
The Delphi programming language (called ObjectPascal) is strongly typed and fully object-oriented.
In fact, the Delphi obiect model is very similar to the C# and Java object models.
Max
Thursday, January 29, 2004
Not sure what the correct definition is but it allows me to allocate and use remote objects, identified by ip address/port (or through SOAP).
remote objects can be single call (like DCOM provides) or singleton (which DCOM doesn't provide).
It's different in as much as where in DCOM a system service is sitting looking for remote object requests, with remoting you have to create a service type program that will listen and serve remote object requests. The singleton is the really useful one for me.
Does Delphi provide anything in this middleware type area?
Gwyn
Thursday, January 29, 2004
Delphi fully supports web services, soap, and a couple other RPC "standards." In fact, you can easily write your web service in c #and then create a client (consumer) in Delphi, or vice-versa.
DD
Thursday, January 29, 2004
"A big thing for me in .NET has been the remoting.
How do you manage this in Delphi?"
Delphi ships with a framework called Datasnap for recordset/dataset remoting.
But there are a couple of products out there that are better, easier to use, and more flexible than Datasnap, and which have support for remote procedure calls/web services to boot. What's more, they do this in a way that fits nicely within the RAD development environment of Delphi. They are powerful and very fast to develop with.
See Remobjects (the RPC framework) and DataAbstract (part for recordset remoting and more) at:
http://www.remobjects.com
and see kbmMW at:
http://www.components4developers.com
kbmMW's web site looks a little cheesy, but it's actually an amazing n-tier library. It works more like other components in Delphi that Delphi programmers are used to. The RPC framework of kbmMW doesn't yet support SOAP (though it will within months); it's a proprietary design but it works fast and well.
RemObjects includes SOAP support, may be a little more polished (at least it "looks" more polished to a new user), makes heavy use of interfaces, and may be more comfortable for someone coming over from the MS world. RemObjects has been or will be ported to .NET, I believe.
There are a couple other choices for n-tier development with Delphi, but I think these are the two best.
Herbert Sitz
Thursday, January 29, 2004
"In fact, Joel is asking for something that Delphi does since 1995: stand-alone executables that don't require a runtime or other external components."
Isn't that becasue it links the whole damn VCL into the .EXE? That's why you get a 1 meh executable just to say "hello world".
Ot at least that's the way Delphi used to work in it's early days. At least MS was open about having to distribute VBRUN.dll for Visual Basic apps. I started wiht Delphi 1 but quit using it afer Delphi 4.
[*]
Thursday, January 29, 2004
The minimum size of a Delphi executeable is 400K before using 3rd party tools to strip it down.
However, it doesn't grow much after that. Your EXE will be 400K bigger than a C++/MFC one, not 2 times bigger or anything.
As soon as your app gains any significant complexity, 400K is meaningless. Also, the more features you add to your MFC program, the more likely it will be linking in 400K of MFC libraries anyhow.
400K is nowhere comparible to 22MB.
The other problem Joel has with .Net is that the different versions of the runtime are not sufficiently compatible with eachother. Delphi (which isn't an option for Joel because what he has now is working fine) would eliminate that problem.
Richard P
Thursday, January 29, 2004
"400K is nowhere comparible to 22MB"
Which, given that nobody here is comparing them, is a pretty strange thing to say.
Friday, January 30, 2004
"At least MS was open about having to distribute VBRUN.dll for Visual Basic apps."
Use packages in Delphi.
Adam Peter
Saturday, January 31, 2004
 Recent Topics
Fog Creek Home
| 
