views:

1101

answers:

12

We have a medium-to-large size application. One version runs on Delphi 6 and another one on Delphi 2006.

One argument would be support for Unicode. We need that to cater to Customers around the world.

Other things I have read about are: better IDE (stability, speed), better Help and some cool additions to the language (e.g.: generics)

What about third-party components? We use DevExpress, DBISAM and many others. Are these already ported?

Touch/Gestures sound cool, but we have no use for that in our application.

+2  A: 
  • The refactoring tools and overall speed and stability of the IDE will make the development team more productive.

  • Working with the latest tools will make it easier to recruit top talent.

JosephStyons
+4  A: 

Purely as a reactive measure. Lets say that there is a new feature in the latest version of a yet to be released operating system. Lets say that this feature breaks certain features inside your application. IF there was to be a global fix for it, it would most likely not be placed in older versions of the compiler, but the newer versions which "officially" support the new operating system. The largest problem about waiting too long is that when such a measure is needed its generally at the zero hour when sales are at risk.

Upgrade NOW, and help prepare your application to be more reactive to future changes.

skamradt
I wouldn't be so quick to latch on to that. The changes made to make my Delphi 7 apps "Vista" capable actually work better on Windows *7* than the "Vista" capabilities added to Delphi 2007+.Just because it's "in the box" doesn't mean it's the best solution. And with Delphi, unlike .NET or some others, the clearer separation between compiler and framework - VCL - and the fact that the framework can be updated even in older versions supplied with older compilers pretty much nullifies the "got to stay current to be current" argument.
Deltics
So the addition of Vista-specific dialogs to Delphi 7 work better on Windows 7 than those added in Delphi 2007+? And the themed drawing of TDrawGrid/TStringGrid/TDBGrid (that didn't exist in D7) work better than those added in Delphi 2010? And how about that ribbon control in Delphi 7 - does it work better than the one in D2009+? :-)
Ken White
@Deltics, its all a risk. You risk staying, you risk upgrading. I was just pointing out that *IF* there was a "program breaking feature" implemented in the *Latest* operating system, that the changes by the compiler would most likely NOT be implemented in previous versions which never supported the OS in the first place.
skamradt
The DevExpress ribbon control works FAR better than the one in Delphi 2009 which is so badly broken as to be beyond a joke. The one in Delphi 2010 does look to be fixed at last. Now I just need to fix the rest of my app as a result of the Unicode breakages in my code and all the components I use, and then I might be able to use it.
Deltics
+10  A: 

Better theme support (eg., TStringGrid/TDBGrid now support themes).

Support for Windows Vista and Windows 7, including support for the Direct2D Canvas in Win7 and the Touch/Gesture support you mentioned.

Improved refactoring, including support for refactoring generics.

Built-in source code formatter.

IDE Insight allows you to find things in the IDE itself.

Enhanced RTTI.

Improvements in the debugger, including new custom data visualizers and the ability to create your own. There are two included with source (one for TDateTime and one for TStringList). Also better support for debugging threads, including the ability to name threads for debugging and set breakpoints on specific threads.

The ability to add version control support to the IDE via interfaces. This will allow version control developers to add support directly in the IDE itself.

The help is much better than in previous versions. It's been completely redesigned again, and is much more comprehensive and complete. There's also an online wiki-based version (used to generate the help itself) that you can add or edit.

Background compilation allows you to continue working while you're compiling your project.

As far as third party controls, that's up to the specific vendor; you'll have to check to see if Delphi 2010 versions are available for each of them individually. (You might check the Embarcadero web site, though, to see if they have a list already available; I seem to recall hearing of one... Ah, yes. Here it is. )

Ken White
A: 

Item 9 of the The Joel Test: 12 Steps to Better Code is:

Do you use the best tools money can buy?

Perhaps this argument is germane here.

On the other hand if you are maintaining legacy code and not generating anything that has dependency on new OS or tool features, it is a hard argument to win. I would not however recommend generating entirely new projects on tools that old.

Unicode has been supported on Windows since at least NT 4.0, and for Windows 95/98/Me since the addition of MSLU in 2001 - so surely Delphi 2006 supports it!? [edit]Not fully supported in the component library it seems.[/edit]

I suggest that the one compelling argument is in order to ensure Vista and Windows 7 compatibility. I understand that 64bit target support was planned for Delphi this year. That may be another argument; but again it only applies if you actually intend to target such a platform, and in a way that will give a tangible benefit over 32bit code. [edit]I emphasised planned because I did no know whether it had made it into the product, but that it might be a consideration for you. It seems it has not, so the argument you put to management might be even less strong.[/edit]

Management are not going to be impressed by the "I just want cool tools to play with", you have to approach it on a "Return on Investment" (ROI) basis. Will you get your product out faster or cheaper using this tool? Are the existing tools a technical barrier to progress? Conversely, consider whether spending time porting your legacy code to new tools (with the associated validation and testing) will kill your budgets and deadlines for no commercial advantage?

Clifford
Save your snarky comments. Delphi fell behind in new features for a few years because of some suicidally stupid decisions by its previous owner. It's owned by a new company now, one that takes it seriously, and those problems don't apply anymore.
Mason Wheeler
Has none of you guys used Windows NT 3.1? What's with the wide-spread idea that Unicode "support" has been magically added in version 4? This is something which the whole OS has been built upon, to quote Wikipedia: "Windows NT was one of the earliest operating systems to use Unicode internally." The public API just provides Ansi (`SomeFuncA`) and Unicode (`SomeFuncW`) versions of most functions on top of that. Internally **everything** is Unicode, and always has been.
mghie
Also, 64 bit support has been planned (and promised) for years now, and never materialized. Not in Delphi 2010 either. So it may be another argument, but not one for updating to Delphi 2010, on the contrary...
mghie
@Mason Wheeler: It is not the ownership nor the quality that concerns me. But rather the commercial sense in betting your house of a proprietary language form a single vendor. It is a fine programmer's tool; selling its use to a manager concerned with protection of investment however is a different thing. However the comments I believe you were referring to have been removed.
Clifford
Since you quoted it, the NT 4 comment came from Wikipedia's Unicode article which says "Microsoft Windows since Windows NT 4.0 supports WGL-4 with 652 characters", however in its context, it does not say that earlier versions did not support other Unicode standards; so I stand corrected, and have changed the text.
Clifford
@mghie: Sure, Unicode existed in WinNT 3.1. However, Delphi supported Win95, 98, and ME as well, which were not Unicode. Since NT was a **very** small part of the market at the time, it made much better sense to support the other flavors of Windows (which were in use in many more homes and businesses). And your comments about 64-bit are just a strawman argument, and have no place here; nobody's discussing 64-bit. The question was about reasons to upgrade to D2010, which the entire world knows isn't 64-bit.
Ken White
@Ken: I commented on Deltics' answer re Unicode, of course it should have been optional, kind of like MFC programs could be built for Ansi *or* Unicode. Two sets of DCU files and a compiler switch (I know it's not that easy, but still). But ignoring Unicode for nearly ten years brought us into the current problematic situation that Deltics correctly describes. As for 64 bit, I only commented on the part of the answer citing 64 bit support as another argument. This part of the answer seems to suggest that not "the entire world" knows about the continuing lack of 64 bit support.
mghie
+8  A: 
  • Last upgrade for old version

