At my office, we are about to embark on an epic journey of converting an old Delphi 5 application to something more modern. One of our options is to convert to Delphi Prism, but we want to see what options are available to help us. So far, all I've found is Oxidizer (last worked on 2 years ago). Are there any other options for helping us convert reasonably quickly to Prism? Thanks.
-
Why are you trying to convert to Prism, as opposed to updating to a more modern version of native Delphi? That would certainly be far less of a headache. – Mason Wheeler May 11 '11 at 23:20
-
It might be less of a headache, but we want to be able to take this application as far into the future as possible, and going with a newer version of native Delphi is no guarantee that 5 years from now there will be any support. However, we're fairly confident .NET is in for the long haul, and converters from Delphi under .NET to C# are quite easy to work with later. There's other reasons for converting to .NET, as well, but that's one of the larger ones. – Tom A May 11 '11 at 23:24
-
I wouldn't be worried about that. I'm pretty active in the Delphi community and I know several of the Delphi team members, and IME there's no reason to doubt that Delphi will still be alive and under active development and maintenance 5 years from now. You'd really be better off saving yourself the headache. Prism is similar to Delphi, but it's different enough that what you're headed for is basically a rewrite anyway, which is the classic Thing You Should Never Do. – Mason Wheeler May 11 '11 at 23:36
-
@Mason: you left out one crucial part: "active development, maintenance, and mismanagement". It's hard for me to imagine: Borland started out by being the one vendor to offer a great compiler at a decent price. Now they're the only one who doesn't. Then we have the mind-boggling idiocy of taking a name as well known as Borland and changing it more often than a deadbeat trying to get out of paying child support. Sad to see a good product so thoroughly mismanaged... – Jerry Coffin May 12 '11 at 00:27
-
1@Jerry: Borland is dead, and they're no longer in control of Delphi. Embarcadero <> Borland. – Mason Wheeler May 12 '11 at 00:53
-
@Mason: Okay, maybe it's not a simple name-change, but the fact remains that a name that was well-known and respected was discarded in favor of one that nobody knew, and they seem to be doing next to nothing to get the name better known either. – Jerry Coffin May 12 '11 at 02:03
-
@Jerry: fair point. So what do you think they could do that would help improve things? (Realistic suggestions only, please.) – Mason Wheeler May 12 '11 at 02:25
-
@Mason: First and foremost, they should release an entry level version, probably named "Turbo Delphi", at exactly the $49.95 of the original Turbo Pascal. Second, buy some advertising space so people know it exists. I doubt "hire Phillipe Kahn as spokesman for a few weeks" qualifies as realistic... – Jerry Coffin May 12 '11 at 02:52
-
@Jerry, for what its worth, there is now a suprisingly complete 'entry level' SKU. Its still a tad expensive, but much better than expecting people to pay $800. Esp when you apply the academic discount to it. – GrandmasterB May 12 '11 at 04:49
-
@Jerry - there is a $US199 (or $149 "upgrade from anything") starter edition http://embarcadero.com/products/delphi/starter available, but it has some weird restrictions. – Gerry May 12 '11 at 04:51
-
@Mason: we're headed for a rewrite no matter what. We're in Delphi 5, can only find one or two companies that make any components for it, and can't get the components we need. Plus, to get up to date for using IPv6, we'd have to rewrite half the application because of the components that were chosen back in 2000. – Tom A May 12 '11 at 14:53
-
2Also to add my two cents in for the improvements to Delphi, I'd like to see Embarcadero stop treating Delphi like it's a side project. When I looked at the feature matrix for Delphi XE and Delphi Prism XE, I felt like I was looking at Visual Studio XP (2002). Embarcadero is a long ways behind other companies in the capabilities of the tools they provide, and it doesn't help that a lot of versions of Delphi kept getting ragged on for being buggy, bloated, and difficult to use (I've even seen comments for XE). Not trying to be mean, just honest. – Tom A May 12 '11 at 14:57
-
Bite the bullet and rewrite in .NET or Java - either way you will have a huge amount of resources like codebase example, commerical components, tools, add-ons, programming forums and general more online help, etc. and a much larger talent pool to pull from than Delphi. I loved Delphi and still use it on small projects (just got XE2!)- but for work (actually finding a job!) and resources, you need to either get on board with .NET or Java. Of course, if this is going to be a 100% winform app then Delphi XE 2 port could work - but I am betting you want mobile and/or web - then go .NET or Java! – MDV2000 May 22 '12 at 14:20
1 Answers
As many comments suggest and encourage, rewrite, yes. Why? Many of those reasons have been mentioned in comments, notably the declining degree of direct language and tooling support, 3rd party component support, but also not mentioned is a decline in available talent to keep the ship going. It is the same problem that many of the mainframe era and direct derivative projects face: talent and interest in those types of systems is waning.
One of the biggest challenges for a migration effort isn't what language or platform or toolset to go to, especially today: there are lots of good options, some better than others depending on what one is trying to accomplish and expect from the resulting effort. Today the biggest challenge, as it has been for years, is finding the right talent to translate the old system into the new, or at least translate it well enough and efficiently enough for others to build in the new.
In the OP's case, it sounds like that they have not only skilled practitioners in not only the legacy language and tooling, but also to a degree are highly familiar with the customer and the domain. That is a big advantage.
What I suggest, based on my experience with genuine legacy migration projects, is take a bigger jump while there is expertise on the originating end. It becomes monumentally harder when those builders and maintainers leave.
System usage and stability assessment. Is the system doing the things the customer needs, no more and no less? Are their particular pieces that can be isolated to a degree? Are there pieces that have plagued development because they are prone to breakage or get frequent complaints about? Are there pieces from the user's perspective that are missing (use cases that would fit the system scope that haven't otherwise been identified)? And so on...
Use that information from the usage and stability assessment to initiate a spin-off, incubation project for coming to a more mainstream platform that tooling and training will be plentiful for in the foreseeable future. Use a mix of architecting/re-engineering and straight porting to get off the ground.
Prove out the new pieces using phased, selective deployment to users.
Evaluate progress to effort spent.
Ramp up migration if everything is going as planned.
EDIT:
Personal recommendations:
C# on a Windows or web platform as it provides familiarity in a lot of ways to Delphi, and it will be the draft horse of Microsoft for a while.
Possibly a foray into mobile. It depends on what the customer needs and wants as this could change how I would prioritize it. One of the things the ThoughtWorks Radar suggest is many companies are moving to a mobile-first strategy for new projects. I personally would be most inclined to suggest the route of Android if looking at native apps, primarily because it's pervasive, but also in OP's case, mobile Java would be a fairly comfortable transition from Delphi. Google is definately not going away from this anytime soon.
Ada. Just kidding.
Possibly Python or Ruby. I am somewhat agnostic about both, but they certainly have some merit.

- 3,306