Sunday, April 21, 2013

Delphi Prism is dead, long live Oxygene.

I just learned that Rad Studio XE4 will not include the "Prism"  (delphi compiler for .Net) product in the bundle anymore.

I for one am not surprised.  RemObject's delphi-flavored "Oxygene" language that powered the "Delphi Prism" product (a rebranding of Oxygene, since day one) has been more of a threat to Embarcadero than an asset, since the move towards iOS ("Nougat") and Java.

Embarcadero has a really nice plan, a cross-platform-Delphi go-to-market strategy, and I believe that their plans and RemObject's plans have been on a collision course for some time. As a consumer who purchases products from both, I am happy.  As I should be.  Because that means there will be competition.  I believe that the perception from inside the Embarcadero camp might be that they are a serious producer of compilers and native-code-generation tools, and the idea that .Net based "JIT" is "native development" is laughed at inside the hallowed halls of Delphi's developers, the idea being that  Delphi's core compiler and IDE technology is of an order of magnitude more importance and sophistication than the tiny little product known as "Prism" inside the RAD Studio box, and Oxygene everywhere else.

I don't actively use Oxygene/Prism, but I'm definitely interested in both it, and in XE4's cross-platform abilities when they ship.  As I have already learned iOS and Objective-C I don't need anyone to spare me that learning curve. It's done.  But I could use a tool that will let me build one app and target more than one mobile platform at once.

RemObjects' products, including Oxygene, are powerful precisely because they are built on top of a big open source ecosystem (Mono on non-Windows platforms) and by being built atop .Net are also leveraging powerful .Net platform capabilities, on Windows.

Ironically, the era of doing your own compiler from scratch is drawing to a close as Embarcadero prepares for a future where a new llvm-based Delphi compiler allows for native-compilation on iOS, and Android.  This is an era of collaboration and an era of competition, at the same time.  While Embarcadero may be "big" compared to RemObjects, both are small compared to the real juggernauts in the software industry.  Microsoft has the Windows platform just about sewn up, and VisualStudio has a commanding presence on Windows.   As Embarcadero and RemObjects set sail on the "blue ocean" of cross-platform development I wish them both the best of luck.

My personal bet is on the Embarcadero horse, because I like the idea of an llvm-based compiler and no runtime overhead and full static optimizing compiler tech, on mobile, windows, and mac.  But if that falls short of its promise for some reason, I am glad that there is another horse in this race.  Having Embarcadero and RemObjects as competitors is better for me, the intended target market for both company's products.

I am not on any Delphi XE4 field tests or betas and the information in this post is based purely on what I have read in public websites.

