Delphi – why won't it die? (2013) | Hacker News Reader

Delphi – why won't it die? (2013)

stevepeacocke.blogspot.com

163 pointswx196162 comments

My employer has a multi-million line codebase in Delphi which is still under active development. I mostly do web development, but every once in a while I go back in to build a feature on the Delphi side of the fence.

The IDE itself is dated and no longer competitive with the best of the modern IDE's. The language and API however is updated and productive. You just need to get over Pascal-style syntax instead of C-style, and you are just as productive in it as if you were using C#.

Why is delphi still hanging on?

1. It delivers executables that need no dependencies. No VM's, no runtimes, no add-on dll's. Underneath it only needs x86 and win32 (unless you're building for mac, android or iOS, which it also supports). I wouldn't be surprised if our software still ran on windows 2000. Since the code is native, performance is never a problem even with wildly inefficient code.

2. It lets you build GUI software really quickly. Productivity in delphi for someone used to it matches any "modern" GUI development platform. Sure, the IDE misses a few features that competing IDE's have, but on the plus side it compiles ridiculously fast (a full build of 2 million lines takes less than a minute on a single core).

3. Delphi is the easiest platform by far to have legacy code on, because the maintenance cost is very low. Delphi's contemporaries (classic VB, MFC) have all gone through major upheavals. Delphi has managed to modernize the API's without breaking legacy code too badly (they even managed to elegantly retrofit unicode into the platform). This is why codebases that are based on Delphi somehow never get ported away from it.

Delphi's competitive with other desktop and mobile development platforms, even at what they're charging for it. What they're charging for it is the problem though. Only people already using delphi buy delphi, and so the perception is maintained that delphi is effectively dead, even when it isn't.

The great thing about Object Pascal is that, unlike C or C++, it was designed to compile really fast. Pascal units completely remove the burden of C++ header files. In the end, you are almost as productive as with a dynamic language and you still have compiled code. I haven't seen another language to get even close to the balance achieved by Delphi in this respect.

D perhaps?

It's also designed to compile fast and to native code. Maybe it's not as mature and robust as Delphi yet though.

I fondly remember installing a Pascal interpreter card in my Apple //e for UCSD Pascal - a branch of Pascal running in a VM. https://en.wikipedia.org/wiki/UCSD_Pascal

Oberon-F on classic Mac OS was really productive, and I imagine its descendant, BlackBox Component Pascal on Windows is so as well: one of the great features was the ability to extend the IDE while running it: you could compile an extension and test it in seconds. Wirth knows how to design efficient languages and systems, and his students (most of the founders of Oberon microsystems, the developers of BlackBox, were such) carry on the tradition.

Have you heard of Nimrod? (http://nimrod-lang.org)

Compile-time wise it is very impressive (the compiler which is self-hosting compiles in under 30 seconds on my computer). It also resembles Delphi and Pascal in some ways and I am personally very productive with it.

Even C++ compilers (except gcc) mostly compile themselves in under 30 seconds. How is that impressive ?

Delphi compiles source code almost as fast as it can read it from disk. Megabytes of sourcecode per second on a 486.

Which C++ compiler compiles itself in under 30 seconds on a typical desktop? Clang takes at least a minute or two even at -j40...

While not Delphi, I really like it and I am playing with it now, thanks for mentioning it.

Nimrod is great. It is definitely inspired by Delphi/ObjectPascal. I keep trying to come up with an excuse to use it for a project.

Lua, LuaJIT provide the same sort of kick, in my opinion. The language supports easy integration with pretty much any syslib, and well .. its a fine way of doing a lot of things. Anyway, its my '21st Century' Delphi, anyway .. haven't written much Delphi code since the late 90's, but I'm sure glad its still around and kicking.

After building gui apps in c++/mfc, I tried delphi. It was amazingly productive. The closest thing I can compare it to is going from java/tomcat to rails; that feeling of getting so much actual work done is what makes delphi (and rails) stick.

I tried building an app in MFC after programming in Delphi/Borland C++ Builder. And my reaction was "Nope. ... Nope. Nope."

I was overwhelmed by the feeling that designer of MFC doesn't want me to get anything done but instead wants to take me on neverending tour of the peculiarities of underlying libraries that were built for 16bit ancient windows.

This is spot-on. The university I attended offered a MS MFC certification trail ('97), I politely declined after using Borland C++ Buider during my internship. MFC had so much Win32 cruft percolating out of everywhere! I was amazed the VCL managed to insulate the user from most of it.

I heard high price also killed smalltalk. Can't they freemium, with minimal loss of existing business?

I am not entirely convinced that unicode has been retrofitted elegantly into Delphi. A lot of legacy functions using string (read: what is now AnsiString) have been modified to still support string; so AnsiPos() for instance takes string, unless you use AnsiStrings unit. And that's just confusing.

In a code base like the one I work with all the way back to Delphi 3, there are other legacy issues as well; such as the late arrival of TBytes, which meant that in olden days you had to handle binary data in strings. Now suddenly they are unicode strings are far less reliable for unicode.

Of course, the compiler doesn't warn you about that, because it isn't clear what you were doing back then. Still, took us a year to get our code from Delphi 2007 to XE3.

I am not saying Delphi is the worst thing ever, but I wouldn't say its legacy support is as elegant as you put it. There are issues, that are not noted by the compiler (unlike the deprecated flag for old functions and the like).

Also the fact that it used to have both {$ENDIF} and {$IFEND} is amusing, but at least now they only want one; but you cannot change it because then it would break code that needs to be compiled in an older version of Delphi.

Edit: But I will say this: I do believe unicode was introduced into Delphi as elegantly as possible. It's very hard to do truly elegantly, I'd imagine.

Well, when I say that they retrofitted unicode elegantly, I'm ofcourse comparing it to how unicode was retrofitted into PHP. Elegant is in the eye of the beholder I suppose.

The same goes for maintainability. Upgrading the codebase was a sizeable effort for sure, but in my view it was less than it would have been had it been developed on another platform.

Unicode was retrofitted into PHP and then the entire effort was abandoned, so yes, i think anything would be more elegant.

PHP currently supports unicode in the same way as lua or C - every string is a binary string. If you want correct UTF-8 behaviour in string functions then instead of using libc or string_ functions, you must pass the character set as an additional parameter to specialised mb_ string functions instead.

talk about python and unicode management...

Binary data in strings? "array of byte" surely?

And if you prefer C++, there is Embarcadero C++ Builder. Interesting that it gets a somewhat less attention generally.

I've used C++Builder (the 200x versions) and I really can't recommend it. Lots of compiler bugs and no improvement from release to release.

I use CB2007. For all the bad things I've said about it ... it is nice. Actually "Delphi" and C++ Builder are not what makes these products interesting ... it is the VCL library and GUI designer that they ship with that makes them so interesting and productive.

But ... I threaten to move to VS2008 and make pure WinAPI applications. However, with no GUI designer and GUI library it is maddening building anything large.

"Since the code is native, performance is never a problem even with wildly inefficient code."

Remarkable!

Yeah. I've written wildly inefficient code in Delphi. And guess what, O n-squared complexity is still a killer when n gets large.

Precisely.

> it compiles ridiculously fast

Courtesy of its simple precedence grammar ... as we all undoubtedly remember ;)

http://en.wikipedia.org/wiki/Simple_precedence_grammar

I don't know if Delphi still does that, but Wirth-style compilers also tends to avoid an AST in favour of calling the code generator directly from the compiler, and Turbo Pascal at least used to do that.

Actually, Delphi/ObjectPascal's compilation speed comes mainly from being a one-pass compiler. Code is translated directly to native code per compilation unit, and since there is no "header file hell", each unit is an independent part whose generated code can be cached in its entirety, so during a single compile, if you have changed just one unit, the compiler only needs to compile that unit (plus dependencies) and then perform linking. The linking is much less complicated, too. Delphi also benefits from having a hand-coded parser and not too many machine code optimizations. I think the simplicity of the grammar may contribute some, but probably very little.

Excellent post.

Yeah the build times were stupidly fast.

Lead to some bad habits though - e.g. Why debug when you can trial & error 10 solutions per minute (on a weak box)?

The first time I used VB/C++ I thought the IDE had crashed because it took so long to build...

Why debug when you can trial & error 10 solutions per minute

Isn't this TDD?

>>Isn't this TDD?

More like a 17 year old too lazy to learn proper debugging, but yes - it works and I'm not surprised its got an official name. :D

Delphi takes it to a ridiculous level though. Often its faster to trial & error the exact syntax for a function than to look it up on the help.

While it's useful to learn proper debugging sometime your approach is valid as well. By the looks of it you're using the optimal solution to your problem.

I prefer to code in Common Lisp on the REPL and do the same thing as you most of the time since each iteration step is so fast. (Change a function -> update it in the live running environment -> test ...)

If you want to try Delphi Lazarus with Free Pascal (http://www.lazarus.freepascal.org/) makes for a pretty close FOSS reimplementation of the same Object Pascal language and the RAD IDE functionality. The IDE is reasonably mature but sadly not fully compatible with Borland Delphi 7, so you can't quite rely on a Delphi tutorial. It is cross-platform. The language combines reference counting and manual memory management, has modules and handling strings in it is pleasant compared to (vanilla) C or even C++ (which it is meant to compete with). Unfortunately, last I checked the Unicode support was imperfect.

One thing I've been wondering about lately is if Free Pascal is a good alternative to C or Go for shipping self-contained static binaries to run on *nix. I haven't tried it yet but the small(ish) static binaries the Free Pascal compiler produces and the lack of libc dependencies in theory make it an attractive option if you want to write something to run on OpenWrt on your router. Has anyone here used FPC for that? How are the MIPS and ARM backends?

I pick up Lazarus ever so often because I loved Delphi (it was my competitive edge; everyone was doing VC++ and I ate their lunches. And dinners.) back in the day. Lazarus as being FPC + libraries is great, but the IDE is still really bad in my opinion. It is unstable to say the least. I wish it was more solid or that Embarcadero would just get smart and open source the whole thing so it actually would have a chance. I'll keep checking though...

Adding my 2c to this discussion:

I saw just recently, via SourceForge's email newsletter, that Free Pascal made it to SourceForge Project Of The Month (POTM):

http://sourceforge.net/blog/april-2014-project-of-the-month-...

I've used various Delphi versions, a little, for personal projects [1], off on on, and liked it. A pity that the free Turbo Delphi Explorer version was discontinued. (TDE was released and then stopped when Borland was in its CodeGear incarnation some years ago.) As others have said, hope Embarcadero comes out with a low-end free or low cost version of Delphi. (They did have a Delphi XE Starter Edition, not sure if it is still there.) I've also read off and on that Delphi (and other Borland products) were/are big in Germany and other European countries.

[1] http://jugad2.blogspot.in/2010/08/digital-clock-v10-in-3-lin...

Re [1] above: Image of the digital clock gone from the post, sorry. But it was just a narrow horizontal window with a text box in it, that showed the current time, updating every second, something like the LED digital clocks you see at railway stations or airports.

If you want to compile static Linux binaries, Musl libc is your best bet. http://www.musl-libc.org/ - works with most things, and it is small. It has Mips and Arm support.

I wrote DDJ's first review of Delphi back in 1995. Maybe it deserves to die, or not, but I get a kick out of the fact that it is still around and sparking discussion. At the time of release its features were quite innovative, and very accessible to the Turbo Pascal programmers (like me!) who were a big part of Borland's customer base for tools. If I recall correctly a lot of Delphi's DNA ended up in C++ builder, and then a lot of the C++ Builder guys ended up at Microsoft... so Delphi has earned its place in the anthropology of our business.

Awesome ... appreciate your perspective. Hang around here and keep us kids in line.

Software has got to be one of the most interesting industries, where among genuinely skilled people you can have such shockingly divergent opinions on really quite simple questions.

From the article:

> Being highly productive has seen single Delphi developers produce software that would otherwise require a team of 5 developers. I’ve been in a team of 3 developers that out programmed a corporate wide application by having it up and running in a few months compared to another team I know of over 30 Java developers who 18 months later still had not produced their application.

I believe this to be completely true. At least for boring internal enterprise apps within corporations, the new languages/platforms and especially modern program design paradigms with their multiple tiers & supporting libraries, multiple levels of indirection resulting in 30 level deep call stacks, etc results in productivity perhaps 1/4 of what you could achieve with a product like Delphi.

Now this is just my opinion, and it is shared by many others, but there are even more who would vehemently disagree. Yet this isn't some "eternal mystery" class of a disagreement, for the type of application that Delphi is appropriate (very important), it can be very easily demonstrated if it is or is not more productive for the task at hand - the differences are so stark that the conclusion is undeniable. Yet, if you were to propose Delphi as a development platform, it would in most cases be career suicide.

I would suggest some of the main reasons for this are:

- as a developer, choosing Delphi is virtually career (skillset) suicide

- it lacks much of the more modern "cool" language features developers so love to play with

- (as a result) choosing Delphi as a platform is risky due to the small and shrinking developer base

> for the type of application that Delphi is appropriate

What type of application is that, in your opinion? Would you use it for a web-based app? (Many boring corporate apps are now web-based, and not just because the developers want that. The business people often want it too.)

> new languages/platforms and especially modern program design paradigms with their multiple tiers & supporting libraries, multiple levels of indirection resulting in 30 level deep call stacks, etc results in productivity perhaps 1/4 of what you could achieve with a product like Delphi.

Modern languages don't particularly encourage or discourage that style of programming. Let's assume we're comparing Delphi to Ruby and Python as the modern competitors for the high-productivity, just-get-it-done language. Those languages have standard libraries with rather minimalist APIs, so I don't see the bloat there.

Now, it's true that frameworks in those languages, like Django and Rails, and huge and have deep callstacks and lots of indirection.

But those frameworks are big because their problem domain (dynamic web app development) is so big and complex. I challenge anyone to find a framework in any language that 1) is as powerful and flexible as Django or Rails, 2) is sanely coded, and 3) doesn't have deep call stacks or lots of indirection.