With old version of Delphi (before Delphi 2005), you have only before january 1 2010 to upgrade.

After you will have to buy a full version.

  • Productivity

http://www.tmssoftware.com/site/blog.asp?post=127

Hugues Van Landeghem
+1  A: 

D2006 was an awful version of Delphi. It's worth upgrading just to be rid of all the memory leaks and random IDE crashes and glitches. Justify it to the boss as a massive decrease in lost productivity. That means less money wasted paying you to not produce code because your dev tools aren't working. It'll pay for itself very quickly on that basis alone.

As for D6 vs. D2010, that's a feature argument. Start with Skamradt's response, that it helps your code be future-proof. Underscore it with OS compatibility. D2007 was the first version that understands Vista. D2010 is the first version to understand Windows 7. If you're compiling with any older version, your app is obsolete before you even deploy it because there's no guarantee it's compatible with modern versions of Windows.

Then you've got actual language features. The main improvements IMO from 2006 to 2010 are Generics, which helps out with all sorts of repetitive tasks, and extended RTTI. Robert Love has been doing some great blog posts lately on how the extended RTTI can simplify common real-world problems. (Plus Unicode, of course.)

Mason Wheeler
+2  A: 

The IDE is definitely a step up from Delphi 6 and/or Delphi 2006.

If Unicode is important to your customers then Delphi 2009/2010 is a clear option. But if Unicode is important to you, rather than your customers, then I'd be careful.

