The Old Joel on Software Forum: Part 4 (of 5)

Delphi

I realized there are a number of Delphi experts here so I'd like to ask some questions.
How does Delphi 7 compare to, say, VB6 or VC++, performance-wise? And what about ease of development? More importantly, will it be here in the long run? If I started a Delphi project today, would I still have Borland support and new versions of Delphi 10 years from now?

I know some of these answers are on the net, but I'm looking for some personalized answers, like "hey, in a project I was in we....". Let's just say I learned to trust you guys.

TIA

RP
Thursday, April 15, 2004

I love Delphi and want to have its babies.

Within our development teams, the view from people who have used other languages is generally that it eats VBs lunch in terms of delivering professional code, speed, etc.

Comparing it with C++ is more problematic. It's faster and I prefer it personally but there is a much larger C++ community than Delphi community.

The chief architect for Delphi is now doing the same job for .NET and Delphi supports .NET so there is a family resemblance and migration path there.

There is good third party support for Delphi and there are no signs of its imminent demise. Borland is fairly solid, but not as solid as Microsoft.

We deliver 15 Delphi written applications for sale to customers. It is fit for purpose and I don't think many people have been fired for choosing it.

Borland tend to give away old versions on consumer magazines, so you have to watch out for people who say 'I am a Delphi programmer' cos it aint always necessarily so.

Woodentongue
Thursday, April 15, 2004

Agree on the eval - Delphi runs away from VB6, and can be in the running with C++ on performance. That having been said, with the new Delphi 8/.Net saga - you choose your market. If you want to keep with native code, then Delphi 7 is still a definate strong runner technically. But from a market standpoint, proclaiming Delphi expertise will generally not help. Fortunately C# isn't bad at all, so when I made the changeover there wasn't a lot of pain involved, and quite a bit of gain.

Unfocused Focused
Thursday, April 15, 2004

"If I started a Delphi project today, would I still have Borland support and new versions of Delphi 10 years from now?"

How can you expect anyone to answer that? We're not soothsayers.

John Topley (www.johntopley.com)
Thursday, April 15, 2004

>Comparing it with C++ is more problematic. It's faster ...

It's faster?

Thursday, April 15, 2004

> How does Delphi 7 compare to, say, VB6 or
> VC++, performance-wise?

Delphi 7 has a true compiler which compiles to machine code.

The generated code is:

- a lot faster than Java
- significantly faster than VB 6
- a bit slower than Visual C++

Another advantage is that the resulting .EXE is self-contained (except for the case where you use an external database engine): the EXE contains everything, no more DLL hell.

> And what about ease of development?

Once you get used to it, I belive it is the most efficient tool there is.

> More importantly, will it be here in the long run?
> If I started a Delphi project today, would I still
> have Borland support and new versions of Delphi
> 10 years from now?

I can't really answer that, but:

Delphi 1 was released more than 8 years ago.

Borland enhances Delphi a lot, but usually doesn't change the existing libraries and language features.

So, that means a program developed years ago using Delphi 1 can be ported to Delphi 7 quite easily.

This is NOT true for VB, where Microsoft often makes significant changes to already existing stuff, breaking your applications.

The controls that come with Delphi are more powerful than the ones that are usable from VB.

From Delphi, you can also use any ActiveX control, so what is available in VB is also available in Delphi.

There are lots and lots of advanced third-party components for Delphi - check out http://www.torry.net/

MX
Thursday, April 15, 2004

I wrote a program in Delphi that would generate a triangulated Bezier surface (according to a procedure that generated the control points), do all the world-space/camera-space/projection transformations, clip and rasterize every few milliseconds (producing an animated fluctuating surface). This program was inefficient in a number of ways, but still it used about 25 to 50% of my processor time. Then I ported it (line by line) to C# and it used 95 to 100% cpu time. It'd probably be about the same as the Delphi version if I ported it to C++.

But what's probably more important to most programmers is the size and utility of the libraries. Borland's VCL is very large and useful for a number of things. They've got great basic date/time and statistical functions. Unfortunately I never found a regular expression class in there and I had to write my own. It's very easy to make 'custom controls' with Delphi, and in general the 'native Delphi custom controls' can be translated into ActiveX controls with little trouble.