Maybe I'm way off base, and you're not talking about web development at all. I went that direction because web development is what I think of when people start talking about boring business apps.

I can't comment on the web capabilities of Delphi specifically, I'm thinking your standard boring enterprisey CRUD app with various calculations/business logic/reports, etc....thousands of new apps of these kind are written every year, nowadays typically with a web front end (regardless if that's really necessary, all things considered). For most complex applications, a client based GUI is superior for power users, the portions of the app that need widespread distribution can be implemented with a web interface.

The big difference to me is the automatic binding of data from the database through to the UI, you're "done" the requirements so quickly that the currently standard practices of "improving" things with some design patterns and what not gets skipped. It's not so much that Delphi's language capabilities are superior (other than the binding), I think it's that so much of the currently fashionable bloat is more likely to be skipped.

> Modern languages don't particularly encourage or discourage that style of programming

I agree...this is not forced on us by modern languages, it is current culture/fashion. There are so many cool geegaws out there today, it would be a shame to not use them such that you can include that experience on your resume (to hell with the additional costs and complexity, let someone else worry about that.)

Great comment, and I agree. I'd just add that it's probably more like tens of thousands of "new apps of these kind" that are written every year ...

I'm assuming you meant the last paragraph of your comment in a sarcastic way :)

> What type of application is that, in your opinion? Would you use it for a web-based app? (Many boring corporate apps are now web-based, and not just because the developers want that. The business people often want it too.)

I think this is mostly a lament of how very, very, very horrible web-based apps are for the developer. Delphi gets you pixel-perfect interfaces that work on a 486 with windows 95 right up to todays windows 8 (there is a version of delphi that would get you 3.1 support as well). With one recompile, the same app runs on android, ios. I have trouble writing a web-app that supports 2 browsers (and especially have not found a way to test that this is so without manually going through the app), yet every delphi app supports over 8 runtime environments.

> Modern languages don't particularly encourage or discourage that style of programming. Let's assume we're comparing Delphi to Ruby and Python as the modern competitors for the high-productivity, just-get-it-done language. Those languages have standard libraries with rather minimalist APIs, so I don't see the bloat there.

On the web there just isn't any other way of doing things. This is supposed to be flexible and "good" design, but here's the catch : changing one tiny thing in the backend requires you to change (e.g. go from 1 to 2 phone numbers per customer) :

1) the backend itself

