Hi,

I'm just curious what people on here think about Delphi? I dabbled once before in it a few years ago when I received the IDE thingy for free and quickly gave up. I just tried it again over the last few days (almost week) and stuff appears to make a little more sense now. I still think that the click and create approach is crazy and that everything is very unintuitive but I do see how people could get stuck with it once they get the hang of it.

I just duplicated a tool with a few mouseclicks which does the same and looks similar if not better than the original I created in asm. Granted the tool is 500KB now as compared to 5kbs but the endresult is still pretty amazing.
Posted on 2008-05-08 10:03:00 by JimmyClif
It's Borland Turbo C++ in silly Pascal syntax ("type more for the same thing").
I hear it's very convenient for database apps, but I'd use VB for those.
I like the windowless-controls, but I already have that in asm - with much slimmer footprint (which is the reason for having windowless controls).

In the end, a project largely dictates what you code it in.
Posted on 2008-05-08 11:42:15 by Ultrano
The click-and-design is nice, but the code generation is horrible - and to make things work, most people link statically against the VCL, and thus get those overbloated executables.

Personally, I'd stay clear of Delphi and BCB, and if needed the RAD, I'd probably go for C#. Yeah, has even higher memory footprint and is non-native code, but imho it's a bit more interesting in the long run.

Ultrano: that isn't actually a 100% fair statement, considering that even Borland C++ Builder is dependent on Delphi for it's VCL... so it's the other way around, really :)
Posted on 2008-05-08 15:42:38 by f0dder
The first and the best IDE in my opinion. You can create programs as small as 6 KB with Delphi. I have written an article about that in http://www.asmtrauma.com. You have great ready-to-use components and you can create them from scratch if you are not happy with how they work/look/etc. The debugger is great. Won't take too much memory and CPU unlike Visual Studio. The compiler is so much faster than any versions of Visual Studio no matter what language you are coding in. Considering how many lines of code get compiled (including the USEs units) resulting in a 500 KB exe file (for example), 1-2 seconds on my 1.8 GHZ CPU is considered (to me) seemless while if I wanted to do the same thing in Visual Studio with C#, it would definitely take more time on the same machine.

All in all, I love Delphi and is the only high level language unless I am forced to use other languages because of academic reasons and etc.
Posted on 2008-05-09 11:46:55 by XCHG
Delphi is the programming language I use for everyday programming. In my opinion it's easy to learn and powerful when used properly. The debugger is good, but it lacks some functionality when debugging at CPU level (oh well, after OllyDbg nothing is near as good :) )

Posted on 2008-05-10 02:47:21 by Morris
I usually use delphi to test algo's that I want to use in ASM, or to test win32 api's (let's face it, msdn can be a bit *iffy*).
Keyword asm can be cool, too.

Make a form, drop a listbox onto it, then send 'debug' strings to it.
No need for messy dw2a and such, just list.add("I am at stage 1") etc.

Make no mistake, it's not a substitute for ASM  :lol: but quick'n'dirty it beats vb6
Posted on 2008-05-10 03:02:33 by sinsi

Considering how many lines of code get compiled (including the USEs units) resulting in a 500 KB exe file (for example), 1-2 seconds on my 1.8 GHZ CPU is considered (to me) seemless while if I wanted to do the same thing in Visual Studio with C#, it would definitely take more time on the same machine.

Do keep in mind that Delphi (and BCB) code generation sucks - definitely not something you want to use for anything critical without linking either with asm or C++ libraries :)
Posted on 2008-05-10 04:12:03 by f0dder


Considering how many lines of code get compiled (including the USEs units) resulting in a 500 KB exe file (for example), 1-2 seconds on my 1.8 GHZ CPU is considered (to me) seemless while if I wanted to do the same thing in Visual Studio with C#, it would definitely take more time on the same machine.

Do keep in mind that Delphi (and BCB) code generation sucks - definitely not something you want to use for anything critical without linking either with asm or C++ libraries :)


Another silly argument from f0dder; and you start to wonder why people don't use this board much now. One of the reasons is YOU.
Posted on 2008-05-10 05:23:15 by XCHG
Unnecessary - 'sucks' is a relative term.
What is sufficient depends on ones expectations.
If it gets the job done, and performance and bloat are not criteria, great.
If that is acceptable, thats the end of the story.
I think f0dder is trying to say that sometimes this is not acceptable, which is true.
Posted on 2008-05-10 06:41:03 by Homer

Do keep in mind that Delphi (and BCB) code generation sucks - definitely not something you want to use for anything critical without linking either with asm or C++ libraries :)

And linking sucks too...

