Never mind that it is realistically impossible to build a quality product of such magnitude in 6-month release cycles which inevitably results in poor quality products, Embarcadero’s current 6-month release cycle schedule is bad for its customers and is creating lots of bad blood. Here’s what I think:
1. Not only do you need a new IDE, but you need new components every 6 months.
The first thing I inevitably end up doing with each new Delphi release is to install component packages. Newer versions of Delphi are unable to load component packages built with previous versions of Delphi. It would be so much simpler if Delphi could be backwards compatible with older component packages, but every new version requires at least minor changes to the things to get up and running. If the package involves a LOT of code, even a little change can be a real problem. Luckily for me, I rely very little on 3rd party components , so I don’t hit any brick-walls with 3rd party vendors with each new release, but I am a rare specimen who works very hard to be self-sufficient in all my libraries and tools (I use hardly anything written by anyone else).
Component vendors have to release and maintain packages for every release of Delphi ever made… and there’s still lots of people stuck on Delphi 7. If you’re a component vendor, this becomes a support nightmare. If you make a bug fix in a component package, you have to open up every single IDE released in the last 15 years or so if you want to cover the target market and build and test the component package for all of them. You might argue, “hardly anyone plays in the Delphi component market anymore anyway!”… and to that I reply… “well… maybe that’s WHY!”
As a result of this chaos, the component market is not viable because there are just too many Delphi versions in active use. I suppose you could say that this problem is two problems. First there’s the fact that companies just aren’t doing NEW development in Delphi and are instead just maintaining old Delphi apps written in Delphi 7. Few companies are willing to budget time for upgrading their legacy code from Delphi 7 to XE7. The saddest part of this is that I could easily do this for just about any company if it weren’t for 3rd-party component issues. Dealing with 3rd party components that are not maintained specifically for newer versions of Delphi can be a serious problem.
2. Confusion among online experts in forums, tutorials, and sample code.
Embarcadero needs NEW customers, and acquiring new customers is rather difficult when 70% of all the experts on the planet are still running Delphi 7. When it comes to seeking blogs and samples on the internet that show Delphi newbs how to do things, it doesn’t help that there are so many versions floating around. Every new version of Delphi released creates fragmentation surrounding the free advice available on the internet. There are subtle language differences and differences in the class libraries.
The thing you hear users complaining about most often is the “price” of upgrading to the latest version of Delphi/C-Builder. When users complain about the cost of upgrades, though, they’re really complaining about two things: The Price and the value that they get for their money.
If I’m a typical Delphi user, maintaining code likely written in Delphi 7, many years ago… with a source-base that has evolved over more than a decade… Firemonkey is not a practical solution and therefore adds little value to my organization.
Since Firemonkey is not a practical solution, you can throw out OSX, Mobile, Linux, as options for typical USA businesses.
So what value does that leave for your typical USA company that you’re trying to convince to upgrade?
Unicode Support? Well.. oops! Delphi was 10 years too late in implementing unicode, therefore the companies that really required it for internationalization purposes moved to new languages long ago.
Generics? Well.. oops! They never finished implementing generics… they at-their-best save you a cast with () infavor of a type argument enclosed in <>. They completely fall apart when mixed with records, which IMO is where they would be most useful (for things like dealing with bitmaps that might have any variation of pixel formats, sound files that might have varied bit depths and channel counts).
64-bit? Well.. oops! They completely forgot to implement even the most basic, rudimentary optimizations in their 64-bit compiler and as a result it is half the speed of their 32-bit compiler. I am extremely turned off by this, and either I will write my own compiler, or translate everything to another language.
Customers who might actually have a reason to upgrade to the latest Delphi have been screwed as their database connectivity has been poorly maintained and outright broken and the promised bug fixes have been ignored for years, and new features have been implemented half-assed and too late.
Customers already think that Delphi’s quality has been neglected and have seen their projects suffer because of it. They have their own QA departments to deal with and will not spend thousands or even hundreds of thousands of dollars to put a new product through QA every time a new version of Delphi is released. There is no “support” of Delphi. What there is: vendor lock. Customers are forced to pay for upgrades that maybe fix a few bugs (although they glorify every release stating that they’ve fixed hundreds or even thousands of bugs). None of those bug fixed seem to affect what it is that I’m doing. I want some basic-level of quality that meets industry standards, and Delphi is still far from it.