2) the business rules in the second tier

3) the RPC/REST/... interface to the second tier

4) any and all frontend code interacting with this data

In delphi, by contrast, you change the backend, and that's it. At runtime, mind you, you don't even need a recompile in most cases. Tables will automatically start showing it, forms will magically contain the new field.

> I agree...this is not forced on us by modern languages, it is current culture/fashion. There are so many cool geegaws out there today, it would be a shame to not use them such that you can include that experience on your resume (to hell with the additional costs and complexity, let someone else worry about that.)

I think part of the question being asked here is "how do these help application development" ? How do they improve the applications ? Well, they make them worse.

> What type of application is that, in your opinion?

Not the OP, but I wanted to chime in that I think Delphi's forte is, was and will always be desktop-based GUI apps. That was always the main point.

Admittedly, I haven't touched it since the early 2000s, but I can't imagine that it could compete as a language/platform for anything else these days. Its power comes from the tight GUI design/language integration, the brilliance of which is still unmatched by tools like Interface Builer; but the language — even with features like generics — hasn't been able to keep up.

That said, in the late 1990s/early 2000s, I was actually using Delphi for headless backend apps. They were distributed, fairly complex backends connected using DCOM and interfacing with Windows technologies like TAPI and MAPI. We had to integrate with C libraries (linked as DLLs) and had to convert the header files to ObjectPascal. I actually wrote a tool called htrans that had a hand-coded C/C++ parser that produced very good ObjectPascal translations, but it was still a chore. Talk about going against the grain.

In hindsight, I should probably have been using C++, and a lot of the problems our team had was due to the fact that we were trying to use Delphi for something that Borland just wasn't focusing on. But we did love the fast develop/compile/run cycle that Delphi provided, Delphi's OO was great at the time, and the apps worked. The difference between Delphi and C++ back then felt a lot like Rails versus, say, J2EE. It was incredibly easy to develop stuff.

Look what Turbo Pascal/Delphi gave a PC developer in 1995:

* An insanely fast compiler

* Statically linked binaries -- no DLL hell (still important for certain kinds of applications)

* A proper module system, no need for precompiled header nonsense

* A UI framework/designer as easy to use as WinForms, at a time when the alternatives were MFC or Win32

* An easy upgrade path to 32-bit Windows

As long as you were ignorant of the world outside of a PC and Windows, it was nirvana.

Well, even considering the world outside of a PC and Windows was probably OS/2, which I know nothing about, or the incredibly fragmented Unix world (Linux was still a wannabe) with Motif/CDE/xlib, C++ without working compilers, an infinite number of #ifdefs, (Linux) threads implemented as a userspace hack, a.out binaries, primitive TCL and Perl as the high-productivity alternatives...

Turbo Pascal/Delphi was probably nirvana.

It was nirvana indeed.

I never liked C, because I already knew a few Turbo Pascal versions before getting to learn C.

So the language was always meh for me, but then Borland blew it up with their schizophrenics moves and allowed C and C++ usage to grow in the PC world.

The lead architect of the VCL went-on to work for Microsoft on .Net and most of the venerable (and still working, if not actively maintained) Winforms API is really reminiscent of the VCL, albeit corrupted by the win32 API leaking through.

Maybe it is rose-tinted glasses, but I remember having a significantly more pleasant experience working wight the VCL (through C++ Builder) than with Winforms.

That lead architect was:

http://en.wikipedia.org/wiki/Anders_Hejlsberg

I read that he got $1 million (or more?) for leaving Borland for Microsoft.

He's also worked on:

http://en.wikipedia.org/wiki/TypeScript

, Microsoft's enhanced version of JavaScript, which has been in the news somewhat lately.

This is the one thing that I will not forgive MS for. They bought the lead guy from Borland rather than compete against the product. I guess it's all fair in business, but it was a gutless defense of VB - an admission, actually - that VB wasn't up to the competition.

The summary for me is that Delphi was more productive and way better designed than VB with the performance of C. I never understood why it didn't have a broader following. My guess is that developers enjoyed the challenge of C/C++, call it an aesthetic judgement.

