If you had a differential of either venturing into Delphi land or Qt land which would you choose? I know they are not totally comparable. I for one have Windows development experience with Builder C++ (almost Delphi) and MFC (almost Qt), with a bit more time working with Builder C++. Please take out the cross platform ability of Qt in your analysis.
I'm hoping for replies of people who have worked with both and how he or she would compare the framework, environment, etc.?
Thank you in advance for your replies.
If you are talking UI frameworks, then you should be comparing Qt with the VCL, not the IDE (Delphi in this case). I know I'm being a stickler, but Delphi is the IDE, Object-Pascal is the language, and VCL is the graphical framework.
That being said, I don't think there is anything that even comes close to matching the power and simplicity of the VCL. Qt is great, but it is no VCL.
Edit: This answer was written in 2008. It probably is no longer so apt, though probably it is not entirely useless. Take with salt.
I have used both and have ended up going the Qt route. These are the reasons:
Trolltech offer quick and one-to-one support via email
Qt innovates, and introduces powerful new features regularly
The Qt documentation is amazing, and in the rare cases where it isn't, you can read the source code
Having the source code for Qt also allows you to debug inside your base libraries, which has been a life saver for me on many an occasion
The API is very consistent and well designed. We have put new people on the project and within a month they show deep knowledge of the toolkit and can learn new classes very quickly
It has bindings to other languages, eg. Ruby and Python.
C++ is somewhat of a downside, eg. compile times, packaging, and a less integrated IDE. However Qt does make C++ feel more like a higher level language. QStrings take all the pain out of string handling for example. Thus the additional issues with C++ that you would normally face, eg. more buggy code, are less prevalent in my experience when using Qt.
Also, there are more libraries for Delphi than for Qt, but this is mitigated due to the fact you can just use a c or c++ library in a Qt project, and also because Qt is so fully featured you often don't have to look any further.
It would be a strange situation where I would choose Delphi over Qt for a new project.
I would pick Delphi. Of course you ask any pascalholic and he is sure to answer just the same. ;)
Qt again is fine, but the VCL just feels more polished. But then that could be my years of working with it so it just feels right. My experience with Qt was limited to a short lived project that ended up being rewritten in Delphi after it was determined that cross platform was not really needed thanks to the power of GoGlobal which can make any win32 app a web application, and therefore run on any platform.
It really depends on your needs and experience. I have worked with both (though have to say that the last Delphi version I really worked with was Delphi 6, and I'm currently working with Qt 4.4).
The language
C++ pros:
C++ is more "standard", e.g. you will find more code, libraries, examples etc., and you may freely use the STL and boost, while Object Pascal is more of an exotic language
Qt compiles on different platforms and compilers (Kylix is based on Qt, BTW)
Object Pascal pros:
some dynamic properties are build right into the language, no ugly workarounds like the MOC are needed
the compiler is highly optimized for the language and indeed very fast
the language is less complex than C++ and therefore less error prone
The IDE
Qt pros:
Strictly spoken, there is no IDE for Qt besides the Designer, but it integrates nicely into your preferred IDE (at least Visual Studio and Eclipse)
the designer does a better job with layouts than Delphi forms (Note: this is based on
Delphi 6 experience and may not be true with current versions)
Delphi pros:
The IDE is really polished and easy to use now, and it beats Visual Studio clearly IMO (I have no experience with Eclipse)
there is no point 2... but if I had to assign the buzzword "integrated" I would assign it to the Delphi IDE
The framework
I will leave a comparison to others, as I don't know the newest VCL good enough. I have some remarks:
both frameworks cover most of the needed functionality
both have the source code available, which is a must IMO
both have a more or less consistent structure - I prefer Qt, but this depends on your preferences (remark: I would never say that Qt is almost MFC - I have used MFC for a long time, and both Qt and Delphi - and .NET, for that matter - are way better)
the VCL has more DB-oriented functionality, especially the connection with the visual components
Qt has more painting (2D / 3D / OpenGL) oriented functionality
Other reasons that speak for Qt IMO are the very good support and the licensing, but that depends on your needs. There are large communities for both frameworks,
A big difference between Delphi and Qt is the Qt signal/slots system, which makes it really easy to create N-to-N relationship between objects and avoid tight coupling.
I don't think such a thing exists in Delphi (at least there was no such thing when I used to use it).
I just started experimenting with Qt/C++/Qt Creator and I must admit I was surprised that this "little cute bastard" was just below my nose for some many years and I pay attention to it just now.
It (the framework) looks neat, feature-complete (even was stuff that .NET lacks such as inbuld XQuery support).
Seems that most of the Qt applications written are dealing with 2D/3D/Games.
I believe the downsides are only: having to know C++ and the lack of DevExpress goodies like QuantumGrid.
I am seriously considering porting one of my simple applications (a picture viewer like ThumbsView).
And it REALLY runs from same codebase. FOR REAL!
Forget about Kylix, Mono, Lazarus, Free Pascal. This Qt thing beats them all in 10 times.
Qt Creator is far from IDE. But I hope in the future they will add a more powerfull debugger, code insight and refactoring (at least the "Rename" one) and more meaningful compiler errors.
I would seriously recommend to someone without experience in Pascal/C++ to take the Qt learning curve.
I would pick Delphi, but that is probably because I have programmed it before. It seems there are still a number of companies which use it, and almost everyone who has 8+ years expierence has encountered it somewhere. It seems that most programmers can relate to using it or at least learning Pascal. Not to mention the fact that newer languages (C#) are based on it (at least partially).
Pick Delphi if your concern are native Win32 speed, a first class RAD environment and executable size. Pick QT if you need a truly cross-platform framework coupled with a now-flexible licensing policy and don't mind slightly bloated code.
I ported an old Delphi program under QT/C++, and I must say that QT is the framework that comes closest to VCL in terms of ease of use and power (IMHO)
I'd choose delphi. Only because I have more experience with it. I don't think that there is other reasonabl criterias.
Qt is cross-platform, Delphi not much if we count Kylix. Lazarus is cross-platform, but not quite feature-complete yet.
Related
I'm a teen who has been programming since 8 years old, so I know what I do.
I want to take a look at Delphi Windows development.
The problem with this, is that Embarcadero's Delphi is really expensive, and I can't afford it.
I wanted to know if Lazarus is a good alternative, now for learning and hobby, but in a few years for working.
If I learn Lazarus now, would I know Delphi also ? Do I need to learn Pascal first ? Any good Lazarus books ? If I learn Lazarus from a Delphi book it's ok ?.
Thanks.
Some things to be aware of:
The component library for lazarus, the LCL is similar in many ways, to the VCL library for Delphi, but there are differences, the biggest being the many components in the VCL that are not in lazarus. As a means of learning Delphi programming, this seems to me to be the biggest shortcoming.
The IDE for Lazarus is similar in many ways to the Delphi 7 IDE (and older versions) and looks nothing at all, and works nothing at all, like modern Delphi IDE versions. So your learning of Lazarus would be somewhat transferable to the now-ancient version Delphi 7, but wouldn't be of much use in knowing your way around the delphi IDE. Installation of packages works completely differently too. Delphi has true support for packages, whereas lazarus rebuilds and relinks itself in order to add more "designtime components" to itself.
The base languages are also almost identical, but I would expect to find some strange differences. There is some brief description of the differences on Wikipedia.
I agree with Kico; The delphi starter edition is not expensive.
there's a version of Delphi called Embarcadero Delphi XE Starter Edition, which have a very good price (free I guess).
I can't recommend Lazarus as a good option for learning Delphi because besides the languages are basically Pascal, they have some differences which could confuse you.
Here is the link for the old Turbo Delphi project (which became the Delphi XE Starter Edition) where you can download your copy.
There's already lots of views on this so take your pick. Mine for what it's worth, is that learning a language and more specifically HOW to program is the most important aspect. I know many skilled programmers who can and do use a multitude of languages - C, C++, Java, Ruby, Python, PHP, Delphi and so on. They all say to me that once you learn and are good at the fundamentals of a while loop, a for loop, and so on, applying that to a new language is easy enough.
I have not produced loads of software but I've achieved more in the last year using Lazarus and Free Pascal than I ever did with any other language - Python and Delphi included! I can easily create cross-platform GUI's that run on all OS'es with powerful procedures that I couldn't make with Python and\or Delphi. I am not saying they couldn't be made with those languages, but I was able to make them easily and quickly with Laz+FPC.
So, personally, even if I could afford to buy Delphi, I'd use Lazarus. I don't see that Delphi offers me, at my level, anything significant over and above Lazarus. So at your level and age, I'd say learn everything you can and when you outgrow Lazarus (if you ever do) move on to DELPHI. The interface transition will be easy enough once you know the language.
If you are still in school, you should check to see if there are educational discounts for Delphi
Primarily I think that you should let yourself be guided what your immediate surroundings use. The people on the forum you intend to frequent, friends, coworkers/students, whatever they use should be an important factor in what you do. Since they are the ones you will ask questions, exchange source etc.
They might be using older versions of Delphi, Lazarus or the newest of the newest Embarcadero version. E.g. for my work, I visit electrical engineering departments a lot, and they uniformly use a Delphi 6 or 7. And if not, usually older rather than newer.
If you are gearing up to do a bit of side jobs with Delphi you have a problem. You can buy starter to learn, but as soon as you start asking money for it, you have to acquire a full license(*), and the starter license is money lost. Specially since Embarcadero recently limited the period that old versions might upgrade, you might not even get a discount on the full version because of an older starter purchase in a few years.
Besides being free, Lazarus, for educational purposes has one big advantage: the number of versions in active use is usually limited to the last two releases. This reduces versionconflicts and at worst versionitis is only temporary. This means all your peers will more or less use the same version, while with Delphi they might be scattered over more than 5-6 versions.
And of course updating lazarus is also free :-) (which is important to consider in a multi year planning, the same people urging you to buy now will urge you to get the latest and greatest in a few years too)
Personally, I think that Lazarus is fine for the initial learning and that differences that really would be a stumbling block are much further down the track. And you get a VCL/LCL path to other platforms. You can always get a Delphi version later when plans are more concrete. (either to find employment, or if you start being a self employed programmer)
(*) luckily, if I understood it right, the starter edition now allows non commercial use in foundations.
I have inherited a legacy app written in C++ (VS2003) MFC that was not updated in years.
I have limited experience in C++, being mainly a Delphi developer. All other apps of the company are written in Delphi.
Going forward, I see a few choices:
1) Keep the app as is and become a C++ MFC developer. But I don't like the idea of using an outdated technology (MFC) for years to come, trying to keep up with new Windows versions and UI standards. It somehow feels like making several steps backwards and I don't think this is the best way to go (?)
2) Convert the app to any modern UI technology offered with C++ and become a C++ developer, but at least using modern technology. Might be a lot of work, not sure.
3) Rebuild the app from scratch in Delphi, where I will be a lot more productive thinking about the future. It's a lot more work right now, but it might pay off later.
Obviously, I personally prefer 3) but I would like to know from your experience which way is the best for the product.
It's a long term decision to make and I will have to stick with it, therefore I don't want to rush into one direction.
(I have intentionally not tagged this question as C++, trying to get answers from Delphi developers in similar situations)
EDIT:
Thanks to all for your answers.
After learning that it is possible to switch to C++ Builder with a MFC application, this seems to be the best solution.
It combines the least amount of modifications to the current app with the possibility to go forward using the VCL for future GUI improvements.
EDIT2:
It's not possible to combine MFC and VCL in one app, therefore C++ Builder won't be an option. (thanks David for pointing this out)
In general everything depends on how complex the application's logic is and what is the projected life time of the application. If it requires maintenance for another 20 years, then
I'd rewrite the UI in Delphi and move the business logic into C++ DLL (for beginning and possibly rewrite it in Delphi either). Then it can turn that the application can be maintained this way for another 10 years and relatively easily ported to other platforms if needed (less work would be required).
This is a hard question to answer generically. Can you provide any more information about your specific app? What sort of technologies does it use? How separated is the UI from underlying layers and logic?
Some general-ish points though:
Rewriting an app is generally a bad idea, for the following reasons:
It's surprisingly hard to get an accurate idea of the requirements. You're sure you know what it does (after all, it's right there in front of you!), but then you release your rewritten app and you get complains that functionality you didn't know was there is missing, that functionality is harder to access if you've changed something, etc.
It introduces bugs. The code, especially if it's old, is full of bugfixes, tweaks, etc. You will lose all that if you rewrite, especially if it's a different language and you can't reuse any code at all.
When using a different UI layer (MFC to something else) separating the UI can be very hard if the app wasn't written well in the first place. You will probably end up doing a lot of refactoring, even if you don't do a complete rewrite and simply move from MFC to 'something else'.
MFC is kept up to date (ish) - there is a MFC Ribbon control, for example, as well as modern controls and Windows 7 support. The least amount of work, probably, would be to upgrade to a modern version of Visual C++ and become a C++ developer. However, you're quite right that MFC is an old technology and is unpleasant to use, not only because of its design, but also because modern form designers etc are great to use.
You're a Delphi developer. Without rewriting the entire thing, you could consider migrating to C++Builder. Consider this:
You can use old versions of MFC with C++Builder. I've never done this, since the VCL is miles ahead, but it's possible and there are a number of people who do it. Check out this forum, for example. (Credit for that link: this thread.)
Once you have your app compiling and working with C++Builder, you can start migrating to the VCL. As a Delphi developer you'll find using this, even with C++, very familiar. It's the same form designer of course, and using it from C++ is pretty simple - it's a different language but code is often line-for-line translatable. Everything you're used to (DFM files, units, event handlers, etc) all translate.
Not only that, but Delphi code can be used in C++ projects. Just add the units to the project, and in your C++ code include the auto-generated unitname.hpp file. You can't (easily) use C++ code from Delphi, but you could create new modules in Delphi and use them from C++. As you do this, more and more of your app will slowly become Delphi code - ie, you don't need to rewrite in a different language all in one go.
As a Delphi developer, I'd suggest going the C++Builder route. Get it working with MFC, and then migrate your windows to the VCL. At that point, you could start rewriting modules in Delphi, or you may find yourself comfortable enough in C++ to continue developing as is.
Edit: I noticed in a reply above you like the idea above of making it a C++ DLL. The link I gave a paragraph or two above of using C++ object from Delphi might be more applicable than I thought. It would fit the RAD Studio (mix of C++ and Delphi) method as well.
Keeping the app as is, tying you to MFC, is likely not very productive - You'll need to learn a GUI toolkit you'll most likely never use for something else (Delphi is great for GUI, MFC doesn't even come close IMO), in addition to a new language.
That leaves you with the choice of rewriting it in a somewhat unfamiliar language using an unfamiliar GUI toolkit, which'll take a lot more time than rewriting it in a familiar language using a familiar GUI toolkit. So you should just get started porting this to Delphi.
Rewriting C++ code in Delphi isn't as easy as you think. A better way to rewrite it is by just redesigning it from scratch, without looking at the old code. Feel free to look how the old application worked, so you can rebuild it. Just don't look at the code. That way, you should get a more modern result.
Of course, if you use the RAD Studio then you have both the C++ as Delphi compiler, thus it should be able to continue to develop the C++ application, although this means you have to learn C++. Then again, any good programmer should be able to just move to another programming language and learn to use it within 2 weeks to a month. C++ can be complex but still, learning C++ and then maintaining the legacy app should take a lot less time than a complete rewrite.
Do keep in mind that any generic C++ application should be able to be compiled for any platform, although the MFC will probably restrict this to just Windows. Still, it's a language that has an even better backwards compatibility than Delphi!
But to keep in mind, will this app run on a different platform in the future? Should it become a .NET application? Or run on Linux? Should it support tablet computers? Android? Your choices today might be outdated again in two years. And since Delphi has a bit uncertain future right now, mostly because C#/.NET became so popular, you might have a more safe bet with C++. Try to replace the MFC libraries with a more modern UI technology, preferably one that's available for multiple platforms, and think very, very well about the future usages of this application.
In general I'd say:
If it's a tiny tool application, and it takes just a couple of days to do a full rewrite: go for it. Don't waste your time creating dll wrappers or to interface with the existing code in other ways. Just do a full rewrite and be done with it.
Otherwise: you'll probably be making changes in one specific area of the application at the time only. Unless the code is a complete spaghetti, you could even get away with making some local changes without fully understanding the implementation details of the rest of the code.
In any case, you need to invest some time into understanding the application and its language + frameworks.
You have a great opportunity to learn C++ and MFC. Take advantage of it. When Delphi goes astray you will have the required knowledge to keep on coding with a language that won't go away so easily, and you can even broaden your development horizons to areas Delphi (and C++ Builder) will never reach. MFC is no more outdated than the VCL is (although I agree the original design is worse).
Good UI programming has nothing to do with the ability to drop controls on a form visually. Many great applications are not built that way. Actually, trying to rewrite it in Delphi could bring you issue in the future, as long as Embarcadero delivers slowly, and without a credible roadmap.
I recommend
1) Keep the app as is and become a C++ MFC developer. But I don't like the idea of using an outdated technology (MFC) for years to come, trying to keep up with new Windows versions and UI standards. It somehow feels like making several steps backwards and I don't think this is the best way to go (?)
Since MFC is well supported and keeps going with the time. MFC is also a what-you'd-call intrusive framework, meaning that the framework dependencies are usually not easily refactored. (The author of CPPDepend published some nice stats on that IIRC, but I can certainly vouch for this from my own experience with large MFC applications).
If you're gonna rewrite to any modern UI framework, don't code the UI in C++ (judging from the fact that Delphi is an option, it is not about realtime visualizations or something like that).
(I'll unask the unasked question here: I you're gonna rewrite, XXXXXXXXXXXXX?) please gentle(wo)men, let's not do the flame
Does the app come with a descent amount of automated tests? If not you're pretty much stuck with option 1 and hope for the best. If there are many tests you can do a lot more with the code without breaking all kinds of things you didn't know were there.
I used to use Pythia to obfuscate my D6 program. But it seems Pythia does not work anymore with my D2007.
Here's the link of Pythia (no update since early 2007) : http://www.the-interweb.com/serendipity/index.php?/archives/86-Pythia-1.1.html
From link above, here's what I want to achieve
Over the course of time, a lot of new language features were added.
Since there is no formal grammar available, it is very hard for tool vendors (including Embarcadero themselves) to keep their Delphi language parsers up at the same level as the Delphi Compiler.
It is one of the reasons it takes tool vendors a bit of time (and for Delphi generics support: a lot of time!) to update their tools, of they are update at all.
You even see artifacts of this in Delphi itself:
the structure pane often gets things wrong
the Delphi modelling and refactoring sometimes fails
the Delphi code formatter goes haywire
Pythia is the only obfuscator for the native Delphi language I know of.
You could ask them on their site if they plan for a newer version.
Personally, I almost never use obfuscators for these reasons:
reverse engineering non-obfuscated projects is difficult enough (it would take competitors long enough to reverse engineer, so the chance to lessen the backlog they already have in the first place is virtually zero)
their added value is limited when you have multi-project solutions (basically they only hide internal or private stuff)
they make bug hunting production code far too cumbersome
--jeroen
You may try UPX - Ultimate Packer for Executable). It will compress the resources and all the text entries are non-readable without de-compress first.
I don't know any good free solutions, but if you really need some protection you can always buy something like:
http://www.aspack.com/asprotect.html
or
http://www.oreans.com/themida.php
If Delphi is the primary language for my development, what is the ideal complement to Delphi.
which should be my next step?
C# for .net and web development
Java
C++ for Know Win32 in depth.
Ruby
Perl
What is your recommendation?
I would recommend HTML, CSS and JavaScript. This sounds like a bit of a strange suggestion when asking for programming languages, but the Web is taking over. Delphi has had the TWebBrowser component since ages, and there are a few alternatives that offer even more features and ways to have HTML rendered onto the forms of your Delphi applications. I have found, when applied in a number of complex situations, it has saved me a lot of work and code.
(To be completely honest, though. I'm suggesting this because I'm trying to blend web-building with Delphi with the xxm project)
My recommendation is C #, but before Getting started with Delphi Prism, the learning curve will be so much easier. Learning a .Net language is going to greatly expand your horizons and types of applications you develop. .Net has a lot of technologies where you can deepen WPF, SilverLigth, WCF.
Delphi Win32 - > Delphi Prism -> C#
Python. It'll take what you've learned in Delphi and allow you to generalize it further.
In addition to Delphi, Embarcadero also sells the RAD C++ development environment.
It uses the same IDE as Delphi so you won't have mix yourself up by learn a new IDE, just a new language.
And you will be able to mix and match Delphi and C++ as you want in the same projects.
In fact, by purchasing (or upgrading to) Embarcadero RAD Studio, you'll get Delphi, C++Builder and Delphi Prism (the .NET tool) all in one.
So C++ seems like the most natural fit and a very logical choice.
And if you want .NET development, don't use C#. Use Delphi Prism.
I will look not for a language, but will think what application technologies to learn and what to develop next. IOW, I will continue with Delphi. Why I have to change it ?
It depends what you want to achieve. I've recently been learning Ruby and Rails (framework) do develop a website and it's been a fabulous learning experience. The wide community of OSS gems and plug-ins means I get a lot more done a lot faster than with Delphi. (And I've also found areas where Delphi beats Ruby too).
Whatever language you choose it should be something with a different 'personality'. What I mean by that is that languages like Deplhi, C++, BASIC and C# all come essentially from the same roots with very similar philosophies. Choose a language like Lisp, Ruby or Haskell which will teach you to think about your coding in a different way.
It just depends on what kind of applications you need/wish to target beside Win32 native ones Delphi targets.
C#: good if you need to use Windows managed features or need asp.net. IMHO, forget Mono.
Java: good if you need to target "managed" non Windows development, especially in some enterprise environments heavily Java based.
C++: if you need to go beyond some Delphi capabilities, and/or target non-Windows platforms natively. Plain C should not be ruled out, can be useful for some advanced develpoment, i.e. kernel development or drivers.
Ruby, Perl, PHP, Python, etc: each have their pro and cons for scripted applications. Ruby and PHP are IMHO better to target web applications when multiplatform is a need, while Perl is a good language to perform heavy text processing in a lot of differnt situations, and Python being a good general purpose tool.
I went from using Delphi pretty much exclusively to using Ruby on Rails, and love it. RoR is to web development what Delphi was to Windows development. It provides a language (Ruby), a framework (Rails) and a whole bunch of code generators to do the heavy lifting for you.
I started a blog some time ago called Delphi to Rails which kind of went through my own experiences making the switch. As much as I enjoyed Delphi, I enjoy Ruby way, way more. It's a strange language at first, but once you've figured out the basics it's super cool, and really fun to program in.
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.
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. )
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
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.
Don't convince him for a Delphi 2009/2010 upgrade, Do it for a Software Assurance.
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.
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!
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.)
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.
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.
It seems to me there are 2 aspects in developing professional applications:
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.
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
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.
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?