VSoft Technologies Blogs - posts about our products and software development.
Back in December 2016, I posted some ideas for some Delphi language enhancements. That post turned out to be somewhat controversial, I received some rather hostile emails about how I was trying to turn Delphi into C#. That certainly wasn't my intent, but rather to modernize Delphi, in a way that helps me write less, but more maintainable code. Nearly 2 years later, Delphi 10.3 Rio actually implements some of those features.
I'm not going to claim credit for the new language features, and the syntax suggestions I made were pretty obvious ones, but I like to think I perhaps spurred them on a bit ;) My blog post had over 12K views, so there was certainly plenty of interest in new language features, and from what I have seen out there on the interwebs they have for the most part been well received.
So lets take a look at which suggestions made the cut for 10.3 - referencing my original post.
So, 3 out of 23. To be honest, I was pleasantly surprised when I found out about them, given the pace of language change in the past. I'm hopeful this is just the start of things to come and we get to see Delphi evolve and catch up with other modern programming languages. I have a bunch of other language features I'd like to see, and received lots of suggestions from other users.
We're still using Delphi XE7 for FinalBuilder 8, and I rarely change compiler versions during the life of a major product version. So I'll only get to use the new language features when I get fully stuck into FinalBuilder 9 & Automise 6. I'm in the process of getting Delphi 10.3 compatible versions of all the third party libraries (commercial and open source) - as and long time delphi user will know, that's always more difficult than it should be!
IMHO if you fundamentally revise the typesystem, you should start a new language/project. The Delphi typesystem is quite complex, specially the string related conversions.Doing some windowdressing like Embarcadero did is just about getting bulletpoints for marketing, it serves no real purposes, solves no real problems.The people that don't want to go that way hate it, and it doesn't go deep enough for the people that really want to go that way. What you get is a compromise that nobody wants, just to justify the subscription tax another year.
So you're seeing about the same rate of progress I did... back in 2012 I created a list that had about 40 items on it to improve the language, library and IDE. Eventually about 1-2 items started showing up per new version, although none lately. Now I can cross "type inference" off at least. I'm not as hopeful that we're about to see the floodgates open to massive modernization and improvement of the language as you are though. Still, I was beginning to think type inference would never materialize. A free version and type inference now though... if they'd just give us a modern IDE now too, we might have the bare essentials in place to start attracting new users.
Thank you so much for such a wonderful software developer tool as Final Builder! Its software release build and deployment automation capabilities makes life for software build shops so much more easy! Thanks from Moscow, Russia.
Actually, non-refcounted interfaces do exist. Just declare them [unsafe]
Type inference is very required.The lack of it made compatibility backdoor hack - record helpers - promoted into libraries core feature, starting with RTL.And when i was porting VurtualTreeViee back to XE2 replacing hacked simole types with advanced records and implicits - Delphi prooved inadequate for source code compatibility. Even simple operator x in <…> could not work.Just crazy.Ternary operator is possible but is not required.It is perfectly substituted with generic and inlined IfThen<T> function.......if Delphi had normal type inference and lazy parameters - so again, type inference.Crazy concept of "assignment compatibility" - an ugly hack-around patch-worked hybrid type system - could be obsoleted too.