Microsoft bought not only Anders but also about 30 other Borland developers over the course of several years. Borland sued, but eventually reached an out of court settlement.

I sometimes wonder what Delphi would look like today, had Anders not joined the MS fold.

Myself as well. I really really liked Borland products. I had an emotional attachment to them. I got Borland C/C++ (3?) as a Christmas present shrink-wrapped one year and I thought it was the best Christmas present ever. Lots of people learned C using K&R's book - I learned C/C++ from reading Borland's manuals.

Long story short, when MS turned the full weight of their organization on Borland and sunk them it opened my eyes to MS's corporate behaviour. That's how I learned that MS always played dirty. It set me out on the road to looking for alternatives to Windows. It's ultimately why I'm writing this in Firefox on Ubuntu.

In ref to the blog post (or whatever it is) I thought Delphi was no more. Just goes to show, here is a link: http://www.embarcadero.com/products/delphi

WOW. I had no idea.

From 1997: "Borland International and Microsoft have settled a Borland-launched lawsuit that started on May 7, 1997, in Santa Clara County, CA. In the suit Borland alleged that Microsoft had hired 34 Borland employees over the past 30 months in order to steal Borland trade secrets."

Just WOW. 34 employees.

Yes, his leaving was bad for Delphi, though good for him financially. A pity. That's why it is a good thing that Free Pascal and Lazarus are there now.

Micrsoft did far nastier things to Borland. E.g. During the Windows 95 preview stage they added code to the app launcher that would detect binaries compiled with Borland products and generate bogus errors.

There's plenty not to forgive Microsoft for. It's just so much cuddlier mow that it's a little desperate.

I totally undestand Hejlsberg for doing that. If i were his wife, and he rejected the offer, I would be *. But to make a managed language out of it. WTF?? He could have made a GUI for C++, just like VCL, and not as complex as MFC. But I guess It was not (entirely) his decision. It was a time when MS was battling SUN for Java add-ons. I think it was a wrong course, to make a managed language that runs just on one platform. Java's (excuse) is a multi-platform one. But .NET (MONO disregarded here for it lags behind), to be managed, GC language, exclusive to one platform ?? I can't comprehend that. MS missed a chance to attack the consumer market (like Apple does). No B2C apps written in .NET, only for the enterprise. That's why developers like Apple, and pay the Apple taxes (expensive Macs).

No, I think Hejlsberg knew perfectly well that he shouldn't attempt to do "GUI for C++". Borland tried it. The end result was, and is, terrible, and the sheer awkwardness of C++Builder was not really a matter of design or implementation, but due to the nature of C++ itself.

Delphi worked because they could control the language and mould it to fit the requirements of the VCL and of the IDE. With C++Builder, they had to introduce special proprietary extensions to C++ (which may have been, like Qt, implemented using macros internally, I don't know) such as "__published" and "__closure". Another factor was that Delphi's fast one-pass compiler allowed incredibly fast GUI-development; the "modify, compile, run" cycle could take literally seconds. C++Builder's use of C++ meant this cycle slowed down tremendously, even with tricks such as pre-compiled headers. C++ had other problems. It just wasn't a good idea.

Hejlsberg's C#/.NET design was necessary, although I agree with your other assertions. As far as I know, .NET was never able to replicate Delphi's genius, and a one-platform, proprietary language was a bad idea even back then.

He also worked on C#.

The VCL ... yes very well done. I wish Microsoft would make their C++ environment work like that. The beautiful & preformat applications we could made.

Auto completion of API function calls and well integrated help - Sublime Text level workflow. It was sweet. I could manage with their help pages and examples quite well.

Actually the UI alternative of the time was Visual Basic, after which it was modeled (and easily surpassed).

Borland Pascal 7 (running in MSDOS) had the best IDE I ever had. Debugging and editing was excellent.

Ever since, I've been using prints and command line. :-(

Why was there no linux port of BP7?

Linux was much less widely used and less on the radar then, compared to nowadays. That may be why there was no Linux port of BP7. Also, Borland did a Linux port of Delphi - called Kylix - later, but it never got popular and was later stopped. IIRC, it was free or had a free trial, and I had tried it a little. I read on the net that Linux people preferred C/gcc and its toolchain ( me too :), that may be why Kylix didn't get popular.

http://en.wikipedia.org/wiki/Kylix_(software)

The above link says that Embarcadero has Linux support (via cross-compiling for Linux, on Windows) on their roadmap. But who knows what will happen, there have been so many changes of direction ...

Delphi was designed by the same architect that later designed .NEt. Microsoft snatched him from Borland. Borland tools were always great, but this was the era of mighty MS. http://en.wikipedia.org/wiki/Anders_Hejlsberg

C++ Builder made C++ on Windows so much more accessible than MS Visual Studio 4 + MFC at the time. Truly a revolutionary platform.

It was the real "Visual C++" in terms of RAD productivity. Microsoft's compiler had nothing visual about it.

C++/CX + XAML is maybe the closest it gets nowadays.

The compiler was lightning fast, and produced fast code. The IDE was fast. It did a beautiful code/visual synchronization that still hasn't been done better. It had good libraries, and did effective programming the large.

Not cross-platform, didn't have automatic memory management, though, and was never going to be able to compete with the advance of free IDEs.

About a million years ago I wrote the Delphi Container and Algorithm Library (DeCAL). Good times :)

This is one reason why I see Go compilation speed as PR.

Anyone of us that had the luck to work with tooling in the Amiga/Atari/PC world back in the day C mostly still only relevant on UNIX, knows there were a few languages with very fast compilers available.

Go's compilation speed is more than PR. It's reality when compared against what it is designed to replace. Believe me, there are several people on the Go team who fondly remember the "old" days of Turbo Pascal, for instance. But those tools just aren't around any more for practical purposes.

> It's reality when compared against what it is designed to replace.

If you mean C and C++ then yes. Not so when compared with most languages with module systems.

This is why I call it PR, because most Go presentations tend to ignore the world outside C and C++.

Last time people were bandying about Go compilation speeds on HN, and actually posted numbers, it was trivially beat by gcc on compilation speed when I tested..

Maybe it's faster now? But it certainly wasn't particularly impressive a year or so ago.

