Could Ruby be Apple's language and API future?

I live in Cork, Ireland, location of Apple's European Corporate HQ, and I know from friends that they've been running Ruby on Rails courses there. It might be inconsequential, but you have to ask yourself why? ... it shows at least that they consider Ruby, and Rails to be significant in some way.

> The Dalvik virtual machine that ships with Android interprets byte code. A byte code interpreter has a few advantages over a stack that runs native code. Performance is not one of those advantages.

This is a cheap shot.

First of all, when building a JIT or a tracing compiler, it's always better to start with an efficient interpreter ... and for all intents and purposes, Android has a kickass interpreter.

Then you can add incremental improvements ... like JITing, or various tricks to optimize dynamic code paths. And this is where Android is today ... the latest version comes with a JITter that will only get better.

What an efficient VM truly allows is for regular programmers to write efficient code without thinking much about optimizations. So most applications can benefit from a good VM precisely in terms of performance.

I've also seen rewritten C++ apps in Java that ran faster, for many reasons, one of them being that you have the power to think about architectural optimizations without getting lost in little details.

And one other thing ... a mobile phone doesn't have the resources (like RAM) to shove in it too many optimizations, but on the other hand you can built specialized CPUs optimized for Android's bytecode.

If you do that, the "stack that runs native code" can eat your dust.

Having used both Objective-C and .NET, I would much rather be faced with implementing a dynamic language atop .NET than have to do so atop Objective-C. While ObjC's dispatch system is quite dynamic, the relative weakness of the type system (if you can even call what ObjC has a 'type' system) and the amount of C baggage it drags along with it makes it a rather unfriendly environment for running dynamic code.

Here's one example: With the .NET type system, you can check a set of arguments against the signature of a method defined in the type information of an object instance, which means that you can be absolutely certain that your invocation will succeed without corrupting state or returning incorrect results. What's more, you can do this check at compile time (in a static language, like C#) or at run time, via reflection. The .NET JIT and runtime code generation facilities mean that you can do 'static' verification at load time for scripts instead of at the point of every invocation. In cases where you have a mismatch between the types requested and the types provided, you get clear, precise error feedback that allows the problem to be corrected. The .NET runtime is able to use this type system to perform a large number of useful safety checks against all code when it's first loaded, so that in many cases it can guarantee no memory corruption or out-of-bounds accesses will occur without having to check every single operation.

As the vast majority of Objective C invocations in a Cocoa application are effectively static (you're sending a message, as described in the Apple documentation, to an object of a given interface, as described in the Apple documentation, which you constructed following instructions in the Apple documentation), the dynamic nature of ObjC invocation wins you very little. The ObjC type system cannot provide you much assistance for those invocations, because it's built atop the C type system - GCC will check your argument types for you statically at compile time, but at run time, given an arbitrary ObjC object, it's going to be quite difficult to be certain that an invocation will succeed. What's more, in most cases GCC can provide no more than warnings, and those warnings are often incorrect.

On the other hand, for the vast majority of code written in a language like Ruby or Python, your method signatures contain no type information, so no validation can be performed. Neither Objective C or .NET win here because both require strong types for arguments. You need only look at NSArray to see how little you win by using Objective C in this case.

Ultimately, in both cases, neither environment is a good fit for a language like Ruby, but I would argue that .NET (and, for similar reasons, the JVM) provides a far stronger foundation upon which to build a language like Ruby. Building a language like Ruby on top of Objective C is only superior to building it in C due to its status as Apple's preferred language for OS X development.

Ruby may at some point be an optional language but it's not going to replace Objective-C.

> Apple actually spearheaded the HTML5 movement...

Hahaha, that was good. =)