Posted on 2008-05-10 07:16:54 by sinsi
Before you start another war, guys (:P), I'd like to see some analyses, benchmarks, examples, etc. :) I, myself, would like to learn more about Delphi, but I prefer learning based on the facts, not opinions ^^'
Posted on 2008-05-11 09:45:43 by ti_mo_n
I do have to agree with Xchg that the compilation is extremely fast. According to the timestamps in my C Drive I installed Windows around four years ago and nowadays it's pretty dang slow. (1.8 Ghz, 1 GB Ram, AMD Single Core) Still hitting the Run Button does show me my humble beginnings pretty much instantly.

I haven't really played around with it too much as I'm not used to the Delphi IDE but I'm amazed how much everything developped since I started programming many years ago. I mean when I started I copied assembly listings out of magazines and programming languages were written in either Notepad or in a similar very bare bone editor.

The Database support in Delphi is amazing. I followed a tutorial on how to drop ADO conpomnents onto an empty window, selecting a few options in their respective Object Inspector and after hitting 'Run' I had a working Database app. Adding, Deleting and changing of entries. Took me Minutes!

Posted on 2008-05-11 11:42:07 by JimmyClif
I'm not interested in a flamewar, and sorry if I hurt anybody's feelings.

Delphi is an OK tool if you want to design something quick-and-dirty, or want an easy way to make database frontends. Just like Visual Basic is a fine tool for those jobs. But I stand behind my statements about sucky code generation. The language is sorta OK, but there's a bit too much type safety for my like, mainly char vs. byte is a thing that gets in your face often.

If people would at least link dynamically against the VCL, things would be a bit better.
Posted on 2008-05-11 17:58:47 by f0dder
Waiting for proofs...

1) Don't understand how you dare comparing Visual Basic to Delphi.
2) Don't know why you think you are hurting people's feelings. You just make them (at least me) understand that you don't really know much about Delphi.
3) How is dynamic linking supposed to make the code execute faster because I suppose that's what your main argument was.

Please provide evidence of all your statements otherwise to me at least, they are worth nothing.
Posted on 2008-05-27 01:32:47 by XCHG
#1 because they're useful for some of the same things - rapid interface design and  database frontends :) (Object Pascal is a more fully-fledged language though).

#2 I don't use Delphi regularly, but I've had enough experience with it since Delphi2 to say that... OK, perhaps "code generation sucks" is a bit over the top, but it doesn't exactly generate the best code in the world. Doesn't need to, either, since you can always link with 3rd party libraries for high performance stuff.

#3 not execute faster, but result in massively smaller executables than when people link statically to the VCL. And yes, I'm aware that this has some redistribution implications and that most people are sheep, but it still annoys me to see statically linked VCL - it's one of the reasons Delphi and BCB have a reputation of generating bloated executables. (oh, dynamic linking can result in faster *loading*, especially if you use more than one Delphi/BCB app that uses the same VCL version).
Posted on 2008-05-27 07:21:43 by f0dder

#1 because they're useful for some of the same things


I believe we all know many things are used to create similar things. For example, I can use Assembly to create a program that I can create with Borland Delphi and perhaps also with JavaScript but to me, it is utterly unthoughtful to compare a programming language that:

1) has a lot more history in creating such programs than Visual Basic does.
2) Never used any external libraries except for Windows' default DLL files. Visual basic has always been dependent on Visual Basic specific DLL files. Remember how Visual Basic 5/6 programs could not be executed on Windows 98's default setup without "MSVBVM50.DLL" and "MSVBVM60.DLL" files? Delphi has always been producing real standalone Executable files.
3) Has had more built-in components than any versions of Microsoft Visual Studio programming languages have had, together over all the versions. If you put all the components in Visual Basic 4 + 5 + 6 and Visual C++ 4, 5 and 6, they still won't be as much as what we have in Delphi 6.


#2 I don't use Delphi regularly, but I've had enough experience with it since Delphi2 to say that... OK, perhaps "code generation sucks" is a bit over the top, but it doesn't exactly generate the best code in the world. Doesn't need to, either, since you can always link with 3rd party libraries for high performance stuff.


Why would I want to link to a 3rd party library if Delphi components can achieve the exact same goal in a faster way, both in execution and development time? Please provide scientific evidence that static usage of Delphi components is more sluggish than using a 3rd party library and dynamic linking. You must know better how many clock cycles it takes for a DLL to be loaded into the shared memory space of the processes and mapped to the address space of the requesting process. My program's job could be finished thoroughly while that DLL is being loaded.

#3 not execute faster, but result in massively smaller executables than when people link statically to the VCL. And yes, I'm aware that this has some redistribution implications and that most people are sheep, but it still annoys me to see statically linked VCL - it's one of the reasons Delphi and BCB have a reputation of generating bloated executables. (oh, dynamic linking can result in faster *loading*, especially if you use more than one Delphi/BCB app that uses the same VCL version).


Referring to your post, above:


Do keep in mind that Delphi (and BCB) code generation sucks - definitely not something you want to use for anything critical without linking either with asm or C++ libraries :)