It was crossplatform for a time, kylix ( http://en.wikipedia.org/wiki/Kylix_(software) ) was delphi for linux, it worked okay but compared to delphi the produced binaries was not dependency free.

Kylix didn't take off the way Borland management thought it would.

The company was already "Inprise" by then, right? That was when I started losing faith

Yes, I used the name Borland loosely. As a liker and user of Borland products (earlier), I did keep some track, of all the company restructuring, selling off of divisions, renaming, etc. E.g.: Borland -> Inprise -> CodeGear -> Embarcadero. But didn't correlate the exact dates of company changes with product releases. Not worth it.

I was in deep at that point. Interbase 6.5 was becoming FireBirdSQL. No one really knew WHAT was going to happen in the open source landscape. I was at a convention and it really did appear that Kylix had a valid foot forward. In retrospect, I would have totally gone in a different direction. The web wasn't "there" yet. We were still doing Perl and rudimentary PHP 3/MySQL 3 stuff. It was a gamble on their part, but I can't say I'd have gone the other way.

Interesting ...

Delphi was one of the greatest development environment ever created when you just "needed to get shit done".

Yes yes yes. Delphi was amazing and still is really. I remember seeing it for the first time at a Borland conference and trying to explain what I saw to my team at the time. Just an amazing product. And super fast.

No question.

I used Delphi 5 for a long time. The IDE was as easy as it gets, the sample code on the net was rampant, and it produced single little EXE files I could send to people and they had a full-on Windows application.

The closest thing I've found since then that allows me to do something similar minus the IDE is BlitzMax, but the IDE was what made the process so silky smooth in Delphi, and I miss it.

I think Delphi got right the "Visual Programming" paradigm. I am surprised that we don't have something similar on newer environments. Perhaps is that multi-user RDBMS with SQL and/or the Web broke the model. I don't know, but it is an interesting question.

The web broke it.

The frankenstein model of CSS/JavaScrip/HTML cannot provide the same RAD capabilites as native applications.

I don't think the advent of mult-user RDBMS/SQL broke it. There was a time frame (some years) when client-server apps were all the rage - Visual Basic / Delphi / PowerBuilder / Gupta SQL as the front-end tools, talking over a LAN or even sometimes a WAN to back-end databases like Oracle, Sybase, SQL Server, Informix, etc. I've worked on some projects of that type earlier. The technical discussions used to be about things like thin client vs. thick client, database transaction isolation levels, whether to use record locking vs. time-stamping, etc., use of stored procedures and triggers, etc. ... :-)

E.g.:

http://en.wikipedia.org/wiki/Gupta_Technologies

http://en.wikipedia.org/wiki/PowerBuilder

Also, Delphi didn't have a completely "Visual Programming" paradigm, if you mean it in the sense of some of those experimental tools that claim that all programming can be done visually/graphically, simply by drawing diagrams, dragging and dropping components onto a window, connecting them visually, etc. The visual part of programming with Delphi and similar tools like Visual Basic, was restricted mainly to designing/creating the UI, iteratively and visually, by dragging and dropping widgets like text boxes, labels, drop-down lists, gauges, graph controls, etc., onto a form (a window), setting those widgets' properties such as font, text foreground and background color, enabled/disabled, tab order, etc. etc. Also, data-aware widgets were useful; they would show the back-end database data represented by each widget, live, at UI design time (not just at run time). E.g. a grid widget could show the rows and fields of a table, live. But the rest of the code (widget event handling, business logic, etc.) still had to written in a text editor by the developer.

Not completely "visual programming" as you say, but I found it a fast and easy tool for making and tweaking the UI. The IDE's integration of UI widgets and event-handling procedures was pretty slick too.

>I found it a fast and easy tool for making and tweaking the UI. The IDE's integration of UI widgets and event-handling procedures was pretty slick too.

Yes, you're right. I found it so too. I forgot to mention in my parent comment that Delphi also generated the stubs/skeletons for the event-handling procedures. Not only was that a convenience, it helped with learning the tool and Windows GUI programming too.

I first touched Delphi as a teenager (I was 14 or 15 at the time), and it was Delphi 6. I had already tried different languages by that time.

I had already programmed in BASIC as a child and it was great, for a kid like me who didn't have Internet access and named text files to .COM and .EXE in the hope they would do something, this was awesome. But I still wanted .EXE files and I then tried Pascal, which gave that to me. I also tried few examples of C, but the code I had access to was in Pascal, and I didn't have the doc or internet, so I kept tweaking.

And then I discovered Visual Basic (in its DOS and Windows) and I was able to do buttons and forms and tigers..

Yet, with Visual Basic, there was always this bloated feeling.. I mean, you had to make an installer for your programs with files like VBRUNXXX.DLL and error messages yelling at you, and depending 16bits or 32bits, VB4 or VB6, so ... it's even fuzzy in my head.

And then I found Delphi 6. The first time I tried it, I thought "Hmm, this is Pascal !". I compiled my first thing, and I automatically looked of parasitic files VB style.. Nope. It was that .EXE..

So I took that .EXE file to another computer and ran it, and it ran. It didn't need any other files. I didn't have to make an installer for it with WISE or something. It just worked. I was happy.

When my brother who was in CS and was doing image processing (tumors, edge detection, etc), he did his project in Delphi and I'd hang around, and he'd ask me how to do this or that, since I started programming in it before he did, and it was so easy for him to implement stuff and build the application.

So maybe that's why it lasted so long. Easy enough for a kid to do stuff with it. It needed not a lot of knowledge to make buttons and forms, etc. I just make the layout, then program what each button does, etc.. And it was simple.

I may be a biggot, since I tried Embarcadero but it smelled nasty since it was, at least for me, an utter mess. I prefer Delphi 6. It may be nostalgia, but I don't htink it's only nostalgia.

Delphi is a great RAD tool, but it's also slowly dying and has lower and lower market share, 100% of my income come from Delphi contracting at the moment, and I love Delphi, but its not a great choice if you're just starting your programming career and have to choose the language to go with. I've been sticking to Delphi for whole my programming career (3 years professionaly, 10+ years hobby programming, i'm 24 now), but its more and more occuring to me that I have to learn some new tech ASAP if I want to progress further. Delphi has no proper crossplatform support and it's a big minus. Also it has ridiculous price.

Was once in a similar situation myself. One path is to identify a future customer pain point that will occur if they continue to use Delphi. You can direct the solution to a language/platform you wish to learn, and work like a dog to develop the new skills and build a great piece of software in this new language.

Thats exactly my plan, to learn some basics then further improve skills on minor contracting jobs I get and I feel comfortable to do them in new language. It would probably be C++.

If you're looking at C++ already then I'd recommend Qt. I think it's pretty close to the RAD feeling I remember from C++ Builder and by extension I assume Delphi.

Compared to them it's not strong on data components that allow you to connect a DB to a UI, you will have to write SQL and code for that. But it is a joy to use, cross-platform and at least on the desktop it is free to use if you don't mind LGPL and shipping DLLs/so with your app.

Don't learn Qt if you want to find clients.

Care to elaborate? Assuming C++ and UI development of course.

Enterprises are not using Qt.

They are in factory control tools and in-car automation systems, for example.

Although the latter are starting to use J2ME systems as well.

At least that is my feeling from job posts here in Germany.

The grandparent is a consultant, how many of this niche is hiring consultants? What are his chances of having steady (consulting) work using Qt? Let's be reasonable, he has a better chance learning MFC (not that that's a good idea either).

