The fix lists since XE3 are longer than ever. EMBT has started the mammoth task it is to overhaul the IDE, at the same time as they have introduced new platforms, new cross platform UI frameworks, new database drivers and numerous other changes. EMBT has done more for Delphi in a few years than Inprise/CodeGear did for a decade.
As for the IDE - it has been showing it's age for some time - I agree. I have to restart it many, many times a day - but it still is the IDE of choice for coding for me. With all it's warts, Delphi still is a very productive tool for Windows UI apps and Windows services.
Unlike MS and Apple which can funnel funding from other sources of income, EMBT has to get paid for their IDE. A subscription model with a lower entry point seems like the obvious choice. That said, MSVS is far from free. We pay far more money for licenses per individual per year to MS than we do to EMBT.
Those that feel moving on to C#/.NET or other platforms is the solution - should make the move. I wish them luck. It still puzzles me though, why some of those that have made the move still linger in the Delphi communities.
Last 30 day summary 209 created 211 resolved - with release of XE8, we will not see any other resolved issues for next 6 months, and already number of newly created reports is the same as number of resolved issues.
And older issues reported in QC are not included. Since XE8 was released recently above numbers do not look good. Whatever efforts EMB is putting into resolving bugs, that is still just not enough.
Lars Fosdal I would like to think they would be able to do more in bug fixing department.
But I am not sure they have enough people involved in fixing and testing. Also people writing their code have to take more care about what kind of code they produce.
If developers are satisfied with writing crappy code or under pressure to write a lot of code fast and have to leave finding their bugs to others then time difference between when code is written and when bug is detected increases and the harder and more expensive is to fix that bug.
I don't know about bugs and fixes, but there is one thing I want to mention: from the first versions of Delphi the VCL source code was an example of perfect code on Pascal and was recommended as standard. I think it lasted till Delphi 4 or 5, maybe 2006. It's hard for me to consider VCL/RTL source code of Delphi XE2 or XE5 as the good example. (I haven't seen the last versions, so maybe I'm wrong and code has been improved) :)
IMO EMB needs to start focusing on the IDE and the code editor, it's full of bugs and they can only delay for so long before it hits them right in the kisser!
the instability of the IDE and the poor performance of the code editor is a major hit in terms of productivity, basically, I'd go as far as saying that it almost cancels out the productivity advantage that Delphi has over other languages such as C++ or even C...
agree or disagree, the reality is, XE9 will either have a good and stable IDE or it will be a complete failure, too many "shiny features" that have to work around internal bugs that eventually will make themselves very evident.
The main issue is that you are not paying for bug fixes, but for a new version in which bugs may be fixed, and new bugs will have been introduced.
Delphi is really missing what all Entreprise-class software has: bug fixes for current and previous versions, ie. bug fixes you can use. Delphi is missing a "stable" release channel, which lags the alpha/beta/canary versions, and is still maintained.
We are still using XE because the few issues fixed in newer versions do not offset the loads of issues introduced in new versions. And all the new libraries and features introduced in half-finished half-tested half-optimized form in newer Delphi versions have stable, well-tested and well optimized versions for XE.
For new or mobile software, I would not choose Delphi these days, even if it was bug-free. It has fallen way behind the curve on too many aspects.
Eric Grange It was my understanding that Nick references the new Update Subscription, which is said to include bug fixes for current and older versions, and in that context it is "paying for bug fixes".
Dorin Duminica As far as code editor bugs and speed go, while I agree it's buggy - code insight especially - you don't know speed issues until you've used Visual Studio. Using it makes me view Delphi's editor in an entirely better light :)
I was trying to comment on Nick's post without success, then I found this post and I have to say it I couldn't expressed my concerns better, I have projects to maintain so I will be around for sometime, but I'm already investigating what tool chain will choose to replace Delphi :-(
I can't support Nick's notion. First, it is offensive to have to subscribe merely to get fixes for the defects in a product just shipped, as is apparently the policy now with XE8. Second, if the rationale for a subscription model rests in any significant way on the premise that defects are fixed, then EMBT has to make a very significant change to their practice in that area.
It cannot be considered acceptable for the defects in the IDE to fester through multiple releases -- after all, the IDE is used by everyone, even those mobile folks who seem to consume so much of EMBT's current interest.
It cannot be acceptable for defects to be downgraded merely because they have been in existence for so long, therefor, in theory, less important. Less important, I suppose, if you simply ignore user feedback, which has been plentiful over the years.
Finally, the single biggest danger in a subscription is the key question we should all be asking: "What have you done for me lately?" A subscription model is a fast treadmill. Past performance does not instill high confidence in me for the new model.
If you have a good product, with high quality, you continuously improve it, you support it well, and you communicate well with your customers, people will gladly pay you an annual subscription.
If you sell crap, then people will turn up their noses.
Eric Grange - The comment about lacking a stable release is accurate. This is why we don't move to the latest release until the first service pack is out.
Lars Fosdal And the problem with latest Delphi releases (when they started 6 months release cycle) is that you don't have stable release. There is no time to identify and fix most critical issues before the next release hits the road.
If Embarcadero would release another service pack for old release when new release is out that would improve things, but so far that didn't happen.
We'll see how this new "fixing issues for past two years" thingie will work out.
Dalija Prasnikar The subscription model is a treadmill. I think that the goal of fixing things in the "past two years" is a further burden that they will not be able to sustain. Still, I dare to hope, as we will be on XE7 for some time.
Yes, given the rate at which new versions come out, properly reporting fixes across 3-4 versions does not look very realistic, meaning only few things will be fixed.
Horácio Filho no specific issues, but death by a thousand issues. Most issues can be worked around, but the problem is in bumping on them, narrowing them, and fixing/finding solutions. The issues range from compiler issues, to RTL/VCL bugs, to IDE bugs, to problematic changes that make having code compile under multiple Delphi versions complex. When things take time to fix because of many issues, it means you have to keep the codebase working against several Delphi versions, etc. Also if the latest versions had many advantages in terms of capability, performance, etc. then why not, but that's not the case, built-in Delphi libraries are mostly irrelevant (because of coverage, bugs, lack of support, performance...).
Final nail in the coffin is the turn around time for bug fixing from EMBT is not acceptable: weeks (best case) or months (if you're lucky) for an hypothetical fix means you have to fix everything yourself anyway, and their fix, if it comes about, may not even really fix things either. They would have to be way more agile for the bugfixing to matter in the field.
Michael Thuma Actually when I run into some issues I wonder if Delphi is really developed with Delphi because then the devs must have run into that issue at some point as well. They must have noticed themselves that the language is lacking certain features that would improve productivity (as in the ability to produce more compact and thus easier to write and more importantly to read code).
Remember when MS started using WPF in VS? They quickly noticed that it was just junk performance wise and they worked on it (no arguing if it now performs well enough please). But imagine how long that would have taken to do at least some improvements if they never started using it themselves.
If you are using your own software be it a library you wrote or be it a complete software you are having a different perspective on it. That's a process of reflection and not just code and forget.
If porting takes a few days to get to a stable state, then it could be okay. When it takes weeks or more, it is not realistic to freeze development for that long and/or devote all resources to the port, especially given that the new version does not offer much (if any) that will simplify future development or enhance the application in any significant way (actually, 3rd party would still have to be used because what's in the box is far from being up to scratch). So port to a new version has to proceed alongside regular development, which means both versions have to be alive and maintained at the same time.
Also there is not XE and the latest version, we buid Entreprise software, with maintenance cycles measured in years, and features/fixes getting ported across versions. We are facing all the Delphi versions we have versions we maintain against.
The fix lists since XE3 are longer than ever. EMBT has started the mammoth task it is to overhaul the IDE, at the same time as they have introduced new platforms, new cross platform UI frameworks, new database drivers and numerous other changes. EMBT has done more for Delphi in a few years than Inprise/CodeGear did for a decade.
ReplyDeleteAs for the IDE - it has been showing it's age for some time - I agree. I have to restart it many, many times a day - but it still is the IDE of choice for coding for me. With all it's warts, Delphi still is a very productive tool for Windows UI apps and Windows services.
Unlike MS and Apple which can funnel funding from other sources of income, EMBT has to get paid for their IDE. A subscription model with a lower entry point seems like the obvious choice. That said, MSVS is far from free. We pay far more money for licenses per individual per year to MS than we do to EMBT.
Those that feel moving on to C#/.NET or other platforms is the solution - should make the move. I wish them luck. It still puzzles me though, why some of those that have made the move still linger in the Delphi communities.
Current issues status at https://quality.embarcadero.com
ReplyDeleteUnresolved - 916 74%
Resolved + Closed - 317 26%
Last 30 day summary
209 created
211 resolved - with release of XE8, we will not see any other resolved issues for next 6 months, and already number of newly created reports is the same as number of resolved issues.
And older issues reported in QC are not included. Since XE8 was released recently above numbers do not look good. Whatever efforts EMB is putting into resolving bugs, that is still just not enough.
Dalija Prasnikar - Valid points, which I hope Marco Cantù will be able to address. Does EMBT have enough people on fixing and testing?
ReplyDeleteLars Fosdal I would like to think they would be able to do more in bug fixing department.
ReplyDeleteBut I am not sure they have enough people involved in fixing and testing. Also people writing their code have to take more care about what kind of code they produce.
If developers are satisfied with writing crappy code or under pressure to write a lot of code fast and have to leave finding their bugs to others then time difference between when code is written and when bug is detected increases and the harder and more expensive is to fix that bug.
I don't know about bugs and fixes, but there is one thing I want to mention: from the first versions of Delphi the VCL source code was an example of perfect code on Pascal and was recommended as standard. I think it lasted till Delphi 4 or 5, maybe 2006. It's hard for me to consider VCL/RTL source code of Delphi XE2 or XE5 as the good example. (I haven't seen the last versions, so maybe I'm wrong and code has been improved) :)
ReplyDeleteIgor Schevchenko Code has not improved, on the contrary...
ReplyDeleteIMO EMB needs to start focusing on the IDE and the code editor, it's full of bugs and they can only delay for so long before it hits them right in the kisser!
ReplyDeletethe instability of the IDE and the poor performance of the code editor is a major hit in terms of productivity, basically, I'd go as far as saying that it almost cancels out the productivity advantage that Delphi has over other languages such as C++ or even C...
agree or disagree, the reality is, XE9 will either have a good and stable IDE or it will be a complete failure, too many "shiny features" that have to work around internal bugs that eventually will make themselves very evident.
Well ... what do we know about XE9 yet?
ReplyDeleteThe main issue is that you are not paying for bug fixes, but for a new version in which bugs may be fixed, and new bugs will have been introduced.
ReplyDeleteDelphi is really missing what all Entreprise-class software has: bug fixes for current and previous versions, ie. bug fixes you can use. Delphi is missing a "stable" release channel, which lags the alpha/beta/canary versions, and is still maintained.
We are still using XE because the few issues fixed in newer versions do not offset the loads of issues introduced in new versions. And all the new libraries and features introduced in half-finished half-tested half-optimized form in newer Delphi versions have stable, well-tested and well optimized versions for XE.
For new or mobile software, I would not choose Delphi these days, even if it was bug-free. It has fallen way behind the curve on too many aspects.
Eric Grange It was my understanding that Nick references the new Update Subscription, which is said to include bug fixes for current and older versions, and in that context it is "paying for bug fixes".
ReplyDeleteROI on my Delphi Pro+Mobile (XE5, XE6, XE7, XE8) investment 2013-2015: +2400%
ReplyDeleteDorin Duminica As far as code editor bugs and speed go, while I agree it's buggy - code insight especially - you don't know speed issues until you've used Visual Studio. Using it makes me view Delphi's editor in an entirely better light :)
ReplyDeleteI was trying to comment on Nick's post without success, then I found this post and I have to say it I couldn't expressed my concerns better, I have projects to maintain so I will be around for sometime, but I'm already investigating what tool chain will choose to replace Delphi :-(
ReplyDeleteI can't support Nick's notion. First, it is offensive to have to subscribe merely to get fixes for the defects in a product just shipped, as is apparently the policy now with XE8. Second, if the rationale for a subscription model rests in any significant way on the premise that defects are fixed, then EMBT has to make a very significant change to their practice in that area.
ReplyDeleteIt cannot be considered acceptable for the defects in the IDE to fester through multiple releases -- after all, the IDE is used by everyone, even those mobile folks who seem to consume so much of EMBT's current interest.
It cannot be acceptable for defects to be downgraded merely because they have been in existence for so long, therefor, in theory, less important. Less important, I suppose, if you simply ignore user feedback, which has been plentiful over the years.
Finally, the single biggest danger in a subscription is the key question we should all be asking: "What have you done for me lately?" A subscription model is a fast treadmill. Past performance does not instill high confidence in me for the new model.
If you have a good product, with high quality, you continuously improve it, you support it well, and you communicate well with your customers, people will gladly pay you an annual subscription.
ReplyDeleteIf you sell crap, then people will turn up their noses.
Eric Grange Hey, please say more about the problems you found in Delphi's mobile development. I will be glad to hear it.
ReplyDeleteEric Grange - The comment about lacking a stable release is accurate. This is why we don't move to the latest release until the first service pack is out.
ReplyDeleteLars Fosdal And the problem with latest Delphi releases (when they started 6 months release cycle) is that you don't have stable release. There is no time to identify and fix most critical issues before the next release hits the road.
ReplyDeleteIf Embarcadero would release another service pack for old release when new release is out that would improve things, but so far that didn't happen.
We'll see how this new "fixing issues for past two years" thingie will work out.
Dalija Prasnikar The subscription model is a treadmill. I think that the goal of fixing things in the "past two years" is a further burden that they will not be able to sustain. Still, I dare to hope, as we will be on XE7 for some time.
ReplyDeleteYes, given the rate at which new versions come out, properly reporting fixes across 3-4 versions does not look very realistic, meaning only few things will be fixed.
ReplyDeleteHorácio Filho no specific issues, but death by a thousand issues. Most issues can be worked around, but the problem is in bumping on them, narrowing them, and fixing/finding solutions. The issues range from compiler issues, to RTL/VCL bugs, to IDE bugs, to problematic changes that make having code compile under multiple Delphi versions complex. When things take time to fix because of many issues, it means you have to keep the codebase working against several Delphi versions, etc.
Also if the latest versions had many advantages in terms of capability, performance, etc. then why not, but that's not the case, built-in Delphi libraries are mostly irrelevant (because of coverage, bugs, lack of support, performance...).
Final nail in the coffin is the turn around time for bug fixing from EMBT is not acceptable: weeks (best case) or months (if you're lucky) for an hypothetical fix means you have to fix everything yourself anyway, and their fix, if it comes about, may not even really fix things either. They would have to be way more agile for the bugfixing to matter in the field.
Michael Thuma Actually when I run into some issues I wonder if Delphi is really developed with Delphi because then the devs must have run into that issue at some point as well. They must have noticed themselves that the language is lacking certain features that would improve productivity (as in the ability to produce more compact and thus easier to write and more importantly to read code).
ReplyDeleteRemember when MS started using WPF in VS? They quickly noticed that it was just junk performance wise and they worked on it (no arguing if it now performs well enough please). But imagine how long that would have taken to do at least some improvements if they never started using it themselves.
If you are using your own software be it a library you wrote or be it a complete software you are having a different perspective on it. That's a process of reflection and not just code and forget.
Michael Thuma At Chronos' bidding (aka time).
ReplyDeleteIf porting takes a few days to get to a stable state, then it could be okay. When it takes weeks or more, it is not realistic to freeze development for that long and/or devote all resources to the port, especially given that the new version does not offer much (if any) that will simplify future development or enhance the application in any significant way (actually, 3rd party would still have to be used because what's in the box is far from being up to scratch).
So port to a new version has to proceed alongside regular development, which means both versions have to be alive and maintained at the same time.
Also there is not XE and the latest version, we buid Entreprise software, with maintenance cycles measured in years, and features/fixes getting ported across versions. We are facing all the Delphi versions we have versions we maintain against.
Michael Thuma These days HTML5 is IMHO the place were RAD exists.
ReplyDelete