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.
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.
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.
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.
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.
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
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.
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.
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.
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 ...)
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.
