

Could Ruby be Apple's language and API future? - pkaler
http://parveenkaler.com/2010/06/30/could-ruby-be-apples-language-and-api-future-3/

======
chc
I've heard people suggest this before, but Apple doesn't seem to feel the same
way. Ruby (even MacRuby) is banned on the iPhone along with every other
language that isn't C or Javascript. Apple plays things close to the chest,
but banning a language that you intend to base the whole platform around just
doesn't make sense.

Syracusa isn't wrong that Objective-C is getting long in the tooth, but Apple
has shown more interest in incrementally improving Objective-C than replacing
it.

~~~
joe_the_user
Yeah,

Also, it seems a bit ironic for whoever is developing MacRuby. You're donating
labor to a company that gives nothing away for free or even cheap. Then they
ban you. Makes you think ... perhaps you should target Ubuntu next time...

~~~
tlrobinson
I believe MacRuby is developed primarily by Apple employees.

~~~
joe_the_user
I guess that's an explanation...

------
bad_user
> _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.

~~~
wglb
I am quite interested in the topic of java vs C++ and java vs C performance.
Do you have specific examples that I can run down?

------
dman
I dont see any concrete evidence that suggests Apples shift from Objective C
in the linked article. Can you point to specific information that points to
such a move. fyi pypy has a LLVM backend, as does haskell, I believe python is
supported in Xcode too. Hence a similar article could have been written about
Apple moving to python.

~~~
panic
Apple is sponsoring the development of MacRuby. It's not sponsoring pypy or
Haskell LLVM backends.

~~~
ynniv
Just because they "sponsor" MacRuby doesn't mean they favor ruby as a
replacement for Objective-C. Until ruby is as fast as Objective-C, I see no
reason they would make such a change. Low performance languages have never
gained serious adoption on embedded platforms, which includes _everything that
has made Apple, Inc (not Computer) successful_.

Maybe I'm a non-believer, but I also don't see any benefit to Apple supporting
ruby specifically. If they were to have a higher-than-objc level API, I expect
it to be an LLVM API which would be compatible with languages with an LLVM
backend.

~~~
lurch_mojoff
Measuring and comparing the "fastness" of a language is a tricky thing in
general, but I think it is safe to say that for most intents an purposes we
can consider MacRuby just _as fast as_ Objective-C. The point you seem to be
missing is that both run on top of the same runtime and both use the same
foundational classes. So the same operation performed on a MacRuby String and
Objective-C NSString should take exactly the same amount of time.

The only thing that prevents MacRuby from being fully compatible with Apple's
"embedded platforms" is the lack of garbage collector on said platforms. By
the time MacRuby is sufficiently stable and optimized Apple's portable devices
will be capable of comfortably running memory managed code.

As for the "LLVM API", for one, I don't really understand how is that supposed
to work - there is no "native" LLVM language and so on; for two, such an API
will be lower-than-objc, not higher; and for three, reimplementing Cocoa and
CocoaTouch as some new supposedly more abstract (whatever that's supposed to
mean) API is going to be a monumental and almost certainly very disruptive
task - and all of it for no good reason.

A lot of the comments, I'd say yours included, seem to be coming from the
presumption that Apple's adoption of a higher level than Objective-C language
is inevitably going to be a huge overnight change. But the beauty and genius
of MacRuby is precisely that it does not require a huge overnight change. You
can mix and match Ruby and Objective-C as you need or like. You can write high
level, terse code using the HotCocoa wrapper or you can fall down to the
nitty-gritty OS X C APIs, for a good number of which there are MacRuby
bindings.

~~~
bad_user
> _I think it is safe to say that for most intents an purposes we can consider
> MacRuby just as fast as Objective-C_

It isn't. MacRuby is much more dynamic than the dynamic part of Obj-C, not
taking into account that Obj-C really is a superset of C.

------
danudey
I can't really see Apple doing this, if for no other reason than Objective-C
is something they can control, and Ruby isn't. If the core Ruby developers
decide they want to add more features, change the language's underpinnings,
etc. Apple's left to play catch-up. If Apple wants to add features, then they
basically have to fork the language and hope their changes get merged in.

Apple's shown (and been shown) how much of a benefit it is to control your own
destiny; even with Ruby being open-source, it's still an outside influence
they have to work with or against. Objective-C, for all intents and purposes,
is their language, one they can take in any direction they want.

~~~
Niten
So? Apple didn't control GCC, either, when they built OS X on top of it.

~~~
gaius
Yet Apple is doing everything they can to make themselves independent of GCC.

