4

Another question over on SO introduced me to Oxygene, formerly Chrome before the browser of the same name came to prominence. It's in the Pascal syntax family, but brings in a lot of object-oriented grammar and elements from the C family, notably Java/C#. One of its big advertised strengths is that the language is implemented as runtime-independent; programs written in Oxygene can target .NET, J2EE, Android, or Cocoa, making it a memory-managed language almost as portable as C/C++ is in unmanaged-land.

However, my question is whether that kind of independence is really useful, given that the frameworks and environments it targets are so different (and incompatible). There are a host of problems inherent in writing one program that can be compiled as-is to target all three of these runtimes, and a common language is only the tip of the iceberg. Java doesn't have a System.Windows.Forms namespace; it has java.swing, and the classes underneath are totally different. Similarly, Java's database interop is via JDBC, while .NET has the ADO.NET sub-framework. While having a common language is nice, being fluent in a "language" is as much (more, IMO) about being fluent in the targeted libraries as it is with the syntax of the language.

Does anyone have a common example of where runtime-independent languages have been leveraged to create truly portable programs across all supported runtimes?

Improve this question
6
  • 4
    sounds like Write Once, Debug Everywhere
    – Dan Pichelman
    Commented Jul 17, 2013 at 17:36
  • Kevin Glass did have e game running on both iOS and Android using XMLVM, but an iOS update broke it. Shows the risks of targetting iOS in particular and multiple VMs in general.
    – Peter Taylor
    Commented Jul 17, 2013 at 17:59
  • JavaScript is executed across many different runtimes (they just happen to be embedded inside a browser most of the time)
    – GrandmasterB
    Commented Jul 17, 2013 at 18:04
  • @GrandmasterB - I see where you're coming from with that, but in that case the .NET Framework has x86, x64 and Itanium runtimes, each of them different enough that you have to pick the right package when installing the redistributable. What .NET code targets is the CLR runtime interface, just like what JavaScript targets is the DOM (among other things). Those runtimes are designed to provide the same interface to code - that's the purpose of their existence - but Java, Dalvik, .NET and Cocoa do not provide the same interface to code.
    – KeithS
    Commented Jul 17, 2013 at 18:09
  • 1
    @Giorgio - I can understand the pun. Each environment you target and support is one more run of your test suite, if you're lucky enough to have a portable test suite for your portable code. Truly supporting multiple web browsers is a similar problem; the browser and the OS it runs on can result in behavioral changes for a user that you will never see in dev unless you have a test environment with that browser and OS. So, it's not enough even to ensure you're targeting the same runtime, because there can still be differences between two supposedly interoperable runtime implementations.
    – KeithS
    Commented Jul 17, 2013 at 22:03

2 Answers 2

Reset to default
3

I'm not familiar with Oxygene but from time I spent looking into Fantom and similar other languages that do what you're referring to, what I found was that they weren't as you're suggesting requiring you to know the different libraries.

The killer functionality they have is a single library that translates to the independent separate ones; so you write code against the Fantom library using their UI functions, and it will translate it to Swing or WinForms depending on whether you compile it to .NET or Java. In this way you don't need to know anything about either the .NET or Java libraries, you know one library and it will handle the translation for you on those standard things like DB access, GUI, networking, et al.

Improve this answer
4
  • 2
    "There is no problem in computer science that cannot be solved by adding another layer of indirection"... Good point, +1.
    – KeithS
    Commented Jul 17, 2013 at 18:06
  • 5
    ... "except for the problem of too many layers of indirection".
    – user39685
    Commented Jul 17, 2013 at 18:56
  • @MattFenwick - Exactly. While the idea of adapter libraries to make a language and its framework fully runtime-independent, I can see this having performance and functionality implications; there are things you can do using .NET libraries that aren't available in Java, and vice-versa. The language and framework becomes the set intersection of all the runtimes it targets. Even then, while it may be runtime-agnostic by design, care must still be taken to ensure the code written is still OS-agnostic. That can be impossible; things as basic as file paths differ greatly.
    – KeithS
    Commented Jul 17, 2013 at 22:09
  • @KeithS I agree and am not convinced for large portions of applications these are the best route to take, but all the same there are a variety of scenarios and applications where that would work fine and in those cases there are a variety of benefits. Yes it'll be a leaky abstraction, but we use abstractions because their benefits outweigh these problems (when they're done well to minimize leaks, Fantom appears to be so for instance)
    – Jimmy Hoffa
    Commented Jul 17, 2013 at 22:32
0

You're assuming the language is designed to be able to compile the exact same program as-is for different platforms. That doesn't appear to be the case. It's portable in the same way as C and C++ are portable. Your core language is the same on all platforms, but you target the native runtime environments. In other words, the language is cross platform, not the application.

Even for cross platform applications, maintaining different sets of platform-specific code is fairly common. Even if you can't reuse the platform-specific code, using the same language allows a lot of code reuse, if you structure your application properly.

For example, I maintain a program for both Java/Swing and Java/Android, for which 75% of the code is reused between platforms, even though both apps are completely native. That's not as nice as 100%, but it sure beats the 0% of common code I would get if I ported to Objective C/iOS.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.