Marco Cantù posts "2013: A Great Year for Delphi.
Marco Cantù posts "2013: A Great Year for Delphi.
I am still deeply in love with Delphi, but - without rehashing all of non-tech - there are some trust issues after some fairly major let-downs in the recent years.
My advise for the next versions, is:
- Make sure you never again release technology that has not been properly matured and dogfood'ed. Want to draw us into FM2? Build some FM2 based tools that we actually will be using on a daily basis (such as a new QC).
- Take a close look at some of the newer units that have been added. There is quite a bit of sketchily documented and - IMO - poorly written code. Ensure that all code has proper peer design review and code review before unleashing it onto us.
- Unit dependencies - Some of the core units pull in way too much luggage which the linker can't get rid of. If necessary, split up the core units even more and perhaps move some of the initialization sections into explicit procedures that can be invoked from another unit's init section - so that people have more control over what gets bootstrapped into their project.
- Spend more time knocking off more of the long time standing issues in the QC system. There are a LOT of niggles and annoyances that should be put to rest.
- Revamp QC with a better UX and make it more accessible. Expose ALL known issues, not just those that have been reported externally. You might even find volunteers that would be willing to do the UX part.
- IDE stability. Any larger size project will eventually produce an out-of-memory situation. Why?
- Debugger stability under 64-bit. Need I say more?
I am very much looking forward to see what the future holds for my favorite bread and butter tool.
Originally shared by Marco Cantù
Blog post "2013: A Great Year for Delphi" at http://blog.marcocantu.com/blog/2013_great_year_delphi.html
http://blog.marcocantu.com/blog/2013_great_year_delphi.html
I am still deeply in love with Delphi, but - without rehashing all of non-tech - there are some trust issues after some fairly major let-downs in the recent years.
My advise for the next versions, is:
- Make sure you never again release technology that has not been properly matured and dogfood'ed. Want to draw us into FM2? Build some FM2 based tools that we actually will be using on a daily basis (such as a new QC).
- Take a close look at some of the newer units that have been added. There is quite a bit of sketchily documented and - IMO - poorly written code. Ensure that all code has proper peer design review and code review before unleashing it onto us.
- Unit dependencies - Some of the core units pull in way too much luggage which the linker can't get rid of. If necessary, split up the core units even more and perhaps move some of the initialization sections into explicit procedures that can be invoked from another unit's init section - so that people have more control over what gets bootstrapped into their project.
- Spend more time knocking off more of the long time standing issues in the QC system. There are a LOT of niggles and annoyances that should be put to rest.
- Revamp QC with a better UX and make it more accessible. Expose ALL known issues, not just those that have been reported externally. You might even find volunteers that would be willing to do the UX part.
- IDE stability. Any larger size project will eventually produce an out-of-memory situation. Why?
- Debugger stability under 64-bit. Need I say more?
I am very much looking forward to see what the future holds for my favorite bread and butter tool.
Originally shared by Marco Cantù
Blog post "2013: A Great Year for Delphi" at http://blog.marcocantu.com/blog/2013_great_year_delphi.html
http://blog.marcocantu.com/blog/2013_great_year_delphi.html
Also be very careful about what you do (or don't) with the language, there are legions of language improvements that could have been done already with complete backward compatibility. And there are plenty of language changes that were botched jobs (generics, code-paged Ansi Strings...), things forgotten in limbo (dynamic arrays...), and plain bad language design choices.
ReplyDeleteBe wary of compiler and IDE performance and stability f.i. how come error insight is still unusable after so many revisions? How come the help is still so poor and sluggish google is a better alternative? These are issues raised back in D8 that never were addressed, and are totally crippling to new users.
Other things like the slow and ineffective copy protection in XE3 are also inexcusable for a software dev company. Add to that lost activation code for past products (Kylix) and you're fast turning reliance on Delphi into a liability.
Lars Fosdal - I couldn't agree more. I actually sent an email to Embarcadero a few months ago highlighting some similar thoughts.
ReplyDeleteFor the unit dependency issues Marco Cantù could try my unit dependency scanner (http://www.easy-ip.net/delphi-unit-dependency-scanner.html).
2013 will be a great year for Delphi if the communication about planned features and current status of development will see some improvement.
ReplyDeleteI really envy all those Visual Studio developers who have extremely easy access to early betas and RCs of new versions with a much better chance of providing all the necessary feedback for making the next release as good as possible.
I really wonder how new features like FireMonkey and Metropolis UI did pass the release process.
And please consider: Delphi doesn't get better just by adding more and more 3rd party tools.
To make this sure the + 1 is only for Lars Fosdal post.
ReplyDeleteThe value of the blog post is zero and I would be surprised if Embarcadero would surprise us with reliable and working stuff this year.