Today I viewed David Intersimone’s Live Webinar on what’s new in Delphi 2009, code-named Tiburon.
This is a Win32-only release. I think you will want it (if you use Delphi), if only for the new language-level features: generics, anonymous methods, and unicode strings. I grabbed a few screens from the presentation. Generics:
Unicode – here’s the TEncoding class:
and Unicode in action:
There are also some new components, such as a neat collapsible panel called TCategoryPanelGroup, TBalloonHints, and Office-2007 style ribbon controls.
The ribbon controls interested me because I am wary of Microsoft’s Office ribbon patent. CodeGear/Embarcadero seems to be wrapping Microsoft’s controls*, as used by the CMFCRibbon* classes, which as I understand it are not the actual controls used in Office 2007 but share their look and feel. You therefore have to agree to Microsoft’s license for the Fluent UI in order to use the controls.
There are also major changes to the DataSnap middleware but DavidI didn’t go into this much in the presentation.
During the Q&A at the end there were the inevitable questions: what about 64-bit (coming in a later version); what about Mac/Linux (nothing to announce); what about the dreadful online help (errrmmm we’re working on it); what about .NET (coming in a later version). Some of the language changes seem to be making ready for .NET 2.0 compatibility.
No announced release date; but the roadmap shows this as a 2008 release; and if it’s being webinared now that suggests it won’t be too long a wait.
Delphi is still absolutely my favourite Win32 development tool and this should be a strong release. At the same time, it is all rather old-school: win32, native code, fat client. You can do web applications in Delphi, and there is an updated “VCL for the Web” in this release, but why would you?
Nevertheless, if there are any Delphi developers still hanging on to Delphi 7 (the last version with the old IDE), perhaps these important language changes along with what is now a mature new-generation IDE will be sufficient to persuade them to migrate.
*Update: Although DavidI said that Delphi’s ribbon controls wrap Microsoft controls, Nick Hodges says here that this is not the case. He is probably right as I’m not sure what controls Delphi could wrap. If the MFC team could not use the actual Office controls, but had to create its own implementation, then I should think a third party would be in the same position. I wondered if the VCL was actually using the MFC code but I doubt that would be straightforward either. This may be a confusion caused by the licensing requirement.
Oh Tim, there is that “ribbon” again and MSFT has a patent on it? Oh my. 10 more years to my retirement – I can hardly wait man, our industry continues to become nuttier and nuttier.
Speaking of Delphi ;-), I remember one organization whose Delphi developers held the company hostage so as to not move over to VB6… and they won! Delphi developers are the most loyal I have ever met in my +20 year career. I am sure this release will continue to breathe more life into a product that should have died at the same time as VB6.
Don’t get me wrong, in some ways I thought VB6 was the pinnacle of software development for business IT apps as it was the quickest way to get the job done (except the Delphi folks would argue otherwise). But now even IT folks want web apps, where does that “really” leave Delphi?
Keep up the good writings!
Tim –
Yes, to confirm, the Ribbon Controls in Delphi and C++Builder 2009 are pure VCL.
Nick
Mitch —
If you are building business applications on the web, then the best solution out there is VCL for the Web, which is a key technology in Delphi.
You get all the power of Delphi when building applications for the Browser.
Nick Hodges
Delphi Product Manager
Embarcadero
Tim –
In fact there were many more improvements to Delphi language since Delphi 7, including operator overloading, records with methods and many more. More info here
Pawel Glowacki
Embarcadero Senior Software Consultant
See, that’s the trouble. No matter how “mature” the new IDE becomes, it’s still slow and a resource hog. I’d be a lot happier with it if it were to fix a few specific issues:
1. Blocking tooltips. It drives me up the wall when I’m scrolling up a page or moving the mouse around, and the cursor happens to roll over some variable that causes the entire IDE to freeze up for ~30 seconds while my hard drive spins, trying to pull up a tooltip. An IDE is supposed to be a text editor with some special features added on to facilitate development. Again, an IDE is supposed to be a text editor, with some special features added on. Text editors never exhibit blocking behavior. When was the last time you locked up Notepad? If the IDE absolutely has to spin my hard drive for thirty seconds to load a bloody tooltip, why not have it do so in a background thread?
2. Blocking Code Completion. Same thing here. Don’t get me wrong. I love CodeInsight. It’s a wonderful thing to have around… when it works. But if I already know that I want to put “if MyList.Count > 5 then”, and I’m suddenly stuck waiting 30 seconds while my hard drive spins because Delphi decided to invoke CodeInsight when I type the dot and it wasn’t “warmed up” yet, there’s something very wrong there. I type over 70 WPM. I can type the word “count” in less than a second, but Delphi forces me to wait for CodeInsight to be ready before I can get on with my coding. Same problem as the tooltips, and with the same solution: if CodeInsight needs to warm up, have it do so in another thread, instead of blocking the text editor.
3. Load times. Delphi 2007 takes longer to load than Half-Life II, Oblivion, Supreme Commander… come to think of it, it takes longer to load up than any of my heavy-duty 3D games, and I’ve got quite a few. There’s just no excuse for that. An IDE is a text editor. A text editor should load and be ready to start editing text instantaneously. Notepad takes about 0.75 seconds to load on my computer. WordPad takes about 3 seconds. Delphi takes anywhere from 1 to 3 minutes, depending on what mood my dev system is in. There’s no good reason why it shouldn’t be up and running in 5 seconds, tops. If there are other big, bulky features to be loaded, have a background thread load them once the core functionality is up and running.
4. Memory leaks. When I load up Delphi 2007 fresh, Task Manager generally pegs it at around 12 MB. Opening my current project group brings it up to 46 MB. That’s a bit much considering there’s less than 1 MB of text to edit, but I’ve got plenty of RAM. I can live with that. The problem is, after I’ve left it on for a week or so, logging plenty of hours writing code, compiling, running, testing and debugging and all that good stuff, that 46 MB is no longer 46 MB, but anywhere from 110 to 400 MB, and a fair amount of that doesn’t go away if I close the project group and reopen it. It’s not nearly as bad as Delphi 2006 was, but there’s still a ways to go.
An IDE is a text editor with special features. That’s what Delphi 7 was, and it was very good at being a text editor with special features. That’s why we all loved it so much. But Delphi, from version 8 to the present, has been a set of special features with a text editor included. The tail’s been wagging the dog for too many years now, and the dog’s owner is getting sick of it. Fix these four issues, and almost all of the “Delphi 7 was better” whining will disappear for good.
@masonwheeler – good points, though you can turn CodeInsight off or disable the most annoying options – even if it is off, you can use it manually with CTRL+SPACE. I don’t find it too bad, but I guess it is system-dependent too.
Tim
True enough. That doesn’t fix the load times and memory issues, though.
The other thing that really bugs me about Delphi is properties. Here we have Properties, one of the best things that ever happened to object-oriented programming, allowing us to treat object data members as ordinary variables while preserving encapsulation… and it’s only halfway implemented. There are two specific things that really bug me, that could be fixed very easily.
1. Read/write properties. Give me one good reason why you should ever not be able to pass a property with both a read and a write value defined to a var parameter of a function. But the compiler chokes on it. “Left side cannot be assigned to.” Well why not? Half the time, the read and write are pointing directly to the same variable. (Which ought to be definable as “property number: integer read write FNumber;” for simplicity’s sake, but the compiler doesn’t like that either.) In this case, simply pass the internal variable to the var parameter. In every other case, have the compiler automagically do what we all end up doing instead: create a temporary variable on the stack, retrieve the read value, pass it in, and on return, copy the temp. value back to the write parameter. A few special considerations would most likely have to be considered for objects, interfaces, and various special cases, but the coders who’ve managed to write the masterpiece that is the Delphi language should be able to tackle these minor issues in such a way as to make them transparent to us.
2. Array properties. Just… array properties. Seriously, whoever wrote the current implementation is a big exception to my above statement about masterpiece-writers, and ought to be taken out and shot. The way array properties are currently implemented makes perfect sense, as long as you accept the rather absurd premise that your objects will never contain any data members that are actual arrays! Yes, there have been times when I’ve used array properties to “fake it” and make something that looks like an array where a real array didn’t exist, but they’re very few and far between. For all the rest of the array properties that refer to real arrays, we’re stuck with the primitive practice of writing accessor and mutator methods even if all we need is direct access. (If I wanted to have to deal with that sort of syntactic diarrhea, I’d be using C++!) And if you declare an array type, and simply declare your array property as that array type, you still can’t do a lot of useful things with it, such as change the length of a dynamic array, (at least not without some horribly convoluted code!) because of the var parameter issue!
Honestly, would it really hurt that much to allow the following as valid syntax?
“property myArray: array of TMyObject read FMyArray write FMyArray;”
I don’t complain about Delphi because I hate it. I complain because I love it. It’s by far the best programming system I’ve ever worked with, on the merits of the Object Pascal language alone. The IDE is icing on the cake. But the problem with building a program targeted at professional coders is that we can see where the room for improvement lies a lot more clearly than most users, and these two rants of mine are where Delphi really needs improved. (There are probably a few other places, but these are the points that consistently cause trouble for me.)
I can only hope that a D2009 patch will fix these things up.
Mason
Because there still isnt a truly RAD environment for the web. Ive been waiting for what seems like forever for a tool for the web as what Delphi is to win32 and it doesnt exist!
I remember when Borland launched Intrabuilder years and years ago, rad for the web? nope good idea poorly executed. I got excited over JBuilder 1, I thought that was going to be Delphi for Java, it wasnt, not even close! Then we had Delphi for PHP, buggy and frustrating.
I’m with Mason, I still use D7 for the simple reason every other IDE release since has destroyed what has made me productive with every other release of delphi pre version 7. I mean D7 fits on 1 CD, D2005 needs three!?!? ok install typically takes two but its certainly suffered some code bloat!
Gary
“If you are building business applications on the web, then the best solution out there is VCL for the Web, which is a key technology in Delphi.
You get all the power of Delphi when building applications for the Browser.”
Sorry Mr. Nick, but VCL for the Web doesn’t seems to be the best solution out there, and to be honest, I don’t know much companies that use it. Even CodeGear/Embarcadero actual WebSite seems to use another technology to power it up.
I Belive that Delphi is still the best win32 RAD tool ever, but since 2003, I haven’t seen something new that could really make me feel
motivated to buy a new version. Now, Delphi is becoming nothing else than a C# clone ( and not a good one).
The new VCL seems to be a good hit, but I will wait a few versions more to buy a new one. There are still only a few improvements at all, and Delphi (in Brazil) is more expansive than VS.