Update:I was not aware that the ios apps emitted by nougat were native compiled binaries... However I do not consider the dalvik stuff any less of a jit based java tech, dalvik does do preJit compilation, just a change of degree not of nature. Optimizers happen at device load time and are less effective. There is still an overhead in dalvik but it is part of android and you don't redistribute any runtimes. So when I say "native" I mean non jvm and non jit. If I am truly mistaken here I ask to be corrected.
Update 2: I just read the docs for Xe4. Zero based immutable strings? What the hell were you thinking, Alan? I have reversed my bet and am now betting on remobjects. I guess oxygene strings are like .net strings and are thus zero based and immutable but if I have to bear that kind of semantic seismic shift I think I also would like it named something other than Delphi when you're quite finished turning delphi into objective c with begin and end keywords.oh well. I must admit that Arc is pretty damn cool, I forgive you Alan, I am still super excited to try this out when it ships! This is probably the price for using a string type in the new compiler which participates fully in objective c classes as a toll free bridged equivalent to nsstring.
Update 3: I plan a followup that covers the reality better as soon as I get hands on time eith both xe4 Rtm and Nougat RTM. Color me a possible Oxygene customer.


  1. Reading your post I get the impression that RemObjects Oxygene for iOS and Android somehow (non-Windows platforms) uses Mono. It does not. Oxygene emits true native code for iOS and Android. It also binds directly to the true native UI frameworks of those platforms.

    This places clear blue-water between their approach and Embarcadero, who have bet the farm on FireMonkey.

    As such, they aren't really competitors at all. Embarcadero are offering a one-size-fits-all cross-platform framework. RemObjects on the other hand have a family of products with a common core language but which beyond that are platform-specific "variations on a theme".

    RemObjects aim to enable you to use Pascal to develop for your desired target platforms.

    Embarcadero aim to make a new platform: FireMonkey.

  2. I meant also to add that your personal bet is a little misplaced.

    If you want "no runtime" then you should be backing RemObjects. With Embarcadero there *is* a runtime - the FireMonkey framework, built-in to every FireMonkey app you deploy.

    This observation leads me to suspect that you do actually think that Oxygene for iOS and Android relies on Mono, and as such you are mistaken and need to reconsider your options before placing your bet.

    Oxygene is the solution that comes with no runtime. Not FireMonkey.


  3. Jolyon is correct. Reading your post, I got the impression that you believe that Oxygene requires mono for cross-platform development. That maybe the case if you plan to use the .net flavour of Oxygene but Oxygene also compiles directly to the Java runtime as well as the Objective-C runtime which is as native as you can go on Andriod, OSX and iOS.

  4. I was definitely wrong about ios and I would love it if someone would post some info that would help me understand where I have misunderstood the situation on android. Please post links!


    There are many posts there regarding technical details of Oxygen's flavors. If you are interested in, you can spare some time and dive in.

  6. Hi Warren,

    the Android / Java Situation is quite easily to understand. Both .NET and Java (and also Cocoa/Objective-C, to an extend) are (memory)managed runtimes.

    On the one side, Oxygene can consume and emit .NET IL code. On one of the other sides, it consumes Java libraries and emits pure Java Bytecode that - without any additional layer - can be executed directly on every Java VM, including Android's Dalvik.

    The third side is Objective-C, where the compiler again consumes the native frameworks written in and for Objective-C, and emits native code.

    Merely the Oxygene Compiler itself is written in Oxygene for .NET, so you need either Microsofts .NET or Mono to execute the compiler, but thats not different for Delphi where the Compiler itself (at least currently) just runs on Windows and cross-compiles for other targets.

  7. Zero based immutable strings are long overdue. They are a good thing.

  8. Sigh. I suppose you're right. Java has them, C# has them, Objective-C has them, Delphi is pretty much alone in having mutable 1 based strings.

  9. Warren,

    great post, and much appreciated.

    It does seem that you have some misconceptions about the layer Oxygene is sitting at, as some of your commenters already pointed out, and i wanted to give some more details.

    Oxygene can compile for three distinct "targets", and each of these target let you reach a variety of platforms.

    The oldest target is Oxygene for .NET (what also was "Prism"). It compiles for the Common Language Runtime, i.e. .NET and Mono. Apps created with it can run in many places, including Android and iOS, using Mono, and some of the downsides/concerns you mention do apply here. We do not *recommend* using Oxygene for .NEt for these, our recommended platforms for Oxygene for .NET are Windows, Windows Phone and cross-platform servers.

    Next us is Oxygene for Java, which compiles for the JVM. The most prominent use case for this right now is Android, although it also lets you build anything else that is Java based, form Applets (ha!) to JSP, from apps for your Java-based refrigerator to... whatever else runs Java. You are right that Dalvik, Android version of Java, is still "managed". But it *is* the native API for Android. All the classes and APIs that make up Android as a platform (opposed to the Linux kernel underneath) are Java based. (Google as a "Native SDK" for C++, but they explicitly say "don't use this, unless you're like writing video codec"). Java/Dalvik is as "native" as you're gonna get on Android, anything lower-level is starting to become less native again,

    Finally, next month we'll ship Oxygene for Cocoa, currently in beta as "Nougat". Oxygene for Cocoa will compile to x64 (Mac), armv7+ (iOS) and i386 (iOS Simulator) code that runs on the Objective-C runtime. the term "Objective-C Runtime" is misleading in two ways. One, that s has little ties to the actual Objective-C language (except that that language was the only one that seriously supported and compiled for that runtime, until now) and two, it's not a runtime on the same level as .NET and JVM, it's really just an object model (much like Delphi or C++), with some "semi-managed" features such as really powerful RTTI and "dynamic-ness". Oxygene for Cocoa will allow you to build iOS and Mac apps as native as its gonna get. You use the same classes you'd use form Objective-C, when you define your own class, it's gonna descend from NSObject (or a descendant, of course). And when you look at your final executable, it's gonna be indistinguishable form one created with Objective-C (except that you had a lot more fun creating it, coz the language is so much more powerful, not to mention cleaner/nicer ;)

    I hope this helped to clarify a few things. I like Jolyon's take on this: "Oxygene is the solution that comes with no runtime. Not FireMonkey." That really is spot on.

  10. ps. posting comments is broken in Chrome.

  11. Wow. Sign me up Marc. I am impressed and thoroughly glad to admit that on dalvik and jvm you are as low as you can go. I actually think some oxygene based app framework plumbing could be a "new vcl for mobile" and thats the biggest question mark for me now as you have addressed my big concerns cleanly.