Embarcadero Technologies, the development tools outfit that inherited much of Borland's technology, has released a new product it says can produce native apps for four operating systems from a single codebase.
That tool is RAD Studio XE5, released this week, and Embarcadero is claiming it is the first development tool capable of …

cost aside...

Re: cost aside...

Just click "Buy now" on Embarcadero site, go to the online store and you'll see the prices, this one are for Delphi alone (new user/upgrade, prices in Euro without VAT, price in USD should be the same, Embarcadero use the usual 1:1 exchange rate):

Yep, if there is no indication of pricing then given the press release comments about "taking the hit" it's going to be way more than £10000.

Even an MSDN Universal licence has a price tag online.

Given that as I type this there are adverts for developers offering only £18k p.a. (and presumably people to bite or else the salary would quickly change) then the overwhelming probability is that it will be cheaper to hire extra developers for each specific platform. Even if the coders aren't that good, they will probably work as well as an "automatic" quad-platform converter ...

@petboy

Re: @petboy

Performance?

They have underperformant compilers (they're switching to LLVM, because they can no longer develop a compiler in-house), the product RTL is very poorly coded (especially the 64-bit one), and their GUI framework for multiplatform applications is a vector one that mimics the target platform drawing every control itself, bloating the application and slowing it down. And a lot of their code now is built upon RTTI calls that are slow as well. Native applicationsa are not "automagiocally" more performant. They are if the whole chain is highly optimized by skilled developers. Something hard to do when you're development team is now made of cheap developers in Iasi (Romania) and Alicante (Spain). And let's not talk about the bugs living into the products for years, and never fixed...

It's funny how Embarcadero marketing still tries to hide the evidence - without understanding that its target customers - developers - are not so easy to deceive.

Re: Performance?

Re: Performance?

No, if you're a development tool company I expect you write your own compilers to compete with others. If you just become a reseller of technolgy developed elsewhere I can't see a good reason to buy your *expensive* tool. For $3K I expect a good compiler developed in-house, not a product cobbled together from some open source project.

Re: Performance?

For Android and IOS, they have created new compilers that emits LLVM byte code for LLVM to produce native machine code from. LLVM is also what Apple use for producing IOS apps.

The RTL is working well in Win32 and Win64 mode. I wonder what specifically you base your claim on related to 64 bit code? It seems to me you have little if no experience with the product at hand.

Can there be made further optimizations?... absolutely.. show me a library that can be optimized no longer, and Ill show you a library that is no longer fit for cross platform development.

What code is based on RTTI? Nothing except live binding. If you choose to use traditional binding (event handlers) or dataset binding, you are not touching RTTI at all. Oh... RTTI is also used if you want to marshal objects to and from JSON or XML, but thats no different to whats happening in .Net or Java.. metadata RTTI is used for marshalling.

Agreed that native is not always more performant. Anyone can f... up a perfectly good development environment with bad code, but its just as much the developers (you as a user) responsibility.

XE5 is by far the best cross platform compiler out there. Its not perfect by any means but it is definitely better than what I have tried cross platform.. and I have been around quite alot.

Re: Performance?

The plans are to switch *everything* to LLVM. The C++ 64 bit compiler is already LLVM. And they're also planning some stupid changes to the languages to better align with LLVM and the ARC memory manager.

The Win32 RTL was optimized thanks to the FastCode project - code developed outside Borland. The Win64 RTL is not optimized, and the latest releases have horrible code, like the TStream implementation copying data into dynamic arrays before writing them to disk (doubling the needed memory and slowing everthing down), the leaks in thread supports, and many others. Just look at Quality Central, Embarcadero bug system, and you'll find plenty of issues never fixed, and situation got worse when Delphi was put in the hands of cheap, unskilled developers. My experience with Borland/CodeGear/Embarcadero products dates back to TurboPascal 1.0 up to the latest releases. Thereby my experience, believe me, is pretty deep.

There is more and more code relying on slow RTTI calls (i.e. attributes are used through RTTI, no compiler support), because of course if you can't update your compiler you use some shortcuts. Sure, Java and .NET use RTTI, but Delphi is not a managed language and you expect a different faster implementation.

Market will say if XE5 is the "best crossplatfom compiler" (maybe GCC could say something?), and I'm sure you won't like the verdict.

But I have to ask myself

Review?

At least a quick review would be nice to get an idea of the current state of these dev tools for those of us who've hardly looked at the Borland replacement for years. Just to see if things are as poor as the other comments here suggest.

That will work so well

Creating applications to the lowest common denominator of four operating systems is going to work so well. It worked out great for Java didn't it? (And yes I know this is a different approach to the problem but Java apps never looked truly native because you were always working with a subset of the OS's features.)

Re: Java apps never looked truly native

Because they were developed by people who didn't know what they were doing, or more than likely didn't care/or was deemed relevant. I'm pretty sure I could present you with screen shots of software on linux, osx and windows where you couldn't guess which was java and which is not.

Re: Java apps never looked truly native