A significant problem with Delphi is its language. There's no multiple inheritance, no operator overloading, no templates, and no interlaced variable declaration. It's probably not going to be used to write a lot of physics simulators. But it's great for making basic Windows programs.

Kalani
Thursday, April 15, 2004

> Unfortunately I never found a regular
> expression class in there and I had to
> write my own.

I use TRegExpr from http://regexpstudio.com/

It's freeware and, in my opinion, it's also pretty good.

There are also other regular expression libraries, which you can find at http://www.torry.net/

> There's no multiple inheritance,

There is multiple inheritance from interfaces - exactly like in Java.

> no operator overloading, no templates, and

Exactly like in Java.

One of the great advantages Java had over C++ was the lack of many error-prone features.

The Delphi object model is very similar to the object model in Java.

MX
Thursday, April 15, 2004

By multiple inheritance I meant multiple implementation inheritance.

It's interesting that you describe operator overloading and templates as error-prone features. Why do you feel that way?

Kalani
Thursday, April 15, 2004

>>Comparing it with C++ is more problematic.
>> It's faster ...

> It's faster?

If he's talking about compile time, then yes, it's faster.

If he's talking about performance, then I doubt it.

Paulo Caetano
Thursday, April 15, 2004

"It's interesting that you describe operator overloading and templates as error-prone features. Why do you feel that way?"

I believe it would be better to call them "easily-abused" features.

When I was learning C++ I remember going crazy about the "cool" factor in operator overloading, to the point of arguing it as an indispensable feature for any serious language. And, naturally, I promptly abused it. I've since cured myself of these afflictions.

Fortunately, my knowledge of templates has always been too basic for abuse :)

Paulo Caetano
Thursday, April 15, 2004

