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.
Listed below are links to blogs that reference this entry: Native code makes a comeback - except it never went away.
TrackBack URL for this entry: http://www.itjoblog.co.uk/blogadmin/mt-tb.cgi/100
Native code and managed code each have their relative advantages, and some tasks are more appropriate for one than the other. The cross-over point shifted to favor managed code as CPUs got faster and JIT compilers increased their efficiency.
Thus, the market for native code tools -- Embarcadero's market -- has been declining. Nor does Embarcadero have any advantages for competing with Microsoft in .NET's managed code world, nor does it make sense to re-invent itself as a Java tool builder. Embarcadero's only real hope is to expand the native code market at the expense of .NET and Java. One way of doing this is by offering cross-platform languages and tools that compile to native code.
Though cross-platform native code sounds like an oxymoron; theoretically, one could create a tool set for based on cross-platform source code that compiles to native code on a variety of platforms. This will be difficult, but it's Embarcadero's only hope. If they succeed they will shift the cross-over point in favor of native code -- thereby enlarging the market for their products.
The tendency of cross-platform GUI tool sets to use lowest-common-denominator widgets is the same whether one uses managed or native code. A widget based on one platform's native code will not be native on the other platform. But if Embarcadero's GUI widgets run natively on Windows and can also run (albeit more slowly) on Linux/Unix/Apple, there will still be an advantage over using .NET or Java -- at least for those applications that make it worth having to deal with one's own memory management. At the very least, Embarcadero could consolidate unto themselves the current market for C/C++ tools, and perhaps they can expand that market.
We saw multi-platform Delphi a number of years ago in the form of Kylix which was abandoned by Borland.
@Andy
Of course I asked Williams about Kylix. I quoted his response in this piece on the Register:
http://www.theregister.co.uk/2009/06/12/embarcadero_codegear_tools_future/
Tim
There's much more difference between C++ vs Java (or C++ vs C#) than simple native vs JIT. We're talking about the wealth and maturity of libraries, the managed memory (vs new and delete), and popularity. How easy is it to find new C++ developers when yours quit and go to Google ?
In Java world, performance is good enough that the rage is all about new languages that will make developers more productive. I don't really see more productivity in going back to C++.
No, I don't see many people going back to C++. But a version of Delphi that compiled Object Pascal to native code in all the major platforms might expand the niche (especially when programming for cellphones and the like). Especially if there were an easy way to interact with device drivers written in C.
Your next platform should be Win64 - that's where we *must* port our applications ASAP. On Linux we already deploy 64 bit applications (written in C/C++), MacOS it's not a target by now, it could become - if and when Delphi shows it could build good MacOS applications.
But if we don't get Windows 64 bit ASAP, the day we target MacOS we won't be using Delphi anymore.
"...We're talking about the wealth and maturity of libraries..."
Well Delphi has an extensive *and* mature libraries for years before .Net, don't be surprised that the .Net libraries are an offspring of Delphi VCL, or at least a brother (they share the same father). Truth must be said .Net Framework had more milk (MS green one) on its childhood.
Its easy to move from Delphi to VB.Net or C#, but its also really easy to move back from them to Delphi. And you will get the speed of native apps, *super* easy deployment, and a superb devel experience.
What's the point on using .Net?
NET is multiplatform. Well, there are multiplataform .Net apps, but at the heart, the only platforms supported by MS are MS platforms, Mono is more like an experiment, very nice, very polished, but still an experiment.
NET is easier to deploy. Easier than what? a messy VB6+COM apps? dll Hell? Yeah .Net is easier. But by no means it's easier than a Delphi app. With Delphi, if you want, you can run directly from a USB stick, no 100' of megas to be installed to play reversi. And you say: .Net Framweork is preinstalled, and I say: so is it multiplatform yet?
Delphi delivers a much more smooth experience for developers *and* for users, not only because it's native but also for it's mature and large library, and it's appeal can now be even better when it gets the native cross compiling ability.
@Tim. I remember a "promise" from Wayne Williams at the time of the CodeGear aquisition that Embarcadero would ensure the existing roapmap would be delivered before they went off at any tangents. It seems a fait accomplis that multi platform will be delivered next, but Wayne and Embarcadero at large should be at least questioned about their handbrake turn and the resulting damage it is causing.
As you may be able to tell, I totally agree totally with Luigi. Win64 should be the next platform targeted. Keep your existing base satisfied before looking for new and unproven markets. Delivering Unicode and the soon to be released "Weaver" / eye candy is not enough. The lack of Win64 support is a festering wound that is turning ceptic.
For those complaining on Win64 and multiplatform, you should remember a post from Nick Hodges when all this started.
To have Win64 compiler they need a cross compiler solution in place. What? You have to think on Win32 and Win64 as different platform targets, thats the point. In the process they are creating a solution that can be expanded to more targets aka OS and Linux.
As I see, and i'm not and EMBT employee only a Delphi fan from the other corner of the world, if we see a cross compiler release of Delphi I wouldn't expect a full GUI app compiler, only for console apps.
Why? Its easier to have a simple console only cross compiler for Linux and Mac than a full Win64 port. What??!! yes, i guess, and it's my personal guess, only rtl and some vcl units will be usable on the first release for OSX/Linux. BUT the first release for Win64 will be (must be) full, with all those 64 enhancements people are requiring.
We have to thanks EMBT they are putting more resources on Delphi than CG or Borland before, Delphi have now multiple parallel projects that will take Delphi to the map again.
Again its my guess, and i'm only a Delphi fan from the other corner of the world
I'm a Delphi fan since the Delphi3 came up.
And it was not the language nor the compiler that won the harts of the developers. It was the IDE and the VCL framework, the component model, the package model.
The real problem is that VCL is too much tied to the Windows API like the most of the Delphi 3th party components. So what's the use of having a multiplatform Delphi compiler when I would need to completely rewrite my legacy applications ?
These days when more and more development is moving towards web, clouds and virtual platforms, the native code compilation seems to start loosing its place in the UI applications.
Cross-platform compilation of one application has always been a red herring. Almost all the software written only needs to run on one platform. For the small minority for which cross-platform portability is required, if you have a GUI, then forget it. Your app is going to look crap everywhere. If you make heavy use of OS calls, forget it - all the OSes around are too different for that to be easily portable. There's a reason Chrome for the Mac is so far behind Chrome for Windows - it's NOT just a matter of recompiling the code.
And as for wanting to compile desktop or server apps for mobile devices, that's just a stupid idea. Those devices have contraints which make desktop/server apps completely inappropriate. You need to start from scratch anyway.
Since virtually nobody needs cross-platform compilation, making it a selling point seems silly. You would think the Kylix and .NET debacles would have made that clear by now.
If Embarcadero want to make a MacOS dev tool, or whatever, then that's up to them. Doing it whilst tying one hand behind their back in the name of cross-platform portability seems dumb.
Also people, since the advent of JIT compilers, some managed code (like .NET for example), actually is native code when it's running, making performance another red herring. I can't believe people are still on that old saw.
We know that going 64 bit means to enable the IDE and the compiler to target more than one platform as it does actually. And we will welcome a new, improved compiler - the Delphi one has been showing its age for years. That said, why targeting Linux and Mac *now* should be more important than delivering Win64 as the first "multitarget" platform?
Face it: most Delphi developers are Windows developers. Most of their customers are Windows users. Actual application can be moved easily to Win64, but may require deep changes to be ported to very different operating systems (and there are many 64 bit Linuxes out there...). The same is true for third party libraries - and that impacts porting a lot.
If there was a 64 bit Delphi, we'd upgrade right now. If the next Delphi doesn't deliver 64 bit but 32 bit Linux and Mac, well, we'll just sit on the fence and watch what happens - no upgrades, we don't need it right now - *when* and *if* Delphi shows it could be a good multiplatform solution, and libraries are ported, we could be interested.
Meanwhile we have to find a way to support 64 bit Windows - and Delphi is later and later. Kylix and .NET stalled Delphi development for years. Now multi-platform is going to have the same impact on *actual* customers. How many failures could Delphi and its customers stand any longer?
If Delphi wants to really be the Swiss army knife of development tools, then it has to fully embrace both 64 bit and cross platform IMHO... and they seem to finally be in a position to seriously attempt doing so. Hats off to them, I really do hope they pull it off...
For me, the failures of both Kylix and Delphi.NET are the red herrings - the former was hugely overpriced and buggy, being punted into a wholly unappealing market (a context where "customers" don't generally expect to be pay). The latter aberration was also hugely buggy, a technologically lagging irrelevance trying to beat the huge MS bully in its own (.NET) backyard.
Those particular mistakes don't look (to me) as if they are being made again... With the new project, the cross compile aspect will be offered as part of the basic Windows based Delphi IDE (adding value to the core product) while still being centred around their own framework(s), not that of the 800lb Redmond gorilla (and major dev tools competitor).
The concept of porting applications isn't necessarily the be all and end all driving factor here - the prospect of writing Windows rich clients, Linux server apps and iPhone apps from within the same IDE has a value all of its own. As for the ease of porting, if desired, then there are definitely plenty of details to be worked out - I agree about the desirability of avoiding Java-esque lowest common denominator GUI issues - but going the full "write once, run anywhere" hog doesn't have to be the end game here. "Write (the bulk) once / bind in bespoke GUIs / compile to everywhere" would be more than acceptable IMHO.
Of course, it's all about the execution now but at least there are real signs of testicular fortitude being demonstrated here, at long last...
"Those particular mistakes don't look (to me) as if they are being made again". Let's see... right now what kept Delphi alive was plain, native Windows development. That's where actual customers are - Linux and iPhone developers? They aren't using Delphi - that's a market Embarcadero have to create, and they need actual Windows developers to port their applications to other platform to gain space.
The more they keep losing because Delphi can't cope with *today* customers needs, the less they have to write software for other platforms *tomorrow*.
Or they expect lots of Linux and Apple developers to buy a Windows license and Delphi to fire up a virtual machine and write their own applications? That's wishful thinking.
And, BTW, business customers don't use iPhones - it could get the headlines, but Blackberries and Windows Mobile smartphones are much more common, hope plans aren't made on hype....
Native code is there to stay:-) No doubt about it. Where the performance is key then even Microsoft relies on unmanaged, native code. Look at Direct2D - the new Windows 7 API for graphics. It is pure unmanaged C++ code. Look at XNA Math. Unmanaged code. You need unmanaged code to implement all these virtual execution environments. Don't you?
"The more they keep losing because Delphi can't cope with *today* customers needs, the less they have to write software for other platforms *tomorrow*"
I agree that they have to keep their core customer base happy as a priority but apparently Embarcadero are ploughing in enough resources to work on both the 64 bit release AND the cross platform project. It doesn't seem to be a resource starved either/or situation anymore, AFAIK.
And, BTW, I don't see Linux on the server or OS X on the desktop / iPhone as platforms of tommorow, they are right here today and growing.
"Or they expect lots of Linux and Apple developers to buy a Windows license and Delphi to fire up a virtual machine and write their own applications? That's wishful thinking".
Yes, I don't think they really expect that either. What I think they do expect is that the cross platform targeting approach from within a Windows client would make Delphi more attractive to Windows developers wanting to dabble in Linux or OS X (or whatever else comes down the pipe later).
From my view point, what we need is for Delphi to do for web/internat apps what it did for Win32 development in 1994 - there was nothing like it, since then it has just been copied by all and sundry.
We need a new way of developing applications for the Internet age. A new VCL-like model a new "VCL-like Serving" server model a new VCL-like Server client model. So far, as far as I can see, everything for the web/internet has been aimed at manipulating/circumventing the restrictions of what was originally a fixed page layout/formatting tag system being sent a new page lookup via a single line text editor. Why are we still doing this?
As a straight Win32 developer getting started with anything web based, compared to beautiful simplicity plus raw coding power of Delphi, seems like trying to arrange chewing gum and string in a magic pattern that most times, with the right incantation(s) all connect up and actually do something useful. This frequently breaks of course - all web apps, and I insist all, compared to native apps are atrocious to code and atrocious to use. An example is D2009 Help - when Delphi's Help was a native code .HLP file system - I pressed F1 and help pops up - immediately. Now it is a browser/search hybrid. I have to wait..and wait a bit longer and then it pops up with a sort-of related article. It's a retrograde step to accommodate the new accepted ever-browsing user experience.
There is a tantalising glimpse of what could be in Delphi4PHP and Intraweb but even Intraweb is a clumsy fudge and D4PHP is not really finished. This is not because the developers have not tried... It's just that in my opinion they are targeting an outdated platform and display mechanism.
An example when we are wanting to visit our banking facility on-line why do we load a program "The browser" which we are reminded daily is insecure by it's very nature of wanting to send text strings to identify what we ant to do? This is also demonstrated by the sheer complexity and length of the URLs you see in the address bar. No one could actually type it in and "Navigate" to it...
Finally do you think I pressed Submit with out Coping this text first? If you still do that ... is that not case proven?
[Later, after submission error "Name and email required" and losing the content]:
Case proven. I clicked on comment anonymously because It didn't want to bother creating yet another sign in.
It's funny, I was agreeing with Jim Cooper up till this last paragraph. He started off making good points about cross-platform compilation not being worth much. Then he makes a fan-boy-like statement like this:
"Also people, since the advent of JIT compilers, some managed code (like .NET for example), actually is native code when it's running, making performance another red herring. I can't believe people are still on that old saw."
Sorry, Jim; but there's a *huge* difference between "some managed code..." and "all managed code".
I don't know why people keep making this simple mistake. Yes, CPUs and JIT compilers are fast enough for some code. But when the code will be run a lot, by a lot of people, the benefit of any speed increase gets multiplied a thousand-fold.
I have been a fan of Delphi since the earliest days. I think that there are many things that would bring it back into the forefront of the development world.
1. The price of entry for developers is substantial this also means that upgrades are also very costly. For many people this development environment is simply out of reach. (lower prices or make the buyer do some free labor for you in exchange)
2. Delphi has a huge grass roots community and there is an enormous code base available on the net. (expand existing examples and source code)
3. Native code is fine. Managed is fine. (how about just building the compiler and interface once in such a way that updates just fix whatever is broken. (why is there a new version every year?) Couldnt it be designed so that you just add "patches" or components or libraries?
4. Support all windows libraries that are truly necessary. (do we need 100 different ways to every single thing?) This leads us to a point in 3 about just having libraries to support those features.
5. Use the media to show that Delphi is not a second class language. That it is not only a contender but the one to be contended with. (set the pace)
6. Keep the IDE configurable (how about skins) that way users can totally customize the IDE features and layout.
7. Focus on research. (Why follow microsoft) How about developing new and creative ways of solving the WEB 2.0 problems. Borland has always been a leader. Why are we now just chasing for scraps?
8. Allow your loyal fans to contribute. There is a lot of free labor in the world. (a little recognition goes a long way)
9. Keep the compiler fast and clean. (reduce the size of executable that are generated if possible)
10. Dont be greedy!! When you get in front of the pack then you can make all the money you want.
11. Incorporate more third party developers into the base product. Dont worry about revisions as they have "source code" your users are programmers they should be able to fix simple issues..
Anyway I could go on and on .. but .. who really reads these anyway???