Given how Germany is following USA footsteps of outsourcing and offshoring everything in Fortune 1000, maybe there are some opportunities.

In Germany's case mind you, not sure about other countries.

Qt has gained some momentum in the EDA industry as well.

True, but since if one has a job working for an enterprise like that makes me want to kill myself in a hurry I consider that a feature, not a bug.

QT will get you into C/C++ programming, which will get you into backends, which will get you into much more pleasurable programming jobs. Yes, likely there'll be limited QT usage once you're there, but ...

Are enterprises using C++? If they are, what UI library are they using to write user interfaces?

Could you elaborate? What is wrong with Qt?

There aren't very many consulting jobs for it.

I will certainly take a look at Qt, and other alternatives, but isn't Visual Studio the ultimate tool of all tools? I'd rather start with it from the start, since I'm already familiar with most of the programming paradigms and stuff that isnt tied to language itself, so it's just a matter of learning cpp + IDE, and I figured out I can easily enough start out with VS? Maybe it will have a bit slower learning curve than if i start with Qt, but at the end it will pay off.

Well, in all the C++ universe Visual Studio is a nice tool, but no one will hire anyone for knowing how to use it. It's the libraries and programming language skills that matter.

Qt is like VCL and it can be used within VS or without it. The Microsoft equivalent to VCL is MFC, but I don't think that's a very current skill to have. It's also the opposite of RAD, having to write lots of boilerplate to get something on the screen. I mean that's why MS invented .NET, MFC was unproductive.

joj vidjao sam ti ovaj nick na krstarici jbt :)

eh, davno je to bilo :)

In terms of job availability it's been dead a long time. I see a single job posted on craigslist every 6 months in city with 50 daily job postings.

Part of the problem is the kind of corporate windows CRUD apps that Delphi excelled at are better implemented as web apps. Which leaves it relegated to hobby developers and 1 man software vendors.

Even weirder is that in 2002 the Delphi community developed a python 2.7/3 type schism over UI changes and .NET inclusion and a large portion of the community refused to adopt new releases. It's pretty telling when a vendor isn't even able to get many of it's own supporters (many of which are these "Delphi will never die" types) to buy new version of their software in over a decade.

The insanely high prices aren't helping either though. Yes yes, they are not 'high' if you are a fortune 1000, however, they are high compared to what everyone is used to now. They didn't step on the train of making for instance a version free if you are an open source dev. Or doing low monthly payments. Or do anything 'cool', like turn up and give a demo on how to implement reactive manifesto complaint software client/server with a few clicks / lines of code. That kind of thing would be relevant and interesting to devs now; if you can do a dashboard in Mac OS X, Windows, iOS, Android with all the backend & frontend stuff smoothly working together, smoothly tested and smoothly deployed, showing off those 6000 datapoints per second coming into the server and the client and still have a responsive interface companies would listen. But they don't; they just don't 'do' anything people want now besides turning up to the mobile parties way too late.

I kind of wonder how many devs still are working on Delphi and if they are not only just bugfixing...

I think Embarcadero is seriously hurting themselves with their bunker mentality.

Their whole "there are only X paying customers left, therefore we need to charge $3000" stinks of someone who is preparing for failure, instead of growth.

It really looks like low self-esteem play of some group that secretly believes the market doesn't want what they have, so they desperately milk their few remaining customers to make next months payroll.

I keep hoping some startup sees the huge arbitrage opportunity that is sitting there. Someone just needs to come along and build a quality GUI around the toolchain - very much like what Xamarin did for Mono - and similarly they need to charge a sane subscription model (free for OS/hobbyist, $99 personal dev, $399 corporate lite, etc).

> the Delphi community developed a python 2.7/3 type schism over UI changes and .NET inclusion and a large portion of the community refused to adopt new releases.

Not quite the way I remembered it. It was more like, "if we're going to develop in .NET then we're going to develop in C#." We liked Delphi for its native compile and unencumbered executable. No point in adding all the .NET baggage and not learning/using it's native language too.

I spent the first years of my non-school life developing things in Delphi, including CGI binaries in the end. I can't say how much I loved the language and the IDE. In fact, XCode is still somehow trying but falling far short of providing the same amenities for developers (maybe on purpose).

Since I rediscovered dynamic languages in the early 2000s and haven't (except for some experiments in C) looked back.

It's funny how you can selectively remember the good aspects of a language and forget how much better life has become since you dumped it. Out of nostalgia I checked out Lazarus and I'm glad it has a somewhat thriving community. However, for me it was clear immediately that the time of Delphi/Pascal has passed for good.

Can you describe what things Xcode lacks that you miss from Delphi? I'd be interested in learning more about such features.

Smart commenting/uncommenting (depends on indentation in Xcode) Expanding case statement for enums (not implemented) Renaming does not work for commented .h and .m file name No shortcuts are shown in hints (debugger step over/into...)

I used delphi extensively in the mid 90's, from the 1.0 release until about 2001. Those were probably some of the most enjoyable and productive times of my life.

IMHO, nothing comes close to the syntactic clarity of object Pascal. This has a ton of knock on effects for long term maintainability.

Plus, the early versions of the Delphi component model were insanely clear and well documented. My first delphi program was a reimplementation of a 6 month long (4 programmer) access database/vb application. I completely reimplemented a 2 man year project in about 24 hours with it using little more than the help docs. After a quick demo at work on Monday, everyone pretty much agreed to kick MS Access/vb to the curb and pick up my code base.

The data aware components were a life saver, and to this day programming in a wide range of languages I am constantly reminded how painful doing things that were simple 20 years ago is. It drives a fundamental distaste into my mouth every time I'm hacking an AJAX app to do basic sorting/filtering of a simple result set. Usually doable with delphi in a matter of a few mouse clicks.

Plus, by the late '90s there were a ton of 3rd party component libraries that nailed just about every GUI interaction an average program might need. The integration of reporting components made generating nice paper printouts a snap too.

So, this is probably why its still being used. Reimplementing a delphi application of a hundred thousand lines is probably a thousand man year project with a "modern" web stack. And so, much like the mainframes running in the data centers of banks/insurance/etc companies, delphi is probably still driving a fair number of business logic applications. I know that some of the applications I wrote in the 90's are still in use at government agencies.

BTW: I used BC builder too, and hated it even though I tend to like C++. The C++ syntax was simply to unwieldy vs pascal.

I have periodically tried out more recent version of delphi or lazurus http://www.lazarus.freepascal.org/ and they don't seem to be nearly as elegant as the early versions. Seems all the effort to make it cross platform (kylix) or match up with the .net component models cluttered up the early clarity of implementation.

I look at tools for DOM manipulation right now - and I look at what people dream of doing with the DOM, especially with apps.

Then I think back to what Delphi was doing in early 90s - then I wonder if just some of that magic was available for building apps on the DOM we'd be in a better place.