Unicode is not "free". If your users/customers have concerns w.r.t memory footprint and/or performance, and/or your application involves extensive string handling, then Unicode exacts a price that all your customers will have to pay, and for customers who are not themselves concerned with Unicode support, that price comes with zero benefit (to them).

Similarly if your application sits on top of a currently non-Unicode enabled database schema. Migrating existing databases from non-Unicode to Unicode is non-trivial, and if you have customers with large production databases, incurring downtime for those customers whilst they migrate their data stores is something you should consider carefully.

Also you will need to be very aware of any interfaces to external systems - your code will unilaterally "go Unicode", and that may adversely impact on external interfaces to other systems that are not.

In such cases you would do well to tie the transition to Unicode with other compelling feature improvements and benefits to make the transition compelling for other reasons.

Also, if you genuinely have customers with a real need for true Unicode, then the transition is not as simple as recompiling with the latest/greatest compiler and VCL. True Unicode support will involve a great deal more work in your application code than you might at first appreciate.

Of course, having a Unicode capable compiler/VCL is a crucial component, but it's not an answer on it's own.

The Unicode change has a significant impact on 3rd party components. Even if you have the source to your 3rd party code you may find yourself facing Unicode issues in that code unless the vendor has taken steps to update that code in a more current version. Most current vendor libraries are Unicode by now though I think, so unless you are using a library that is no longer supported by the vendor, you should be OK on that score.

I would also exercise caution when it comes to those "cool" language features such as generics. They sure do look cool, but they have some seriously limiting characteristics that you will run into outside of feature demonstrations and can result in maintenance and debugging difficulties as the experience of the community in working with them is limited, so "best practice" has yet to emerge and the tool support perhaps hasn't yet caught up with the uses to which those features are being put in actual code.

Having said ALL that.... Since you cannot realistically choose any version other than Delphi 2010 to upgrade to, then if you are going to upgrade at all then you have to bite the Unicode bullet and will find yourself presented with lots of tempting language features to tinker with and distract you. ;)

And now that Embarcadero are imposing a more draconian policy w.r.t qualifying upgrade products, you will have to get off of Delphi 2006 if you wish to qualify for upgrade pricing for Delphi 20*11* onward, whether you decide that 2010 is right for you or not, otherwise when the time comes to upgrade to Delphi 2011 you will find yourself treated as a new customer, and if you thought that upgrade pricing was steep, check out the new user license costs!