I believe that your main argument was about the code being "critical" and I believe you didn't mean critical as in slow in size of the executable. You definitely meant critical as in the execution speed. For this, again, you are starting to argue about a completely separate subject. You are now talking about the size of the executable and not about the speed of execution.

One last thing before I forget. Delphi 2? Upgrade for crying out loud. Upgrade f0dder. People will throw garbage at me if I start discussing networking support in Windows and basing my opinions on Windows 3.1. One word, "upgrade".
Posted on 2008-05-27 17:55:17 by XCHG
Okay, I guess I'll have to try to be a bit more explicit, and perhaps a bit more coherent as well.

First, let me repeat that saying that " code generation sucks" was perhaps a bit harsh, but I will maintain the standpoint that Borland's compilers (delphi as well as C++) generally produce somewhat worse code than other compilers. This is based on experience with a pretty broad range of their products.

Now, obviously it isn't fair to compare Turbo Pascal 6 or BCC3 or Delphi2 code generation to anything that's available today, and back then their products compared more equally to the direct competitors (though it still pretty ho-humm - on the typical hardware than ran TP6 programs, you usually had to add a bunch of BASM to get decent speeds, and use things like Sally's Peephole Optimizer) - or patched up versions of the runtime. But that's years ago.

I have obviously used more recent Delphi versions that D2, I just wanted to imply that I've used borland products for a long time. In fact I start programming with TP6 (or was it TP5?), and loved it's IDE and integrated help system. I've used BCC3 and BCC5 (whoop, 32bit DOS programs when combined with WDOSX!), et cetera. And I was pretty disappointed when the Borland C++ libc printf got implemented using iostreams (code bloat en masse).

When I speak code generation, I (mainly) speak speed.

As for static vs. dynamic linking, I speak program size - I've never been a fan of bloated executables, and linking the VCL statically generates just that. It also inhibits code sharing between multiple running Delphi/BCB apps that use the VCL.

I'm not a great fan of VB, but I do think that Vb6 (which is about a zillion years old now) has certain aspects that are comparable to Delphi/BCB - namely ease of use, ease of interface creation, and database integration, and extensibility (Delphi/BCB has 'components', VB has OCX'es). VB is a more limited language and because of it's pcode system worse speed than Delphi/BCB so-so compilers. Anyway, I digress, I didn't really intend to "compare the languages", just say that both VB and Delphi have their strong points (code generation not being one of them ;)).

Btw, MSVBVM*.DLL redist can hardly have been a problem - zipped up the file is less than 700kb, quite doable even if you were on dialup (what's that, ~4min download on 28.8k?). If you didn't have internet back then and got a program off a CD, the CD should have included the runtimes. If not, the distributer wasn't very professional.

On the other hand, especially back in the days of dialup, people linking statically to the VCL pissed me off. Linking dynamically could have shaved off quite some download size for many of the tools I used back then. Some people might start bitching about disk space, but that has never really been that much of an issue - unless you transported things home on floppies.

Today with 8 gigabytes of ram, terabytes of storage, and 20mbit internet connections, that static vs. dynamic linking argument might be a bit moot. But then we could just give up assembly programming altogether, who caaaares anyway? Why use a smarter and more efficient method when we can just throw faster hardware at the problem?

3) Has had more built-in components than any versions of Microsoft Visual Studio programming languages have had, together over all the versions. If you put all the components in Visual Basic 4 + 5 + 6 and Visual C++ 4, 5 and 6, they still won't be as much as what we have in Delphi 6.
Perhaps, but I wonder what the figures are if you compare number of custom Delphi/BCB components to custom OCX'es? Not that I really care, you focused too much on the whole VB thing :)

Why would I want to link to a 3rd party library if Delphi components can achieve the exact same goal in a faster way, both in execution and development time?
I was referring to Delphi code generation (speed) there.

And whether you should link to 3rd-party code staticly or dynamically depends on the type of the library... something like OpenSSL goes nicely in a DLL because it's used by a lot of other software. VCL would be nice dynamically if more developers linked dynamically, because it's relatively huge, and standardized.

Ooooooh well. You're happy with Delphi, stick with that, I'm not saying it a super bad product or anything - just that it's code generation is sub-par.
Posted on 2008-05-27 20:19:23 by f0dder
Still can't believe you are comparing VB with Delphi.

Clone CD, Clone DVD, WinSCP, Spyware Doctor, Skype and dozens of other commercial and noncommercial software are written in Borland Delphi/C++ Builder. Skype has a 20MB executable actually and everything works smoothly. I don't have time; if I had, I would post a list of other major software written in Delphi/C++ Builder.
Posted on 2008-06-12 10:19:01 by XCHG
Let's just forget this and move on, and agree to disagree :)
Posted on 2008-06-12 16:52:28 by f0dder