This is why kids these days jump into web development, they aren't aware how good tooling we already had back then.

To add my two cents, here's a piece I wrote on why I use Delphi/Object Pascal a few years back

http://screamingduck.com/Article.php?ArticleID=43&Show=ABCE

Now that time has moved on, I no longer use Delphi at all, and rarely use FreePascal. My currently active projects are C, Node.js, and Browser Javascript. For game projects I prefer Haxe. For future large scale projects. I'm eyeing Rust. When the time comes I'll probably be weighing up the relative maturity of Haxe and Rust. They are developing from different directions, Rust being more idealistic and Haxe being more pragmatic, but I think they'll grow aspects of the other over time.

I remember the same feeling with VB6/VC6. Sure, with VC6, you could do More Stuff, and theoretically, it would be Better Stuff. But in an afternoon with VB6, I could bang out a good first prototype for SO many projects that in many cases, ended up being "good enough" that we never needed to go back and re-do it "properly" in VC6.

PowerBuilder, though... Man, that can't die fast enough.

That's how I sold Delphi; I applied for VC projects and then talked them into a 'fast prototype' in Delphi. They never rewrote and I had happy clients for many years. It worked especially well in companies who where forced into VC by higher management and already did a few (long, painful usually) projects in it; they could now show off something much faster and with more features.

Delphi had one of the best and most useful help documentations I've ever used. In my eyes it was a huge winner for Delphi over Visual Studio products, although I never really liked the pascal syntax...

Delphi/Pascal and Wolfram mathematica are the two things I point people to when we talk about documentation.

Every single function had a working snippet example. Mathematica had details and applications for each function, while Delphi/BP had a well written explanation of what the function would do and how to use it.

They are the standards that have not been surpassed yet. Or even approached imho.

These days you get an auto generated docstring explaining that xval is "the x value passed to the function".

One of the great things about Delphi and its predecessor Object Pascal were, besides what other HNers have mentioned, was AOT compilation, being memory safe and allowing systems programming at the same time.

No need for VMs.

Luckly Go, Rust, D and now .NET Native might make younger generations aware of it.

Object Pascal is not the predecessor to Delphi

Delphi is the IDE and compiler, Object Pascal is the language (Free Pascal Compiler and GNU Pascal are two other compilers, both exhibit the same quick and safe compilation).

> Object Pascal is not the predecessor to Delphi

Object Pascal was designed at Apple as their extensions to Pascal while using it as system programming language to develop the first versions of Mac OS.

Afterwards, Borland extended Turbo Pascal with Apple's agreement and then Turbo Pascal 5.5 was born.

After the initial versions of Delphi, the Borland marketing team decided it was a bit confusing to have Delphi and Object Pascal as names, and decided to start referring to the language as Delphi as well.

I was a Turbo Pascal user since version 3.0 all the way up to the first versions of Delphi.

Yes I'm quite aware of the history but the fact that borland/embarcadero choses to call both delphi doesn't really change what I said though, every where besides the marketing of this IDE clearly considers object pascal [1] as the language (with several implementations/compilers), and delphi [2] as the IDE.

Delphi's own documentation, once you're past the marketing naming on the box, makes it clear that the language is object pascal.

[1] http://en.wikipedia.org/wiki/Object_Pascal [2] http://en.wikipedia.org/wiki/Embarcadero_Delphi

So it seems I need to post some links to official documentation.

<quote>The Delphi Language Guide describes the Delphi language as it is used in RAD Studio development tools. </quote>

http://docwiki.embarcadero.com/RADStudio/XE6/en/Delphi_Langu...

<quote>Delphi is a high-level, compiled, strongly typed language that supports structured and object-oriented design. Based on Object Pascal, </quote>

http://docwiki.embarcadero.com/RADStudio/XE6/en/Language_Ove...

The current language is based on Object Pascal, which is quite different from being Object Pascal, which was quite different back in the Turbo Pascal and early Delphi days.

I don't know Delphi and Turbo Pascal history from Wikipedia, I lived through it, from Turbo Pascal 3.0 up to Delphi version 3.

I always gravitated to it because it was a fantastic painless (mostly) wrapper for the beastly win32 API. As a unix programmer, it was great when I "just needed a quick windows GUI" for something.

Delphi has been my secret weapon for more than a decade now.

I loved it for that too. It's amazing how much easier most things are in Delphi. Yet everything remains possible. I wrote a windows application firewall in Delphi, and that worked. Man that was a great experience.

I always wondered why a devshop I've worked at used Delphi. Now I know. The main code base is handled by one developer.

Does anyone... Turbo Vision!!! Oh, the memories! and "Uses BGI"

I have been Delphi developer for more that 15 yrs. I had 2 shareware apps, one of which is still selling (very well). But now I work in Objective C. Xcode is much better IDE (Delphi is 32 bit, and crashes often with big projects). I will probably continue to do Delphi, on the side, but iOS and OSX are my main domains of interest. Delphi devs are old, no new fresh blood, no jobs available, no new books are being published. Online material is mainly marketing, no useful blog posts, new frameworks, package managers.. Delphi is great for people that have been using it for ages, but with the current pricing, and no 'community' edition, it will not attract new developers.

I agree with most of your sentiments, but no new books and no new frameworks isn't completely true. For example, I just started reading Coding in Delphi (https://leanpub.com/codingindelphi) which describes a few current efforts. Still I'm hesitant to make use of those, because they would further lock me in with Embarcadero; sticking to what's in Delphi 2010 itself at least allows for a relatively smooth transition to Lazarus at some point. I haven't given up on the principles of Delphi yet, but I have on Embarcadero.

I completely identify with this poster. I inherited an app written in CA Clipper (a language from 1987) It became FoxPro. I had to learn those ancient technologies. Surprisingly, I really enjoyed it. I loved those old terminal/DOS apps. Around 1999, we made the decision to migrate the entire app to Object Pascal/Delphi/Kylix/InterBase/FireBirdSql. It was an incredible effort. I loathed, yet loved it. What I learned during that year STILL comes back from time to time in my current development projects. Kinda makes me feel old! When I started doing C#, I felt quite at home. Apparently, the guy who did Delphi, got hired at Microsoft.

And why should it? It may not be trendy but it's a really quality environment for its use case.

I only wrote it as a hobby as a teenager but compared to trying to write Visual Basic or C or Java on Windows it was a real dream. As a hobbyist the absolute most important thing was seeing my effort actually materialise in front of me and to that end it was amazing. And Pascal is a dream compared to C for slightly-higher-than-C level stuff.

I loved it and I hope it sticks around. I just took another look and it compiles applications for Windows, OS X, Android, and iOS. Maybe I should give it another go some time.

Delphi 3 introduced me to programming in my teen years. Somehow that's why I never dived in C I guess. I remember how you only had to dealt with pointers when you used Windows API.