<http://en.wikipedia.org/wiki/Clang>

------
gfodor
This would be all kinds of awesome, but I think it's probably a dream. To leap
from ObjC to Ruby would be a absolutely massive undertaking for them.

That said, they've pulled off crazier shit before.

~~~
Niten
Not at all. Given that they're both dynamic programming languages with runtime
dispatch, there's really little impedance mismatch between Ruby and
Objective-C. Thus MacRuby, a Ruby implementation that encapsulates Objective-C
objects and messages in Ruby objects and methods. Cocoa in Ruby without a
bridge -- it's already there, it's a done deal.

Now as for whether they'd _replace_ Objective-C with MacRuby, no, that
wouldn't make sense. The two would live side by side. Apple can continue to
implement Cocoa frameworks and core applications in Objective-C while also
offering an excellent Ruby programming environment built on top of that.

It's sort of like C# vs. F# or IronPython in the .NET world -- Microsoft
didn't have to replace the base .NET assembly implementation language (a.k.a.
"assembly language for CLR") in order to provide more attractive dynamic or
functional languages on top of the same infrastructure.

EDIT: In fact, the semantic mismatch between Objective-C and dynamic languages
like Ruby is less than the mismatch between dynamic languages and the CLR,
which mirrors the statically-typed semantics of C#. Is Apple's combination of
the Objective-C type and dispatch systems and LLVM going to one-up .NET from a
direction that we didn't see coming?

~~~
kevingadd
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.

~~~
dchest
OK, but it's already implemented: <http://www.macruby.org>

------
vault_
I think there are two big reasons that Ruby isn't on the iPhone. For one,
MacRuby is still in development and isn't stable yet. For another, the
Objective-C GC isn't running on the iPhone, which is what MacRuby uses. As the
project matures and the iPhone gets better hardware, I think Ruby will start
to show up on it.

------
openfly
You really can't avoid native execution if you want to really push the
frontiers on these devices. And because these are such small devices even lone
developers can really push boundaries and make money and a name for
themselves. But the second you start blindly "optimizing" their products, bad
things happen in spades.

In my opinion implementing a VM purpose built for a specific language spec is,
was, and ever shall be a mistake. Sun was wrong to do it with the original
JVMs. In this regard at the very least Dalvik is ahead of the game. The
problem of course is, however, that implementing any VM at all on an embedded
device results in crap performance from all apps executing through it. The
reason Apple chose to remove multitasking and force C# down people's throats
was simply because it's the only way to develop an application that is sturdy
and fast on an embedded device today. Claiming it frees the developer from
having to optimize their code betrays your ignorance of developing on embedded
devices.

------
rbranson
Yes! This is so obvious to me. Why would they even bother with MacRuby if this
wasn't the future of iOS development? What would bring more developers to iOS
than a rapidly growing language that you can learn and apply to multiple
platforms, and also to arguably the best web development environment out
there? Objective C's message-passing is extremely compatible with Ruby. A
high-performance, pre-installed, officially-supported Ruby implementation
would be a huge edge over the drudgery of Java on the Android platform!

Yes, I am aware of Ruboto, but there is going to have to be some serious
wrapping of the very extensive Android APIs to make them palatable to Ruby
developers.

------
Niten
MacRuby apparently performs quite well, at least in this stage of its
development. What would be really interesting is if this translates into real-
world Rails/Sinatra/whatever performance gains significant enough to create
demand for OS X hosting...

------
mkramlich
speaking as someone who wuvs Python and dislikes both Ruby and Objective-C I
hope the answer is no :)

~~~
dazzawazza
Unlike (I suspect) a lot of people here I don't mind Objective-C and I really
dislike Ruby.

Would this effect my decision as to whether I develop for the iOS/OSX
platform. No of course not.

At the end of the day I actually dislike all languages, just to varying
degrees. Python is the one I dislike the least. As soon as I can get my
programming job done without the need for programming I will do it.

------
ihodes
Unlike many of the other commentators, this seem feasible enough, given
another year or so and some progress in terms of performance and the API.

I think it’d be great to have the option to write Mac apps in Ruby instead of
in Obj-C, and it seems rather Apple-like to be the first to having a language
like Ruby be a primary/supported system language. Wouldn’t mind seeing a Lisp
there instead, but Ruby's a bit of the way there, at least!