Some time back I was pulled into Delphi kicking and screaming, coming from the world of hand-crafted Win32 (I shunned even MFC) calling C++. As a bit of history, prior to that I had attempted to get to appreciate Visual Basic, and I found it incredibly questionable as a development platform: Poor performance, horrible worst-of language, clunky IDE, incredible array of arbitrary limitations, etc. What a refreshing difference Delphi was from my VB experiences. (As an aside, the limitations previously mentioned regarding Object Pascal apply to C# as well, so obviously they aren't THAT important if brand new best-of languages avoid them)

Before long I got to love Delphi for feature rich Win32 GUI clients -- it is simply unparalleled in this arena (and it REMAINS unparalleled. C# and VS.NET 2003 is absolutely clunky comparatively). Performance was very important to me, and it was comforting to discover that Delphi apps compiled extremely tight from both a resource, and speed, perspective, and of course deployment is a breeze as long as you stay away from the excrement known as "BDE". I would still drop to C/C++ for some tasks (and Delphi's excellent COM support made this a breeze), for example doing CRC32 calculations on files using overlapped I/O, but this was required very infrequently because in most cases Delphi and C++ were comparable in performance.

Having said all of those glowing remarks about Delphi, personally I think its future is very unlikely - Borland took a tentative jab at cross platform (which is seeming more and more like a brilliant idea that could get traction) and withdrew, and then dedicated a lot of resources to making a pretty questionable value .NET development tool. Borland sales seems to have abandoned Delphi to being nothing more than a fringe product, preferring instead to pimp their modeling and integration tools. Personally I think optimism about the future of Delphi is a demonstration of denial.

Dennis Forbes
Thursday, April 15, 2004

Personally I see little reason to continue with Delphi for the long term as the future is obviously .Net on the windows platform. Short term Delphi can be a good fit if your delivering a project relatively soon (say under a year) and low installation footprint is a requirement. For example, maybe your organization is not ready to widely distribute the .Net runtime. Also, software for consumers would be a natural fit for Delphi (for example something like CityDesk). For most reasonably sized business apps I would tend to believe you would be better off biting the .Net bullet now.

IMHO Delphi will continue to wither as Delphi 8 does not offer any compelling advantages over just working in C# and Visual Studio.net directly.

On a personal level, I am currently in the process of looking at porting one of my projects from Delphi 5 to .Net. My plan is to re-architect the product at the same time so I would not get much code re-use out of going with Delphi 8 anyways. In this case I find sticking with Delphi to be of little benefit.

Gerald
Thursday, April 15, 2004

Delphi = make more money and have more fun

In recent years (esp since Delphi-architect Anders became C#-architect), MS and Borland have become close buddies: you can depend on Delphi's future imo.

Joe Hendricks
Thursday, April 15, 2004

Is the future obviously .Net? Or is it going to be another short lived M$ technology rapidly replaced by another idea that does the same thing?

I suspect the latter.

Mr Jack
Thursday, April 15, 2004

My opinion is this:

1. Do you work for a corporation for in-house database apps? Then C# / .NET is the way.

2. Do you develop applications which must have very rich user interfaces? Then Delphi is the way.

3. Do you develop applications which must be distributed to many users? Then Delphi is the way.

I have used both VS .NET and Delphi, and in my opinion, right now, Delphi is superior to VS .NET in all the 3 points above, including point 1 where I recommended VS .NET.

Delphi will do the job better than VS .NET.

However, Microsoft is very commited to pushing VS .NET. That means VS .NET will grow and evolve very quickly, and since Microsoft is targetting enterprise in-house development, that is the position VS .NET get.

So, if you develop in-house database apps or web sites, it is better to switch to C# / .NET or to Java now and have the experience on your resume.

However, if you want to develop programs which have one or more of the following:

- rich user interface

- high performance

- must be distributed to many users

- very easy access to Windows API (in Delphi, you just call the function, no need to declare)

- access to lots and lots of high quality 3rd party components

then I recommend you to switch to Delphi. :-)

MX
Thursday, April 15, 2004

>When I was learning C++ I remember going crazy about
>the "cool" factor in operator overloading, to the point of
>arguing it as an indispensable feature for any serious
>language. And, naturally, I promptly abused it. I've since
>cured myself of these afflictions.

But it sounds like the only argument you had for wanting it in a language is the "cool" factor. That's what your problem was -- misunderstanding the value of that feature.

There are tons of practical arguments for having operator overloading features in a language. Type-safe smart pointers, function objects, consistent serialization, iterators, type-safe simple sequence ordering, and simple syntax for high-level mathematical objects are all examples of great uses of operator overloading.

>Fortunately, my knowledge of templates has always been
>too basic for abuse :)

But I think that's *unfortunate*, because you miss out on (for example) the greatest use of operator overloading. Look at the source for the STL sort (or stable_sort) function. It says that as long as the iterator types allow random-access syntax, and the contained type defines an order on its values, any sequence of any type can be sorted. That's a very useful form of abstraction.

Kalani
Thursday, April 15, 2004

"However, Microsoft is very commited to pushing VS .NET. "

As an aside, a lot of VS.NET adoption has to do with FUD (which is one of the reasons why it's tough to win against Microsoft on their own turf): I was involved with one organization where an astronaut was advocating an immediate switch to .NET not based upon reality, but based upon the spurious contention that the entire Windows platform was going to .NET (with services such as MSMQ being .NET "native") and Win32 would be the second class citizen, if it would be supported at all. This sort of argument has killed Delphi all over.

While it seemed lke a loser at the time, Delphi really had a potential winner with the CLX initiative (especially if they added platforms) - A high performance, native compiled, cross-platform language and GUI set.

Dennis Forbes
Thursday, April 15, 2004

>(As an aside, the limitations previously mentioned
>regarding Object Pascal apply to C# as well, so obviously
>they aren't THAT important if brand new best-of
>languages avoid them)

Sorry Dennis, but that's not much of an argument. In any case, I'd immediately disagree that Java and C# are "new best-of languages".

Look at where Java and C# are going in terms of language features. They're adding generics (templates, essentially), and (this is great) closures and continuations. Isn't that hilarious? Not only are they working hard to support features from an ancient language like C++, but they're even sending out paleontologists to find Lisp!

What's the value in restricting what can be expressed in a language? If it's supposed to be a general-purpose language, I think it's clear that there's no value in that. So the question is more about whether or not your problem domain maps well to the intended domain of a more restricted language. Are you making internal CRUD database applications? Then you can probably safely ignore those features that physicists and linguists find so valuable if the language makes *your* job easier.

Kalani
Thursday, April 15, 2004

>(As an aside, the limitations previously mentioned
>regarding Object Pascal apply to C# as well, so obviously
>they aren't THAT important if brand new best-of
>languages avoid them)

One thing I do like about Java and C# over Object Pascal is that interfaces and objects have identical semantics and are treated identically. Interfaces in Delphi for Win32 have a very crusty feel to them after you have worked in Java and C# for awhile.

Gerald
Thursday, April 15, 2004

"Sorry Dennis, but that's not much of an argument."

My point is that clearly they aren't atop the mandatory, absolutely required feature list if they were excluded from the design document when someone had a chance to begin anew with all that has learned: For the overwhelming majority of development they are frivilous or outright unnecessary. Generics will be nice for a couple of edge "collection" cases, and anonymous functions might save a couple of keystrokes, but neither extend the easily possible in any significant way.

Dennis Forbes
Thursday, April 15, 2004

Does anybody actually want multiple implementation inheritance?

Implementation inheritance is overused (or at least inappropriately used) anyway, most advice seems to be to favour composition.

John Topley (www.johntopley.com)
Thursday, April 15, 2004

Sure, that's one way to interpret it. Another way to interpret it is that the language designers didn't know how valuable these other features would be (consider where C# came from), or that they specifically excluded features to target a niche (eg: Gosling's statement that he's aiming for "mainstream programmers").

There are many examples of using templates for very practical purposes that go far far beyond collections. If I had the time, or you had the interest, I'd happily describe some of them.

Yes part of the implementation of closures in languages like C# will allow anonymous functions, but lexical scoping is just as important to have in your language. And these things certainly *do* extend the "easily possible".

In fact, with features like continuations there are things that you can express very easily that can't be expressed at all in many other languages. I described an example just about a month ago on this board that had to do with writing a generic framework for network servers. Here's the example:

TCPServer(80, (iostream& conn_stream) { conn_stream << Eval(ParseHTTPExpr(conn_stream)); });

In that single line of code you set up a listening socket on port 80 and define a function for handling connections. Eventually somewhere you'll ask 'conn_stream' to get a character out of the network buffer for your connection when there isn't one available. In that case you want to allow execution to continue for any other connections that are waiting for data, or for the main server socket itself which ought to be listening for connections. Continuations make that possible. The conn_stream::get_char method will pack up the state of the current computation and send it back to the TCPServer implementation (bypassing the actual connection implementation we provided in the middle) where it can be reinvoked if necessary.

Kalani
Thursday, April 15, 2004

Yes John, I want implementation inheritance. It's true that some people misuse it, and if that's an important consideration on some big project (ie: the risk of one of my programmers going crazy and writing horrible code is greater than the risk of less maintainable or more slowly implemented software) then sure I'd be right there in line with everybody else asking for a language without multiple inheritance.

But in general I've used it to great effect too many times to get rid of it for my own use.

Kalani
Thursday, April 15, 2004

"If I had the time, or you had the interest, I'd happily describe some of them."

How about in a nutshell? I'm very interested.

Dennis Forbes
Thursday, April 15, 2004

That makes 2 of us. Very very very interested.

RP
Thursday, April 15, 2004

"But it sounds like the only argument you had for wanting it in a language is the "cool" factor. That's what your problem was -- misunderstanding the value of that feature."

I never said the opposite, i.e, I know it was my mistake, not any problem with the feature :)

My point is - how many people make a mistake similar to mine? How many do it in production code. How many headaches does it cause? How much does it cost?

"There are tons of practical arguments for having operator overloading features in a language."

I'm not saying "remove operator overloading and templates". Quite the opposite - I think the STL is one of the best additions to C++, and it's one of the features i most missed when I worked in Deplhi. I'm just saying that these features are very easy to abuse.

"But I think that's *unfortunate*, because you miss out on (for example) the greatest use of operator overloading."

I use it. I just don't worry too much about how it's implemented. I define whatever methods/operators/copy ctors are necessary to use my classes in STL containers, and I do my best to make sure it's done correctly - usually, with a great deal of help from Scott Meyers :). But I try not to go any deeper than I need to.

Paulo Caetano
Thursday, April 15, 2004

I have an additional question. What about Delphi and Kylix.?
Does this really make moving from a Win to Linux environment easy?
I have not done anything targeted for a Windows box in years (my area is embedded, not desktop). I need to do some applications for monitoring/comunication with an embedded system. Would Kylix and Delphi be a viable combo for write once, build twice and work everywhere?

Doug Withau
Thursday, April 15, 2004

OK. For the full details I could email you the complete source code of some utility classes I've written. I'll just go through a few descriptions here and you let me know if you think it's valuable (or ask me why templates are necessary to do it).

Smart pointers: given some type T, generate a class that controls the release of some data, but which can otherwise be treated like a normal pointer to the data.

Monitored value: given some type T, generate a class which behaves just like T except that it calls a sequence of functors (monitors) each time a value is assigned to the class. You can drop this into some existing code (especially a big mess that you inherit from your organization) to see how the execution of your program looks from the perspective of one variable (especially useful for global variables used all over). You could use it to implement a multi-read single-write locking pattern for any kind of data. You could use it for recalculating dependent variables (eg: left, right, width : change left or right, recalculate width, change width, recalculate right).

A generic automaton: given some type E (the element type), S (the state type), and M (the implementation class type), generate a class that maps items in C(S) to member functions of M (where C(S) is the set of states including "meta" states like "start of element sequence", "end of element sequence", and "any state at all"). Have this class take an input sequence (of type E) and feed it to the member function associated with the current state. If that function executes a transition to a different state, call any transition functions that are defined as well (giving them the entire sub-sequence captured from the point of being in the first state up to the point of transitioning to the second state). This has been very valuable for writing fast parsers in a very clear way (and it works on any kind of sequence of data, not just character sequences).

There's the famous example of expression evaluators for optimization of mathematical expressions: http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html .

Unique ID generator: I worked on a very old project for this company and the 'rdbms' they used didn't support auto-number fields. So I made a class like this for generating those values:

template <class DataType>
class PKValueGenerator
{
...
static unsigned int LastPK;
...
};

And for my data types:

class UserRecord : public PKValueGenerator<UserRecord>
...

Then in the DB-handler library I wrote for them, I could initialize each PKValueGenerator<T>::LastPK value (each table has its own) and when inserting a new record of type T, use ++PKValueGenerator<T>::LastPK as the new primary key value. It was small amount of code that made it look like this DB natively supported auto-number fields.

Kalani
Thursday, April 15, 2004

"Would Kylix and Delphi be a viable combo for write once, build twice and work everywhere?"

Yes, except for the fact that Borland has (at least for the moment) halted development on Kylix because of lack of demand. I know of developers who are still happily using Kylix, but the future for it is very uncertain.

Borland C++ Builder X tools might give you the cross platform development you want. Windows, Linux, Solaris. It includes graphical components built based on the cross-platform open source wxWindows library.

Herbert Sitz
Thursday, April 15, 2004

"It includes graphical components built based on the cross-platform open source wxWindows library. "

It includes wxWindows, period. Nothing you can't download for free, with wxWindows, Eclipse and the C development add-ons, and MinGW, you pretty much have C++BuilderX for zero dollars.

I have a copy of CBX and I am underwhelmed.

Mitch & Murray (from downtown)
Thursday, April 15, 2004

Whoa, thanks for the correction. Much different from what my understanding was.

The old C++ Builder included and was mostly compatible with the same set of native and third party VCL components as was included and supported by Delphi, wasn't it?

And now C++ Builder X includes only wxWindows and no components or widgets beyond what are included with freely available wxWindows?

Herbert Sitz
Thursday, April 15, 2004