It took years to Microsoft to get the web right (as everyone who used Visual Studio and .NET before MVC could tell you), it's no wonder it was difficult for a company like Borland to transition.

As a PHP developer I wonder why I never tried that "Delphi for PHP".

Coincidentally I interned at Borland France during my marketing years ten years ago and developers were really passionate about Delphi.

"With very few exceptions, technologies don’t die. In this way they differ from biological species, which in the long-term inevitably do go extinct. Technologies are idea-based, and culture is their memory. They can be resurrected if forgotten, and can be recorded (by increasingly better means) so that they won’t be overlooked. Technologies are forever." - Kevin Kelly [1]

[1] http://kk.org/thetechnium/2006/02/immortal-techno/

I did a contract that involved some Delphi not long ago. I was really surprised to see it still in use. The worst thing, though, was registering to get a trial from Embarcadero who then had an elaborate follow-up process including phone calls from them. And after all that, the code in question wouldn't compile with the new editions of Delphi and I had to track down a copy of Delphi 6.

I was really surprised to discover they still have a C++ compiler product. Does anyone use it?

I used C++Builder at a previous job. All their software was C++/VCL, they were completely locked in. Embarcadero tried to keep up with the evolving C++ standard and on paper they were moderately successful, but if you actually tried to program in a modern style, it all fell down. E.g. you'd find an object's destructor was ignored, or even worse, run twice. I think I reported about two dozen compiler or C/C++ library bugs.

I use CB2007. Yes, it's not the fastest code and no C++11 but it does the job at the moment. The thing is that the supplied VCL is what is so amazing. Hard to give it up.

I loved Delphi back in 1997. Then I moved on to Java, and never looked back. It was wonderful though, and GUIs were so easy. It wasn't my first language, but it was the first language I become truly comfortable and productive in.

My move to Java was partly because I was straddling the Windows and Linux worlds, and Delphi couldn't cross that chasm with me at the time.

Why? Because it cannot just die yet! One of my most frequently used Windows app is in Delphi. Total Commander. ;)

I feel like Delphi has made a recent exciting comeback to relevance. AppMethod allows development of native compiled apps for OSX, Windows, Android and iOS, all from the same Delphi code base. That's a compelling proposition.

Isn't Delphi currently hosted only on Windows? I would love to use a tool like Delphi on OSX to make apps for OSX.

I have recently joined a small successful ISV selling and developing a couple of Delphi apps in an industry vertical in which I have significant experience; my prior experience has been C#/.Net for quite a while, and before that Java. I recall buying the Delphi IDE way back in the day; possibly when I was still at university, definitely when Borland was still around!

So some informed observations:

1. The quality of the IDE is incredibly dire compared to Visual Studio+Resharper or Jetbrains IntelliJ. Perhaps it will be improved if a buy a license for Castalia. That said, I've been using XE3, maybe the more recent versions are better but it seems that Embarcadero have been focusing on getting into the cross-platform mobile game (one which I think Xamarin/Phonegap/Titanium, etc are playing better) rather than increasing the quality of the tools or enhancing the language. XE6 may have some improvements under Embarcadero's "QPS" (Quality/Performance/Stability) project. We haven't upgraded our licenses since the versions since XE3 didn't bring anything for us, but if we want to see Delphi survive then perhaps we should be chucking some money Embarcadero's way!

2. The language is quite verbose, and I find the need to declare the 'interface' for a class separate to the implementation of the methods quite cute. There's so much ceremony around anonymous methods that it hardly seems worth it some times. Lack of built-in multicast delegates for event handlers.

3. I recently attended a local symposium put on by the user group. There didn't appear to be much diversity amongst the attendees. I would charge that lack of diversity is not a sign of a healthy software development community. Speaking with one of the organiser's, they mentioned that Embarcadero doesn't introduce new Delphi customers to the user group any more since it is just "grumpy old men".

4. At this symposium one of the talks was on dependency injection. I was bemused that this was a new idea to the Delphi world. One of the advertisers in the symposium papers was a consultancy whose pitch basically was "so you've been making money from selling a product, but you're getting old and want to retire. Pass the source code and rights over to use and we'll work out an arrangement to continue development whilst maintaining a royalty stream for you".

5. Packaging of open-source for easy reuse is challenging in Delphi. Unlike managed environments such as .Net or Java, reusing well-known open source components is as simple as adding an assembly or a JAR to your project (yes, I acknowledge that in the past this has had its own challenges, but I think in the .Net world at least Nuget has largely conquered this). The native binaries nature of Delphi has meant there is no such equivalent (that I'm aware of), although I'm considering leveraging Nuget's packaging format and tools for BPLs.

Re #1, Castalia is very slow fews years ago I tried, it's the ModelMaker Code Explorer that adds a lot of productivity to the IDE, including refactoring, and so on. Plus GExperts and GNPack.

Thanks for those recommendations, I'll check them out.

GNPack should be CnPack

Everybody else seems to love it, even compared to Java.

I can't help but think of using three days to collect and compile all dependencies for a legacy project.

At that point at least I'd take Java and maven any day.

dealing with Delphi as a product more than programming language hurts the Delphi community. I mean Embarcadero should give away some (freebies) to the community. like a free/express Delphi version. I think this will refresh its community and the Delphi empire would rise again.

They did, but they were not consequent with them so the developers lost trust.

Does anyone know more about PeopleCode and their PeopleSoft tools and IDE and how it compares?

PeopleSoft was hostilely acquired by Oracle in 2005, after which, despite Oracle trying to kill it for years (and merge the Peoplesoft product into Fusion), it still exists.

PeopleCode/Tools is more equivalent to ABAP offered by SAP, it's heavily tied to the Peoplesoft environment, and has no real comparison to Delphi.

Amazing that you can still find it around these days, but most PeopleSoft customers have moved to Oracle, SAP or Workday by now.

Having supported Delphi applications I had to say:

1) It just works;

2) It works in old machines fairly good enough

3) There is a lot of new components/integrations (SQL,DB2,Oracle,WEB,etc)

4) Good reports system

It isn't sexy but do the job very well for most corporate applications.

I remember when it was sexy - in the days of Windows 95-98 - that was the best RAD tool out there.

Reminds me of ColdFusion. It should be dead, but it's not.

The COBOL of the future?

Scott Adams could make the same joke again http://dilbert.com/strips/comic/1997-11-04/?CmtOrder=DateEnt...

I dont think so. Java is the new Cobol. http://c2.com/cgi/wiki?JavaIsTheNewCobol

I'd say Java 1.2 is the new COBOL. Just like COBOL devs were in serious demand during the "millennium crisis", Java 1.2 devs will be in demand the next time we have some sort of fundamental upheaval. This is due to so many banks/utilities/etc betting the farm on older Java. Judging just by current job postings, Rails 3ish might be entrenched for a short while too.

Reply on news.ycombinator.com