Could Ruby be Apple's language and API future?

http://parveenkaler.com/2010/06/30/could-ruby-be-apples-language-and-api-future-3/

by pkaler • 16 years ago

64 74 16 years ago

dman• 16 years ago

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• 16 years ago

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

ynniv2• 16 years ago

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.

gfodor• 16 years ago

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.

chc7• 16 years ago

It's not really that crazy. Take a look at MacRuby — it's pretty close already. Apple just doesn't seem to have enough interest to replace Objective-C.

AndrewO3• 16 years ago

MacRuby has already reimplemented most of Ruby's classes on top of equivalent Cocoa ones (String < NSString, Hash < NSDictionary, Array < NSArray). That removes a big part of bridging problem that existed with things like RubyCocoa.

Not to mention the ability to call existing APIs and the fact that C and MacRuby will both be running on LLVM—I think it's less crazy than it appears.

Niten6• 16 years ago

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• 16 years ago

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.

mhd• 16 years ago

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

Java/Cocoa? Java/WebObjects? Heck, we still have the "NS" prefix…

While I think that MacRuby will definitely gain some traction, I don't think they'll completely replace it any time soon.

prodigal_erik• 16 years ago

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.

chc7• 16 years ago

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.

AndrewO3• 16 years ago

Apple is fortunate that they're the only ones they have to check with to change 3.3.1. When the hardware has gotten ample and the software is mature enough, I for one won't be surprised if we see revisions.

Meanwhile, a blanket ban will accomplish their goals just fine (take your choice: blocking Adobe, preventing fragmentation, making developers choose single platforms, etc).

chc7• 16 years ago

They could change 3.3.1, but they didn't have to blanket-ban Ruby to begin with — they made already have four languages they allow. The fact that Ruby was banned shows that they don't even place it on a level with C++, much less Objective-C.

On top of that, MacRuby was just starting efforts to target the iPhone when Apple banned it, leading the developers to throw their hands in the air and say, "Oh well, didn't really get far anyway." If Apple really wants Ruby on the iPhone, stopping its own people from working on the project doesn't make any sense.

joe_the_user2• 16 years ago

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• 16 years ago

I believe MacRuby is developed primarily by Apple employees.

burriko• 16 years ago

Stating that Apple 'gives nothing away for free' is quite hyperbolic. Apple certainly contribute to open source in more ways than you're giving them credit.

See http://www.macosforge.org/ for some examples.

alexkiwi• 16 years ago

The world isn't ready for iPhone on Rails.

stcredzero• 16 years ago

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

danudey• 16 years ago

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.

jpcx01• 16 years ago

They control MacRuby, and indeed have added new syntax. MacRuby is actually not forwards compatible with regular ruby.

Niten6• 16 years ago

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

gaius• 16 years ago

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

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

ged• 16 years ago

MacRuby is a fork of the language, albeit a friendly one. Just as Rubinius, JRuby, IronRuby, and others are all forks.

I can see Apple replacing Applescript with Ruby, but just based on the fact that MacRuby uses the ObjectiveC runtime, I doubt it's really going anywhere.

vault_• 16 years ago

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.

aufreak3• 16 years ago

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.

bhiggins• 16 years ago

Ruby is an impractical language so, no.

c00p3r4• 16 years ago

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

ptomato• 16 years ago

You mean like MacRuby, say?

c00p3r4• 16 years ago

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

c00p3r4• 16 years ago

btw, how could I run this on Linux or FreeBSD? ^_^

cageface• 16 years ago

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.

ihodes• 16 years ago

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!

aaronbrethorst• 16 years ago

Answer: No.

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

demallien• 16 years ago

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!

Niten6• 16 years ago

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• 16 years ago

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

dazzawazza• 16 years ago

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.

ynniv2• 16 years ago

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• 16 years ago

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.

rbranson• 16 years ago

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.

gaiusparx• 16 years ago

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• 16 years ago

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.

sovande• 16 years ago

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

paulnelligan• 16 years ago

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• 16 years ago

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)

bad_user2• 16 years ago

> 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• 16 years ago

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?

jcollins• 16 years ago

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

gmosx2• 16 years ago

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

jasonlotito• 16 years ago

> Apple actually spearheaded the HTML5 movement...

Hahaha, that was good. =)

gmosx2• 16 years ago

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

openfly• 16 years ago

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.

Could Ruby be Apple's language and API future?

Related Stories