------
ynniv
If Apple cared about having a more friendly API language, they wouldn't have
deprecated the Java bridge: [<http://cocoadevcentral.com/articles/000024.php>]

The only languages Apple has ever expressed a preference for are Pascal, C,
Objective-C, C++, and JavaScript. Why would they add ruby when they already
have JavaScript?

~~~
kevbin
Once upon a time Java was a "co-equal" with its own colored box. But Apple's
been pretty mercurial when it comes to languages: Clascal, Object Pascal,
AppleScript, ScriptX, SK8, NewtonScript, HyperTalk, Dylan, MCL,
{AppleSoft|Integer|Mac} Basic, Smalltalk, Java, Corba IDL... most of those are
way more friendly than Java, but died just like desktop Java. MacRuby's a
little different, I'm guessing it's a research project to see what might be
compelling about a unified, llvm-based, multiple-language runtime.

------
gaiusparx
I believe Obj-C will always be what Apple build their API frameworks. But it
is possible that MacRuby will be an option in future for programming on iOS
like it is on Mac OSX.

When I heard of MacRuby, I had this immediate crazy thought that Apple choose
Ruby to piss off Google :-) You know Apple vs Google and Ruby vs Python, and
Google is basically a Python house.

~~~
draegtun
_Google is basically a Python house_

Google is basically a C++, Java, Python and Javascript shop :) ref:
<http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html>

Be interesting to see if _Go_ sneaks into that list.

------
prodigal_erik
They just took a big hit in the nerd press for banning twenty years' progress
in programming language design. I think they want an iOS development process
painful enough that only committed specialists (who double as evangelists) can
manage to ship, because everyone else would tend to write portable code that
runs on competing platforms.

------
aufreak3
This article seems very very speculative. For instance, I don't think the
blocks implementation in ObjC is adequate as a _full_ closure implementation.
It certainly looks like Apple is trying to improve the language while
continuing to remain "close to the metal" using C without the need for
bridges.

------
gmosx
Nah, I think Apple has already chosen JavaScript. Don't forget, Apple actually
spearheaded the HTML5 movement...

~~~
jasonlotito
> Apple actually spearheaded the HTML5 movement...

Hahaha, that was good. =)

~~~
gmosx
good and _true_ , html5/css3 innovation started with Apple's work on webkit.

------
paulnelligan
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.

~~~
lenary
indeed. especially as people inside apple have already built web apps using
RoR in the past. one that comes to mind is the application they use for
enterprise managing lots of iphones (i can no longer find it, but i assume
it's still around)

------
cageface
It seems extremely unlikely that Ruby will _displace_ ObjC. I can imagine that
it will become the blessed _scripting_ language for the Mac, in something like
the way that Visual Basic has been for Windows.

Either way I'm glad to see Apple's support behind Ruby.

------
sovande
Hardly, Apple need a compiled language for its mobile platform that does not
do managed memory. But it may replace applescript.

------
aaronbrethorst
Answer: No.

MacRuby is awesome, but it'll likely eventually suffer the same fate as the
Java Bridge.

~~~
demallien
No, that's probably wrong. With MacRuby, bridging is toll-free, and, as others
have noted already, there is a much lower impedance mismatch between ruby and
objective c than there was between java and objective c. Apple has improved
the support for scripting languages over the years with the introduction of
the scriptingbridge framework. These days, you can easily write an app on the
mac in either ruby or python, the only constraint is that things become a mess
if ever raw c structs are exposed by the cocoa api (and yes, there are still a
few places where this is the case), or worse still when there is no cocoa api
for a particular framework. Still, even in these cases there us some support
in the scripting bridge framework, although my personal preference for this
type of problem is just to wrap the c code in an objective c wrapper class
before using the wrapper class from within MacRuby. Works like a charm!

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

------
alexkiwi
The world isn't ready for iPhone on Rails.

~~~
stcredzero
Yes, but isn't Rails one of the best ways to quickly deliver iPhone web apps?

------
c00p3r
It would be cool if they will sponsor some effort to marry ruby and llvm. ^_^

~~~
ptomato
You mean like MacRuby, say?

~~~
c00p3r
Did they already replace Matz MRI to LLVM-based one which can pass all ruby-
spec? ^_^

~~~
chc
The original interpreter is already replaced with YARV in 1.9. But yes,
MacRuby replaces YARV with an LLVM-based virtual machine. (Only passes about
85% of RubySpec right now, though.)

Incidentally, Rubinius is also based on LLVM these days.

~~~
c00p3r
Such a fundamental changes like unladen swallow in python or migrating to
LLVM-based VM in ruby must be backed by very powerful and resourceful entity.
Good news!

------
bhiggins
Ruby is an impractical language so, no.