Re: That will work so well

Java is a VM which is quite a different approach. I haven't used Firemonkey (guess they have to call that FM these days) in any serious capacity (beyond some proof of concept work a few years back), but it is vector based and offloads to hardware acceleration so I don't see any big issue there. The IDE still supports platform specific functions (Win API being the most obvious), but you obviously can't target other platforms if you want to do that.

The problems this faces are no different to the problems you face writing any cross platform "application", be that Java or HTML5, c++ or whatever. UI conventions are different on different platforms. Do you attach your menus to the window or go for the OS X model? Do you have a single MDI window model or a bazillion independently draggable windows? Do you swipe to delete iOS style or touch and hold Android style? Where do you put your "back" button?

Gets my attention. I'm not a developer, but want to find a tool that is as capable as if not more than Lotus Approach, so that I, as a non-programmer, can create forms, charts, detail tables on forms, and embed charts on forms and reports, and embed drop-down detail panels on chart, and so on. I want to create kewl stuff but deploy (for freen and for pay) to Lin/Mac/Win/Android. I'd like to study it a month or two, then make rudimentary apps in less than a few weeks, and spend less than 6 months kicking out a decent beta, along the same learning curve as Lotus Approach, but not have it be Filemaker, Alpha 5, Sesame, Foxpro, Access, Omnis/Omnis Studio, etc.

Also, anyone use Code::Blocks, Codelie, Gambas III, or Qt4 Designer? If so, and you could choose two of those I mentioned (maybe Radstudio XE5 is 3rd choice...), which two would be in your tool kit if you had a boss say to pick two from the above, and both HAVE to be able to deploy natively and webly OS-agnosticly and acquired freely or cheaply (less than $400 for prototyping deployable/stand-alone apps)?

What about Livecode?

Re: What about Livecode?

Good question. Compared to Lazarus it's probably not compiled and may not be suitable for fast applications requiring number crunching or something. Lazarus also allows you do generate GUIs visually, algorithmically, or in any combination of the 2.

Re: What about Livecode?

'Compiled' is a rather slippery term, particularly if you have a compile free workflow as Livecode does - prior to compiling a standalone for Win/Mac/Linux/iOS from the same code base.

The point is, the claim "Embarcadero is claiming it is the first development tool capable of producing native apps for Windows, Mac OS, iOS and Android" is one that could only be defended by Mr Logic pedantry regarding 'compile' and 'native'.

Granted, I wouldn't want to build an industrial sized scientific data cruncher in Livecode. But if you are looking to go cross 4 platforms, that's unlikely to be the goal. I freely admit I am biased, becasue I've had 12 years of fun and profit out of it.

Oxygene needs to be mentioned

Between the free (as in beer) FreePascal and the expensive as in (who needs two kidney's anyway?) Embarcadero offering, sits "Oxygene" from RemObjects.

Like Delphi, Oxygene is an ObjectPascal based language but unlike Delphi instead of creating a portable runtime (FireMonkey) which all Delphi apps have to target if they wish to deploy to mobile devices or Mac, Oxygene compilers inhabit the natural world of each platform.

Oxygene for Java works directly with Java packages and emits Java byte code.

Oxygene for Cocoa works directly with Cocoa and emits LLVM code.

Oxygene for .NET ... well, you get the idea.

Using Oxygene means that you are working with the platform tools as the platform creators intended, but are not confined to using the language that those same creators used (Java / Objective-C) but avoiding all of the limitations and pitfalls that a lowest common denominator / one size fits all approach suffers from.

Worth bearing in mind is that Delphi for Android / iOS does not offer universal support for either Android or iOS.

For Android you can only target 2.3.3+ or later Android OS because they rely on the "NativeActivity" class introduced with that version of Android, to bootstrap the FireMonkey runtime. Even if you have a modern JellyBean device you could be out of luck as the runtime demands of FireMonkey mean that NEON support is mandatory. Whilst perhaps less of a problem in the future, it currently rules out Tegra2 chipset devices for example - Samsung Galaxy Tab 10.1, ASUS TF101 etc etc.

For iOS the embarrassing performance of FireMonkey on older iOS hardware has resulted in Embarcadero now mandating iOS 6 as the minimum for FireMonkey apps, ruling out 1st gen iPads for example. iOS 5.1 may only account for 6% of active iOS devices but that's still 24 MILLION+.

But more importantly than potential users unable to use your kit, if - like me - the spare gear you have knocking around to use as a development test rig happens to be either or both of these sorts of devices (in my case a TF101 and an iPad#1), then you will need to add the cost of some hardware to the already eye watering cost of Delphi.

Oxygene on the other hand - like the native tool chains - support anything that the platform vendors support.

It's a more sophisticated approach and cheaper into the bargain ($699 initial, $499 annual subscription thereafter. Unlike Embarcadero, you aren't required to pay your first year of subscription renewal up front).

Oxygene: $699

Delphi Pro XE5: $1,000 + $500 for mobile support + first year support and maintenance = $2,000+