I was recently commenting on Facebook and asked what could the community do to help Delphi get more popular again. My answer? Uh Nothing.
A real change would start with the product actually getting a serious refresh, something probably that nobody can afford to do, and which EmbarcIdera is extremely unlikely to fund.
Cue up a nostalgic 80s song, maybe Glory Days, by Bruce Springsteen. Grab a beverage. I'm about to rant.
Now the UI changes were well intentioned, and well done, and were intended to bring Delphi out of the Win3.1 era UI of Delphi 5 through 7, and into a docking style IDE, comparable with Visual Studio 2005. I like the new UI in 2005+ delphi editions better than the old UI, but the point is that the old IDE was more stable.
There has not YET been another full refresh of the IDE. Delphi has continued to be usable, and a good productive tool, and while it's IDE architecture continues to look worse by comparison with its one time equals, it is now so far behind it's not even funny. Remember there are people using FoxPro and Visual Basic 6 IDEs and loading them up in Windows 10. We're more like them, than different, at the moment. The registry key where delphi gets installed gets a regular major version bump, we're at what 18.0 now? But the IDE architecture is frozen in time.
The delphi DCC32 and DCC64 compilers are relatively good compilers, excepting that there is no significant OPTIMIZATION available for DCC64 still. If you are familiar with the level of optimization work done in modern C++, and you compare it with Delphi in 2018, you're gonna be sad. I think that the Nextgen picture may be significantly more rosy with LLVM's optimizers at work, but that's never going to be an option when Nextgen was designed from the ground up to contain many breaking changes to your code, including string handling, and other fundamentals. That's not gonna be pretty.
1.2. Make the compiler and code completion engine a subprocess (RADStudioLanguageServicesEngine.exe). Kibitzing compilers, code completion and error insight compilers would share a single tokenizer/lexer and grammar.
1.3. Make the IDE main window (shell) a lightweight shell written in Delphi (RadStudio.exe).
4. Make the form designer also a subprocess (RADStudioFormDesign.exe). This subprocess would be capable of loading a set of BPLs needed to open the form.
2. First do no harm. Don't Tread On my DFMs. I would fix the ancient frustration caused by failure to locate and install all BPLs that a form requires before you open a form. It would be possible to open a form without the damn thing DELETING YOUR COMPONENTS. Similarly, all the places where it asks you sixty million times in a row are you sure you want to delete your components would default to no, don't bug the user, and don't do destructive stuff, instead fall back gracefully and do nothing. Those fun times when you have to open task manager and kill delphi to get it to stop asking you 9 million questions. Good times.
A real change would start with the product actually getting a serious refresh, something probably that nobody can afford to do, and which EmbarcIdera is extremely unlikely to fund.
Cue up a nostalgic 80s song, maybe Glory Days, by Bruce Springsteen. Grab a beverage. I'm about to rant.
The Glory Days of Delphi were from the Delphi 5 era until Delphi 2005, where the product foundered severely. 2005 was so bad, and 2006 was only slightly better, that few people could use it. To this day I encounter companies still using Delphi 5 or 6 or 7 because of this ancient developer and QA failure made in the tail end of the Borland era. Let's face it. Shipping Delphi 2005 was the worst thing that the management ever did to the product's reputation. Even worse than the well known shenanigans at their Sales level where they were pushing their (now dead) Java IDEs on their existing Delphi accounts.
The blowback from the instability of 2005 was actually less than the blowback for the UI changes. Developers (it me!) are a surly bunch. You moved my buttons. Damn you!
Now the UI changes were well intentioned, and well done, and were intended to bring Delphi out of the Win3.1 era UI of Delphi 5 through 7, and into a docking style IDE, comparable with Visual Studio 2005. I like the new UI in 2005+ delphi editions better than the old UI, but the point is that the old IDE was more stable.
There has not YET been another full refresh of the IDE. Delphi has continued to be usable, and a good productive tool, and while it's IDE architecture continues to look worse by comparison with its one time equals, it is now so far behind it's not even funny. Remember there are people using FoxPro and Visual Basic 6 IDEs and loading them up in Windows 10. We're more like them, than different, at the moment. The registry key where delphi gets installed gets a regular major version bump, we're at what 18.0 now? But the IDE architecture is frozen in time.
The bds.exe code of 2018 is mostly the same in operation, and contains most of the same assemblies and parts (binary dlls) as the bds code of 2005, with the addition of creaky refactoring code built in J# (yes JSharp, that no longer supported .net 2.0 language), error insight that doesn't work (due to having its own parser which doesn't parse all the language features, or even the compiler search path behaviour of the real compiler). The editor core in C++ is buggy to this day and crashes, and loses people's work.
A lot of talented people worked really hard and fixed a lot of bugs, and Delphi XE8 and up, including the current Delphi 10.x series are very stable IDEs. Don't get me wrong. I appreciate that work.
But what we have here is a polished antique. The editor core is basically the code from Borland C++ for Windows' editor, from about 2001. The code is a legacy codebase, and it needs a total IDE overhaul.
The delphi DCC32 and DCC64 compilers are relatively good compilers, excepting that there is no significant OPTIMIZATION available for DCC64 still. If you are familiar with the level of optimization work done in modern C++, and you compare it with Delphi in 2018, you're gonna be sad. I think that the Nextgen picture may be significantly more rosy with LLVM's optimizers at work, but that's never going to be an option when Nextgen was designed from the ground up to contain many breaking changes to your code, including string handling, and other fundamentals. That's not gonna be pretty.
But the Compilers, classic and nextgen, produce really fast code, even though they are not at parity with say, the Visual C++ 2017 optimizing compilers. I'm actually fine with that. I actually still kind of hate C++. Pascal is a beautiful language.
The bigger problem is the IDE is not very good.
Spend 16 full hours getting work done (pair programming) with a colleague who knows what they are doing in Visual Studio (perhaps with resharper or not), or IntelliJ IDEA and you will realize that what we mean when we say "IDE" in delphi is at a point similar to what Most IDEs Were Capable of Circa 2005.
Alright Smart-Ass What would You Do Differently?
Fair question. If you gave me a 6 million dollar development budget and two years I would rearchitect the IDE, but not the compiler, or the language specification:
1. Subprocesses are key. Yes, yes it will use more memory. It will crash less. Are you sold yet?
1.1. Make the editor core a subprocess (RADStudioEditor.exe). Less crashing. Large file search/replace should even be able to happen in background in parallel.
1.2. Make the compiler and code completion engine a subprocess (RADStudioLanguageServicesEngine.exe). Kibitzing compilers, code completion and error insight compilers would share a single tokenizer/lexer and grammar.
1.3. Make the IDE main window (shell) a lightweight shell written in Delphi (RadStudio.exe).
4. Make the form designer also a subprocess (RADStudioFormDesign.exe). This subprocess would be capable of loading a set of BPLs needed to open the form.
2. First do no harm. Don't Tread On my DFMs. I would fix the ancient frustration caused by failure to locate and install all BPLs that a form requires before you open a form. It would be possible to open a form without the damn thing DELETING YOUR COMPONENTS. Similarly, all the places where it asks you sixty million times in a row are you sure you want to delete your components would default to no, don't bug the user, and don't do destructive stuff, instead fall back gracefully and do nothing. Those fun times when you have to open task manager and kill delphi to get it to stop asking you 9 million questions. Good times.
3. Stability is key. When a BPL fails to load or segfaults, instead of the IDE going down, you would lose one DFM editor tab.
4. Modern editor features. Delphi's next IDE needs navigation and quick look features on par with IntellIJ IDEA and Visual Studio 2017.
5. Unified compiler and code-completion (kibitzing) engines, with a single root grammar and Lexer. The compiler and the code insight engine need to work similarly to the modern architectures used in Visual Studio and Visual Studio Code.
And a few things I would NOT do:
1. We Don't Need No Stinking New Language Keywords because We Are Not Jealous of C++. The language in Delphi is actually it's most important asset. Adding crap to the language is not gonna make it better. Delphi is kind of beautiful and clean, like Google Go. I actually think the syntax of anonymous methods is the ugliest part of the current language spec. I'd like to stop now before we end up with crap like they have to deal with in the latest C++ language spec. Delphi's module system, and runtime plus compile time typing system are better, in my opinion, than C++'s mostly compile-time-only type systems, and current lack (in 2017) of modules. I don't want to copy C# either.
2. Break stuff. I would not break anyone's code, DFMs, .pas files, etc. Absolute compatibility is the only way to guarantee you can upgrade. The decisions already made to break stuff in nextgen, while I understand the difficulty that lead to the reluctant change, I still thing are going to be the undoing of the entire thing.
Would 6 Million American Dollars be enough budget to do all the above? Would it take 2 years? That I don't know. I just know it would take a lot of work. And given that the business case for the above might be that the payoff would be around $4 million dollars, it remains probable and possible that doing all the above is a business mistake.
What I do know is that the above is the list of things being NOT fixed, are among the things that would make most young developers who know any other language, and even most old farts like me, want to Stay The Hell Away from the product.
When Delphi works, great, it's a joy to use. A proactive solution to the long term trouble with Delphi stability requires a modern multi process architecture, and a significant R&D commitment. It would also be nice if you still had some key developers who knew where all the bones are buried. If you didn't have all that, I'm just saying, that maybe six million dollars is still not enough to do the work above.
The market realities today are stark. You can get a trial of IntellIJ IDEA for free and run it for months, and you only pay a few hundred dollars for it if you buy it. Visual Studio Community is freely downloadable and is the default choice for Windows-Centric developers today, which is funny because WinForms and WPF still suck.
Delphi is a niche product today, an important and interesting one, but it's probably never going to be even 10% as popular as the big boys, ever again. I still think it's a great thing to build Win32 apps in, and I do wish it wouldn't eat my DFMs and my code on me.
Rant over. [Mic drop]
Postscript: A very senior Delphi Developer where I work pointed out that another core Delphi IDE design mistake is that the Library Path, and Component Installation Registry keys, and other similar items, exist at all, at a global level, which is not committable to source control, but which does affect your ability to open, share, and build codebases in Delphi on multiple developer machines, and that these settings should be per-project and be as files on disk, not in the registry. I agree with him heartily, and feel he was right when he said that is perhaps the single worst problem with the current IDE design. If I were to replace the existing crap, I would introduce a concept like Workspaces in most java IDEs, such as IntelliJ IDEA, to the Delphi world. A copy of the files and their workspace should be all you need to transport and build Delphi code anywhere. And it should be possible to load different versions of different components into different projects without the egregious workaround of bds.exe -Rsomething
