12 ms·

Could Ruby be Apple's language and API future?

64 points by pkaler 16y ago

dman 16y 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 16y ago
  Apple is sponsoring the development of MacRuby. It's not sponsoring pypy or Haskell LLVM backends.
  - deleted 16y ago
    [deleted]
  - ynniv 16y 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.
    - lurch_mojoff 16y ago
      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 16y ago
        > 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.
    - mattetti 16y ago
      Btw, Apple is not "sponsoring" MacRuby. Apple is developing MacRuby, it's an Apple project. Will it replace Obj-C? Probably not. Will it become a blessed alternative? Everything seems to point in that direction.
      - caljunior 16y ago
        Could not agree more. MacRuby exists, it's great. Use it. Who cares whether or not it will replace or complement Obj-C, sliced bread or even the internal combustion engine. GC is the key to the iOS port. Not there yet, so no option at the moment. Of course the future (maybe distant, maybe near) will bring GC to iOS and MacRuby with it. No need for reinventing the wheel.
gfodor 16y 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.
- chc 16y 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.
- AndrewO 16y 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.
- Niten 16y 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?
prodigal_erik 16y 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.
chc 16y 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.
- AndrewO 16y 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).
  - chc 16y 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.
    - AndrewO 16y ago
      Just remember that we're talking about a company that managed to migrate its entire product line to an entirely new processor with few people (inside and outside the company) really knowing until they unveiled the first demo machines. Compared to that, adding a new programming language (that doesn't even affect their existing 3rd party applications) to a platform they own completely is child's play.
alexkiwi 16y ago
The world isn't ready for iPhone on Rails.
- stcredzero 16y ago
  Yes, but isn't Rails one of the best ways to quickly deliver iPhone web apps?
  - deleted 16y ago
    [deleted]
    - chc 16y ago
      Flash was never a good way to write a Web app for iPhone, given that no Web browser on the iPhone can view it.
      - deleted 16y ago
        [deleted]
danudey 16y 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 16y ago
  They control MacRuby, and indeed have added new syntax. MacRuby is actually not forwards compatible with regular ruby.
- Niten 16y ago
  So? Apple didn't control GCC, either, when they built OS X on top of it.
  - gaius 16y ago
    Yet Apple is doing everything they can to make themselves independent of GCC. http://en.wikipedia.org/wiki/Clang http://en.wikipedia.org/wiki/Clang
- ged 16y 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_ 16y 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 16y 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.
deleted 16y ago
[deleted]
bhiggins 16y ago
Ruby is an impractical language so, no.
c00p3r 16y ago
It would be cool if they will sponsor some effort to marry ruby and llvm. ^_^
- ptomato 16y ago
  You mean like MacRuby, say?
  - c00p3r 16y ago
    Did they already replace Matz MRI to LLVM-based one which can pass all ruby-spec? ^_^
    - chc 16y ago
      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 16y ago
        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!
  - c00p3r 16y ago
    btw, how could I run this on Linux or FreeBSD? ^_^
cageface 16y 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 16y 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 16y ago
Answer: No. MacRuby is awesome, but it'll likely eventually suffer the same fate as the Java Bridge.
- demallien 16y 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!
Niten 16y 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 16y ago
speaking as someone who wuvs Python and dislikes both Ruby and Objective-C I hope the answer is no :)
- dazzawazza 16y 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.
ynniv 16y 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 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 16y 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 16y 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 16y 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 16y 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 http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html Be interesting to see if Go sneaks into that list.
sovande 16y ago
Hardly, Apple need a compiled language for its mobile platform that does not do managed memory. But it may replace applescript.
paulnelligan 16y 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 16y 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_user 16y 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 16y 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 16y ago
Ruby may at some point be an optional language but it's not going to replace Objective-C.
gmosx 16y ago
Nah, I think Apple has already chosen JavaScript. Don't forget, Apple actually spearheaded the HTML5 movement...
- jasonlotito 16y ago
  > Apple actually spearheaded the HTML5 movement... Hahaha, that was good. =)
  - gmosx 16y ago
    good and true, html5/css3 innovation started with Apple's work on webkit.
openfly 16y 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.

64 points by pkaler 16y ago

dman 16y 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 16y ago
Apple is sponsoring the development of MacRuby. It's not sponsoring pypy or Haskell LLVM backends.
- deleted 16y ago
  [deleted]
- ynniv 16y 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.
  - lurch_mojoff 16y ago
    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 16y ago
      > 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.
  - mattetti 16y ago
    Btw, Apple is not "sponsoring" MacRuby. Apple is developing MacRuby, it's an Apple project. Will it replace Obj-C? Probably not. Will it become a blessed alternative? Everything seems to point in that direction.
    - caljunior 16y ago
      Could not agree more. MacRuby exists, it's great. Use it. Who cares whether or not it will replace or complement Obj-C, sliced bread or even the internal combustion engine. GC is the key to the iOS port. Not there yet, so no option at the moment. Of course the future (maybe distant, maybe near) will bring GC to iOS and MacRuby with it. No need for reinventing the wheel.

gfodor 16y 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.

chc 16y 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.
AndrewO 16y 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.
Niten 16y 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?

prodigal_erik 16y 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.

chc 16y 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.

AndrewO 16y 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).
- chc 16y 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.
  - AndrewO 16y ago
    Just remember that we're talking about a company that managed to migrate its entire product line to an entirely new processor with few people (inside and outside the company) really knowing until they unveiled the first demo machines. Compared to that, adding a new programming language (that doesn't even affect their existing 3rd party applications) to a platform they own completely is child's play.

alexkiwi 16y ago

The world isn't ready for iPhone on Rails.

stcredzero 16y ago
Yes, but isn't Rails one of the best ways to quickly deliver iPhone web apps?
- deleted 16y ago
  [deleted]
  - chc 16y ago
    Flash was never a good way to write a Web app for iPhone, given that no Web browser on the iPhone can view it.
    - deleted 16y ago
      [deleted]

danudey 16y 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 16y ago
They control MacRuby, and indeed have added new syntax. MacRuby is actually not forwards compatible with regular ruby.
Niten 16y ago
So? Apple didn't control GCC, either, when they built OS X on top of it.
- gaius 16y ago
  Yet Apple is doing everything they can to make themselves independent of GCC. http://en.wikipedia.org/wiki/Clang http://en.wikipedia.org/wiki/Clang
ged 16y 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_ 16y 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 16y 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.

deleted 16y ago

[deleted]

bhiggins 16y ago

Ruby is an impractical language so, no.

c00p3r 16y ago

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

ptomato 16y ago
You mean like MacRuby, say?
- c00p3r 16y ago
  Did they already replace Matz MRI to LLVM-based one which can pass all ruby-spec? ^_^
  - chc 16y ago
    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 16y ago
      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!
- c00p3r 16y ago
  btw, how could I run this on Linux or FreeBSD? ^_^

cageface 16y 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 16y 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 16y ago

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

demallien 16y 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!

Niten 16y 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 16y ago

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

dazzawazza 16y 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.

ynniv 16y 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 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 16y 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 16y 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 16y 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 16y 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 http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html Be interesting to see if Go sneaks into that list.

sovande 16y ago

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

paulnelligan 16y 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 16y 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_user 16y 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 16y 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 16y ago

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

gmosx 16y ago

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

jasonlotito 16y ago
> Apple actually spearheaded the HTML5 movement... Hahaha, that was good. =)
- gmosx 16y ago
  good and true, html5/css3 innovation started with Apple's work on webkit.

openfly 16y 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.