Question: which is best for cross-platform, managed code using a runtime such as Java, .NET, or Flash, or is it native code? When Java arrived in 1996, Sun promoted write-once-run-everywhere as one of its key benefits. The arrival of just-in-time compilers for all the runtimes mentioned above removes many performance concerns. So is managed code the best solution?

My assumptions about this were challenged when I spoke to Embarcadero's CEO Wayne Williams last week. His company is the one that now owns Delphi and C++ Builder, the RAD software development tools, after acquiring Borland's Codegear division last year. Williams told me that taking Delphi and C++ Builder cross-platform is now the top priority for the team working on those products. Concerning native code, he said: "It's crystal clear. If you want a small, fast, GUI-rich application, and you want to target the popular platforms, there's only one game in town." That means at least x86 code for Windows, Mac and Linux, and he added, "there's no reason mobile devices shouldn't be on that roadmap as well."

What's wrong with Java then? "There's always been two approaches to target multiple platforms. One is interpreted, where you shield the code the developer is writing from those differences. The Virtual Machine is responsible for that, and if you want to add another platform, it's all centralised. It's easier, but the result is poor, it's a least common denominator approach.

"It's a bigger investment and it's more difficult to cross-compile, where you natively target these platforms, but the end result is much better. You're running true native code with full access to whatever hardware there is on that platform."

It was like going back in time: I recall similar arguments about Java back in the nineties. Since then, we've had not only JIT compilers but also huge increases in hardware performance. Is Williams living in the past?

Before dismissing what he says, it's worth noting that native code has never gone away. I use cross-platform native code applications all the time, from the SQLite database engine to the Audacity sound editor, and I enjoy their small size and fast performance. Over at Google, the Chrome team is hard at work delivering a new web browser, and it is mostly written in C++. Most of Windows is written in C++, despite Microsoft's commitment to .NET; and Java is an afterthought in Apple's OS X.

Although hardware performance has improved, the increasing numbers of mobile devices with constrained resources is a counter-balance to the idea that hardware takes care of inefficient code; and although managed code is fine for many business applications, it's hard to quibble with Williams' contention above that "If you want a small, fast, GUI-rich application, and you want to target the popular platforms, there's only one game in town."

There is another argument for managed code, which is that applications are quicker to write and safer to run when they are under the control of a runtime virtual machine. That is generally true as well. Still, Delphi does a great job of hiding the complexity of native code development. It may be just a little anachronistic, but if Embarcadero successfully deliver a cross-platform Delphi compiler, I think there will be plenty of take-up.

Williams says we may see cross-platform Delphi as soon as next year.

Ever since .NET burst onto the scene back in early 2002, Microsoft has promoted it as the primary platform for custom applications. For sure it has plenty of advantages, including automatic memory management, a modern programming language called C#, and a rich class library encompassing both Windows and Web development. The Windows Presentation Foundation, touted as the next generation of the Windows user interface, can only be programmed using .NET.

Unfortunately .NET also has downsides. The first is potentially troublesome deployment, thanks to the large runtime required. The problem has not gone away even though Windows now comes with .NET as standard, since new versions appear regularly. The second issue is performance. Although a just-in-time compiler enables .NET code to run at near-native speed, there is still a heavy memory overhead. The result is that .NET applications generally load and run more slowly than native code equivalents.

The trade-off here is that ease of programming compensates for slower performance. It's true; but not all developers realise that the choice is not only between C# and Visual Basic on the one hand, and the intricacies of Visual C++ on the other. Before turning up as Microsoft's chief architect for C#, Anders Hejlsberg worked at Borland on a language called Object Pascal and a development tool called Delphi. There is some family resemblance, particularly if you include Delphi's Visual Component Library (VCL), which wraps the Windows API with a class library that is equally as capable as the Microsoft Foundation Classes, but much easier to code against. Unlike Microsoft's .NET tools, Delphi compiles directly to native code, and it is feasible to create applications that have zero dependencies, run like lightning, and work on versions of Windows right back to 2000.

Delphi's recent history has been unsettled. Borland delivered some unsuccessful .NET editions and messed with the IDE. The Delphi side of the business was then spun off into a separate entity called CodeGear, which was recently acquired by Embarcadero, best known for database design tools such as ER Studio. Fortunately the compiler remained as good as ever, and the signs are that Delphi's new home will be good for the product. The company has just released Delphi 2009, the first version with proper support for Unicode. A companion product called C++ Builder has the same VCL, but uses C++ in place of Delphi's Pascal variant. These releases also introduce language enhancements including generics and anonymous methods.

Delphi is not the answer to every software problem, and its documentation is poor compared to what you may be used to with MSDN, but in the right context it works like magic. Aside from .NET, every corner of the Windows API is open to it, including services, native code DLLs, COM components, and fiddly software like custom actions for the Windows Installer. The Delphi IDE is once again mature. If you have ever looked with horror at the tens or hundreds of megabytes demanded by .NET for your small Windows Forms utility, or found yourself troubleshooting some obscure problem installing the .NET Framework, Delphi is well worth investigating.