[Estimated Reading Time: 3 minutes]

Over the past few weeks there has been some speculation as to what the mysterious “Hydrogene” that RemObjects have been working on may or may not be. Well, that particular feline has slipped it’s captors and escaped the bag.

I’m not aware of any official announcement and I hope that my mentioning this does not upset any plans. But a post appeared recently in the Google+ Oxygene Community that gives the game away. I have waited to see if this post would be quietly removed at the polite request of RemObjects, but since it hasn’t I thought it was time to comment on it myself. 🙂

Oxygene of course is ObjectPascal for native .NET, Android and iOS/OS X development. An ObjectPascal compiler that produces object code that is native to each platform, where “native” means “first class citizen participating fully in each supported platform without any runtime beyond that provided by the target OS/platform and with no need for bridging or API wrapping“.

Top of the Pops as far as speculation about what Hydrogene may be was that it would be a C# front end for the back-end compiler technologies that support Oxygene itself.

That is: C# for Java / Android and – I would think – iOS / OS X.

I think Microsoft have C# for .NET covered 🙂 though I wouldn’t be surprised if RemObjects might have something to offer in the way of an improved C# for .NET as well. 🙂

To be clear, all that is clear from the post to the Oxygene Community is that Hydrogene supports Java / Android ! .NET and Cocoa would be obvious inclusions but are not confirmed as yet.

This is exciting news to me, but I couldn’t help but be reminded of some (relatively) ancient history.

Philippe Kahn is a name most often invoked in reference to the early, Halcyon Days of Borland, but a name perhaps less often mentioned is Niels Jensen.

Niels was one of the original founders of the company that would later become – with Philippe Kahn’s help – Borland Inc. But he split with Borland in the very early 90’s to found Jensen & Partners International, producing a range of compilers under the banner of TopSpeed.

I used the TopSpeed Modula-2 compiler for a brief time myself. 🙂

A key feature of the TopSpeed compilers was the fact that you could use code from each language (C, C++, Pascal, Modula-2) with the others via object oriented extensions, though I never had direct experience of this in action so cannot speak to the success of this in practice. The compiler architecture that made this possible was the realisation of Niels Jensen‘s vision of independent front and back ends for these compilers.

This is of course now continued in RemObjects own technology and – rather more belatedly – by Embarcadero.