Deltics
+1, though I think that many of the arguments presented against Unicode are caused by the late Unicode adoption by the VCL alone. Most of them (like performance issues, missing support by Third Party components, and incompatible database schemes) wouldn't be issues at all now if the switch to the long strings in Delphi 2 had been made in a way to support both Ansi and Unicode, as even the very first WIN32 SDK did.
mghie
BTW, Unicode support is important for all customers, unless you don't have any place in the software where people's names or addresses or file names are handled. Or would you rather limit your customers to those with ASCII-only names and addresses? Or tell them that it's completely unavoidable that their name is shown completely mangled, or can't be entered at all?
mghie
You are quite simply wrong. Unicode is not important for all customers at all - if it were Delphi would never have become so widely used without Unicode support or survived so long without it. There have always been ways of handling non-ASCII. Unicode is only *one* such way, and it is far from being universally recognised as the "right" solution. Unicode is just one more character set among many.
Deltics
UTF8 is less expensive in terms of memory and a HUGE number of applications would be better off using UTF8. UTF32 is more efficient and easier to work with when processing normalised Unicode strings, and any application doing serious string handling absolutely should be normalising. Support for encodings other than UTF16 in the Delphi implementation is token at best. That is a choice that could have been made in the implementation and is not inherent to Unicode per se.
Deltics
And I wasn't arguing *against* Unicode, simply pointing out some often overlooked aspects.
Deltics
I understood that you weren't arguing against Unicode, I was simply pointing out that some of the aspects are of Borland's own doing. Re Unicode not being important for all customers - that's a common idea among people that have never seen or do not care about people entering their Turkish or Vietnamese name in a WIN1252 Ansi program. But go on in your ignorance, it's wide-spread, I read that even UPS isn't able to print proper international addresses with their software. As for "Unicode is just one more character set among many" - wise up or stop lecturing. You are quite simply wrong.
mghie
It's only ignorance if it's a false assumption. But it's not *always* a false assumption. For an ISV selling direct to specific customers, they *know* whether Unicode is essential or not for their customers, and *by definition* an ISV using Delphi 1 thru 2007 has customers for whom Unicode is not an issue. These days a far more common and absolutely false assumption is that successful compilation without warnings iN Delphi 2009/2010 == a "Unicode application". That is entirely and absolutely wrong if you have not undertaken much deeper and more extensive changes in your application.
Deltics
+1  A: 

Playing the devils advocate, there may be reasons not to upgrade. For instance you might be missing the source to certain components or you may still need to support Win9X.

I think you'll probably find the best reason to upgrade (leaving all the new wizz-bang features aside) is that you'll be significantly more productive in the new IDE. If you don't / can't upgrade I'd recommend grabbing a copy of Castalia, which can give you access to many productivity enhancements (e.g. refactoring) in Delphi 6.

Alister
+1  A: 

DBISAM is updated, I just emailed them this past week concerning a project I hope to be upgrading from Delphi 3 to Delphi 2010.

All the other packages I looked into upgrading for that project (WPTools, Infopower, TMS) all state on their websites that they offer compatibility with 2010.

I never had D2006 (I have 2007) so I can't speak to any defects in that particular release (D2007 isn't that great, either) but it's generally a good principal to keep your tools in good shape. For a saw that means sharp, for software that means current. Especially in a new-OS year, you probably want the corresponding version of your primary development environment.

Larry Lustig
A: 

Lists of compatible components that already support Delphi 2010 including DevExpress (article will be periodically updated from our technology partner database) is at

http://edn.embarcadero.com/article/39864

Argument - tens of thousands of tools and components available for the things you might need in addition to the open api(s) for components and the IDE.

+3  A: 

Don't convince him for a Delphi 2009/2010 upgrade, Do it for a Software Assurance.

Francis Lee
Thanks for the suggestion. I now created a new question: "Does it make more sense to upgrade to Delphi 2009/2010 or to buy Software Assurance?" (BTW, how can I add a hyperlink to it here?)
Pato Moschcovich
Just add it to your comment. http://stackoverflow.com/questions/1543959/does-it-make-more-sense-to-upgrade-to-delphi-2009-2010-or-to-buy-software-assuran
Bruce McGee
+1 for pushing the subscription model, which will (hopefully) lead to more stable incremental releases and fewer "big ticket" releases that take a couple of patches to settle down.
Bruce McGee
+1  A: 

It seems to me there are 2 aspects in developing professional applications:

  1. You want to earn money: you have to stick to your customer's demands, keep your stuff KISS, maintainable and so on... You have to be productive: no matter of generics, RTTI, widgets like flowpannel, gesture and so on because it takes time to learn and more time to use. In this way, change from D7 to D2010 is not nessary relevant. Change for another IDE like REAL Basic allowing multiplaform target is more accurate.

  2. BUT as a developer there is a child and a poet in you, fascinated by new technologies or/and algorithms... This is the creative part of the job. You got to be creative if you want to be impressive and innovator. Upgrade to Delphi 2010 is a must have, searching for new classes, new objects is a way of life in today's programming.

That's my humble point of view and the reason that keep me spend my money to upgrade Delphi from I to 2010.

Best regards,

Didier

Didier
If I were going to use a less capable IDE in favour of cross platform support, I would probably consider Lazarus before something like REAL Basic.
Bruce McGee