Just over a year ago, I wrote a blog post where I listed some ideas for enhancing the Delphi language. In that post, I showed 20+ language features that would not break existing code, but would bring some modern language constructs to the language, and help us write less, but more expressive code.
Just over a year ago, I wrote a blog post where I listed some ideas for enhancing the Delphi language. In that post, I showed 20+ language features that would not break existing code, but would bring some modern language constructs to the language, and help us write less, but more expressive code.
So, 12 months on, what's changed? - Sadly, absolutely nothing. Yes, there's a roadmap feature for 10.3 that says nullable types, but that's it. BTW, I never mentioned nullable types in the post a year ago, because they were already on a roadmap or mentioned by embarcadero.
I guess resources (people) are in short supply when you are constantly chasing the latest breaking change in ios or andriod. sigh
https://www.finalbuilder.com/resources/blogs/postid/750/delphi-language-enhancements
So, 12 months on, what's changed? - Sadly, absolutely nothing. Yes, there's a roadmap feature for 10.3 that says nullable types, but that's it. BTW, I never mentioned nullable types in the post a year ago, because they were already on a roadmap or mentioned by embarcadero.
I guess resources (people) are in short supply when you are constantly chasing the latest breaking change in ios or andriod. sigh
https://www.finalbuilder.com/resources/blogs/postid/750/delphi-language-enhancements
/sub
ReplyDeleteTop 2 for me:
ReplyDeleteTry/except/finally would really simplify and "flatten" a lot of code.
String Case Statement - the readability improvements would be spectacular!
I am all for changes where the amount of boilerplate or hard to read code can be reduced.
My one I would add in would be string appending:
instead of s := s + 'some extra text';
s += 'some extra text';
Surely that is completely syntactic sugar and long overdue - just like i++; and i--;
The concept except is totally different from finally and hardly mixed in one statement (I've done statistics for that in private Delphi, Java and C# code bases) so no need for that.
ReplyDeleteHelpers on interfaces would be the big thing for me.
The second big thing: fixing the know compiler bugs and anomalies.
Martin Sedgewick If you have a lot of instances of except and finally nesting then that suggests that the code is handling exceptions poorly. No language enhancement is needed, just better coding.
ReplyDeleteDavid Heffernan Absolutely! I was tired (3am) when I posted that. It sounded like I would get some benefit, but I dont really use that pattern as much as I thought. Just scanned my codebase for examples of this and there are not as many as I assumed. I`ll take that!
ReplyDeleteA lot of these extensions I have seen in a product sometimes called prism......
ReplyDeleteLuckily we don't have to worry if any of those will make it any time soon because at least since yesterday we know that their compiler person will be busy implementing android64 next year ;)
ReplyDeleteStefan Glienke "their compiler person" I laughed so hard!
ReplyDeleteStefan Glienke Tagawa San (https://twitter.com/yooichitagawa Yooichi Tagawa) is a busy guy indeed.
ReplyDeletetwitter.com - Yooichi Tagawa (@YooichiTagawa) | Twitter
Martin Sedgewick no problem (: That was exactly the reason I did those statistics a while ago.
ReplyDeleteWhile I certainly would want some more language sugar such as multiple type helpers, interface type helpers, enumerable constraint for generics and some lambda syntax, I certainly wouldn't want them to be rushed...
ReplyDeleteStefan Glienke and OSX 64...
ReplyDeleteWhy is try except finally end considered as not useful? When you have to free an object and react to an exception it would enable us to write the free only once with all the benefits this means.
ReplyDeleteAm I missing the point?
Christen Blom-Dahl Given that is on the roadmap for 10.3 that work should almost be finished early 2018.
ReplyDeleteKlaus Edelmann Personally I don't consider it as not useful but it's the category "in rare situations saves a few words" compared to some language features that enable entirely new ways to design code (like interface helpers).
Klaus Edelmann I consider it not very useful because the scenarios where it could be used are rare.
ReplyDeleteI'd vote on a 10.3 with no new features at all, just focused on quality. (with the exception of platform changes requiring new updates.) I'd vote these to the bottom of the todo list: Type Inference, inline variable declaration, strings in case statements, named params, variable method arguments.
ReplyDeleteDarian Miller A release with no new features and focus on quality, been suggested a thousand times over the years, will never happen. Asbjørn Heid no wouldn't want to rush them... but how long should we wait?
ReplyDeleteVincent Parrett Well certainly a lot longer than one year for any non-trivial feature.
ReplyDeleteDon't get me wrong tho, I'm aching for more language features.
Asbjørn Heid If they haven't already made some progress on things then it's probably going to be too late.
ReplyDeleteDavid Millington I wonder if anyone official picked up on this tidbit?
ReplyDeleteSadly, I think C++ has had more language changes between single standards updates than Delphi has had since it was initially released! Since Delphi isn't a "standard", the vendor has absolutely no incentive to add any improvements to the language itself. Rather, they spend their R&D dollars on bigger, fancier libraries that can help sell higher-priced SKUs. Language changes don't translate into added revenues (or even loss of revenues), so ... why should they bother?
ReplyDeleteFWIW, I'd LOVE to see ALL of these proposed changes.
Darian Miller You might vote on a 10.3 with no new features at all, but such updates hardly sell (people hate to pay for the correction of bugs that "shouldn't have been there anyway"). And Embarcadero has to make money, somehow.
ReplyDeleteRudy Velthuis Guess we are trapped in a vicious cycle then.
ReplyDeleteRudy Velthuis that was previously very true, but we are now migrating to a full subscription services model. I would think it would make great PR and get more people believing in the subscription model to have a quality-only releases. In reality it could be simple semantics - just upgrade a point level update to a version level release. So instead of a version 10.2.3 (or two 10.2.3's if they screw that up again...) release 10.3 next time. Then they could make every odd level release a full version focused on quality (with feature toggles perhaps for new behavior.) Then make every even level release to unlock new features. That way you get a constant focus on fixes and features in a well defined, easily explained system. Just typing off-the-cuff, but it's got some merits.
ReplyDeleteDarian Miller hey, why does that sound familiar?
ReplyDeleteDarian Miller Impossible, Embarcadero has to react to so many other vendors to stay in the game (android64, support new OS releases and tools versions) that they barely have the time for anything else.
ReplyDeleteStefan Glienke Unlikely perhaps, but not impossible... OS Support changes could be included in the odd releases as needed.
ReplyDeleteJeroen Wiert Pluimers Did I repeat your idea? : )
ReplyDeleteDarian Miller Linux kernel versions.
ReplyDeleteAsync/await is my killer feature, and if we were starting from scratch, I'd probably chose C# over Delphi just for it. As it is, we're making do with anonymous method callbacks and it is not pretty. The poor language integration for the parallel library relative to C#/Oxygene, and the lousy Objective C bridge compared to Free Pascal, are marks against it too.
ReplyDeleteOf course, resources (people) are also in short supply when you let all of your experienced staff go, so I don't see our fortunes changing any time soon.
If we are talking about ideas anyway, I always wanted generics for non-method functions and procedures too. It sucks to always having to put them in a class (or record), often as static class functions. So instead of TArray.Sort you would simply have a standalone Sort function (I hope these pointy brackets are not seen as HTML tags in this comment). Would make implementing and especially using algorithms a little easier.
ReplyDelete