This vision is echoed no more strongly than in the way that Oxygene (ObjectPascal) and Hydrogene (C#) are able to seamlessly and fully participate in the worlds of the object code produced by other compilers on the supported platforms – IL and .NET framework in the case of .NET, Java Bytecode and, well, Java in the case of Java (and thus Android) and LLVM / Cocoa for iOS / OS X.

You could – for example – create a Java class library for Android in C# using Hydrogene, consume that (along with other Java class libraries) in an ObjectPascal class library using Oxygene and then that class library itself may be consumed by an Android developer using Java.

Parallel examples can be drawn for .NET and iOS / OS X, though obviously there are some constraints on the sharing of object code (and even, to an extent, source code) across the different platforms supported by the back-ends, but this can – in theory if not yet realised – be addressed at the source code level by the judicious application of framework and RTL abstractions.

I think it is fair to say that these are seriously interesting and exciting times for RemObjects.

27 thoughts on “What is Hydrogene ? Asked and Answered”

  1. The main question on cross-platform is RTL library! No matter what language (Pascal/C#), but we need some bit of code to run on all platforms.

    DA/RO SDK can be one, but Sugar as for now is not complete replacement for RTL.

      1. Of course, having water *and* Fire, now that lets you cook up all kinds of cool things… But, one leak at a time… 😉

  3. Object without language boundaries is not either a compiler feature, either a VM feature.

    You need to have IL (Intermediate Language) pseudo-code emitted to share a common object view. In this IL, the “class” is defined.

    On .Net and Java, it is done at the Virtual Machine level.
    You can even mix language paradigms: e.g. the great functional language CloJure is able to access “pure” Java objects – and its “string” type is in fact the Java “string” object. BTW CloJure is even able to be compiled into JavaScript.

    At compiler level, since LLVM is (by name and design) an IL-based compiler, you can theoriticaly also shared objects between front-end languages.

    But the main point is the underlying framework.

    Even if you can share some part of your code, you need to write a lot of specific code for each platform.

    The Java runtime is very far away from the .Net’s or iOS/OSX’s version.

    Oxygene is great. Perhaps a version emitting JavaScript (just like SmartMobileStudio compiler) would be a good idea. In this case, the runtime will be HTML5 itself, so it would be able to run on any HTML5-supported platform.

    This is what is interresting in GTK, QT or FireMonkey approach. Or even http://www.chromium.org/developers/design-documents/aura

    1. Even if you can share some part of your code, you need to write a lot of specific code for each platform.

      Because the platforms have specific differences. Even if you abstracted all the common parts to a lowest common denominator level, you end up having to write platform specific code if you want to create apps that sit comfortably on those platforms. And in many places, your lowest common denominator will end up redundantly duplicating capabilities of the platform(s) (often complete with their own bugs that the platform doesn’t have and which have bu**er all support because the runtime you are dependent upon is a niche interest group in an already niche language) simply because the platform implementation doesn’t “play nice” when it comes to trying to shoe-horn it into the lowest common denominator view.

      1. Indeed.

        Differences do exist.

        But you can have very little difference, e.g. for HTML5.
        Your whole UI stack is the same: HTML5/CSS.
        Your low-level execution stack is JavaScript and its libraries.
        Then you can have an HAL over each dedicated platform (e.g. WebRTC, or PhoneGap).
        Of course, if you want to implement Android intents, it won’t be feasible.
        But I guess 90% of existing apps would be fine enough in HTML5, even small games.
        Note that you can always link any custom library (or jar) to your PhoneGap application, so that you can access the OS as expected.

        With Oxygene, you will have to rewrite 70% of your code for each platform (RTL + UI), even if you do not need any low-level feature. I did some cross-platform apps with Mono, and it is a nightmare do design the UI for each platform – even if the language is the same, and even if Mono feature a common RTL (which is not the case yet for Oxygene).

    2. Agreed. Even if there are specific differences, most of the times you will be using a common denominator, at the end, the developer needs to measure the advantages of coding on N different languages to do great on specific differences or in one and work in the exceptions.

    1. LOL, but actually if Embarcadero were writing it this is exactly what it would mean. A .NET stub with just enough CLR scaffolding to launch container for a custom rendering engine and handing off execution to an embedded runtime running within it. That is what Embarcadero would mean by “True Native .NET application”, yes ? 😉

      In the usage you refer to of course “native” didn’t refer only to .NET but everything else in the list that followed: Android, iOS etc. In the case of .NET it means specifically using the CLR and the .NET framework, as opposed to the specious and misleading use of the term as deployed by Embarcadero to mean “unmanaged code” with the platform itself at arms length and sometimes entirely beyond your reach.

  5. I’m not sure the market was calling out for an implementation of C# for the JVM.. there have been some open source attempts before such as Stab, but they never caught on.

    Anyway, the talk of object inter-operation made me think of Red Hat’s Vert.X project thry’re working on…

    >Vert.x is hailed by some as the next evolution of the application sever; it’s
    >a modular and multi-language framework that runs on a Java Virtual
    >Machine (JVM). While some are making the JVM multilingual, Vert.x goes
    >further: it lets you mix and match programming languages in a single
    >application, so you can code in Java, JavaScript, Groovy, Ruby and
    >Python.
    >
    >Vert.x could also eclipse the industry’s most recent best hope, Node.js –
    >which allows JavaScript to be used end to end, both on the server and on
    >the client. But’s server-side Javascript can also be a real challenge when
    >it comes to scaling. The polyglot Vert.x, meanwhile, is intriguing devs, and
    >its ranking rise in Google searches reflects the growing interest.
    >
    >Vert.x is an interesting and potentially disruptive technology and it’s
    >generating interest among those who 10 years ago would have been
    >championing JBoss.

    http://www.theregister.co.uk/2013/02/08/red_hat_legacy_maker/

    1. I agree that the relative lack of real “clear blue water” between C#, Java and the rest of the curly bracket gang makes the prospect of C# for Java et al far less compelling – for me – than ObjectPascal was and is.

      However, I have been surprised by how many people have said “ObjectPascal for Java is all well and good but I’d be more interested in a C# version“, or words to that effect. I don’t understand it myself. But I imagine that RemObjects took the pulse of their market and considered the effort worthwhile.

      If it only serves to increase the interest in what RemObjects are doing that can only be a good thing, whether you are using Oxygene (as I am, with no intention of switching to Hydrogene myself) or are interested in a slightly #‘er form of curly brackets. 🙂

      1. Actually, RO did have a lot of puzzle’s parts before Hydrogene: code-gen modules for .NET/Java/Cocoa, C# parser (as a part of Oxydizer), platform-specific tricks (interop/invoke quirks).

        Hydrogene make sense due to larger C# number of devs.

        But RTL is a king. I like Sugar approach due to eliminating “common denominator” problem and shifting it to “common API” possibility!

  6. OMG, really thrilling news, whats this called ” native .NET”?
    let me have a guess
    not a tiny initiative,
    but,
    NSA Eagerly Transmitting ?
    😉

  7. Have you looked closely as XeroCoder? http://xerocoder.com/

    I think it is what you are dreaming of and what RemObject is trying to achieve but in a more polished way and at an affordable price.

    2. Somehow cool together with the new parallel execution grid, indeed. I will have to check that in detail.

      Good to see a C# too in the Remobjects Compiler Suite.

      We used TopSpeed Modula at university. The Turbo Pascal guys were a minority. The one or other could be found but not lots of them. The ‘separated’ backend was praised these days too but history had shown – those who are in the market first even with a crappy solution are more likely the winner. Maybe that changed but I am not totally sure if customers already honor solid vs. quick.

      1. Thats a long story. I know them since the Delphi++ IDE. That IDE already allowed to integrate .net as well as Delphi … and so on. 3 languages.

        An IDE implemented in Delphi. Later they evolved the product into a parallel grid execution system and IDE. The IDE runs under Mac, Linux and Windows …

        XEROCODER. XPower++/XEROCODER – based on open source and grid reimplemented since the old grid is said to be Google grid now.

        if combined it with the Grid Execution System – The application developed with XEROCODER does decide (more or less) on it’s own where to execute code. The infrastructure runs in Canada, Turkey and Germany at the moment. Of course you can justify and configure all you need…

        Afik they also have access to companies that provide special designed tablets too …

        They are a nice innovative tech shop… afik. But I don’t know about size. For existing customers they still maintain the old grid since some huge companies early relied on the grid technology for mobile apps – business processes level in enterprises, education portals, … just a few.

        I don’t know more.

  8. This is great news. For those wondering why you’d want a C# compiler for Android or iOS take a look at Xamarin and the way they’re exploding. But they’re charging an horrendous amount of money for their tools and pricing most small software shops, like mine, out of the market for their product. With Hydrogene being sold for the same price as Oxygene ($699 with $499 maintenance after the first year) this is a result for us now we’ve moved away from Delphi and Pascal to C#. The market for C# developers to get to iOS and Android is huge and Hydrogene gives the market just what it’s looking for and without the huge Xamarin price tag. I really hope this explodes for the RO as they deserve it for taking their technology in this direction.

    1. A good time for that will probably when its being announced 😉

      1. If I’ve learned anything from Embarcadero, it’s that it’s never a good time to state differences between your product and the competition’s. Don’t put this information on your web page anywhere comparing your product to anyone else’s. Pretend your competition doesn’t even exist! And if anyone complains on your official forum about the difficulty of comparing your product to others due to this lack of information, appoint people with a moniker like “TeamRO” and have them make comments along the lines of “It’s not up to RemObjects to tell you about the competition’s products or make it easy to compare them” and “Isn’t that your job to form a comparison between products? Why should RemObjects have to do it for you?” But feel free to make vague comments about Hydrogene being “your secret weapon” and “a productivity enhancer” without ever explaining specifically what makes it so or how it does it compared to anything else. Oh, and delete all the forum posts of anyone with a Ghost Busters moniker. I don’t know why, but this is *vitally* important.

        1. LOL. Good business advise there, will make sure to keep those in mind! Another good tip, when asked by the press about your competition, tell them you don’t consider those competitors to be competition because their products do things ever so slightly different (such as, use C++, unlike your own C++Builder product 😉

Comments are closed.