views:

518

answers:

8

I was wondering what's the point of using Ruby (or even Python) in Cocoa application development other that not learning Objective-C (which is pretty simple language and will not take to more than few days to learn). I'm new to this and I'm interested why people do this? What are Pros and Cons.

+7  A: 

I think the point of it is some people would prefer to program in Ruby than Objective-C, simple as that.

Ruby features duck-typed objects which makes it a good fit for the Cocoa frameworks (whereas a C++ or Java or C# binding isn't).

U62
+7  A: 

Regardless of the language (ObjC, Ruby, Python), developers still have to learn the cocoa framework.

As you point out, one advantage in using Ruby or Python is that it may abate the learning curve a bit for developers who are already experienced in those languages, but who may not be as familiar with C and Objective-C.

Primarily, though, I think folks find that they can:

  • do rapid prototyping using PyObjC or RubyCocoa
  • use existing business logic code written in one of those languages, without having to port it to ObjC (particularly useful if you have core code in your app that you re-use on multiple platforms)
  • use some of the easy APIs available in those languages. For example, cocoa offers no built-in CSV parser (you have to roll your own, or cobble something together from the endless home-brew parsing projects on the web), whereas Python has one out of the box - I'm sure Ruby has one too, I'm just not that familiar with Ruby's API.

Of course, I agree with you: objective-c is fun! Now that Apple makes it so easy to use other languages, though, it's nice to have options :-)

Jarret Hardie
+2  A: 

Neither Ruby nor Python Cocoa-Apps need compilation, the languages have much more powerful constructs like literals for collection types, co-routines, list-comprehensions.

They have proper garbage collection, which works very well with ObjectiveC's reference-counting scheme without the programmer needing to think about it.

Python at least (Ruby most probably as well, but I don't know it much) has e.g. numerical processing libs that aren't available for objective C - granted, you can use C or C++, but that's much more cumbersome.

All this comes with a price-tag of course: execution speed. But then, GUI-apps are more about gluing things together, not about raw processing performance.

And lets not forget - as cool as ObjectiveC is - it still has a lot of C in it.

+3  A: 

One reason I use scripting languages in my Cocoa apps is for using function closures (specifically from JavaScript). They make doing asynchronous programming much easier, and as a result I tend to use it a lot in controlling networking operations.

Steve Streza
+5  A: 

This question is a bit like "Why use Objective-C? You can call into Cocoa using assembly instructions just fine. Do people just not want to learn assembly?"

I know Objective-C. I learned it years before Ruby. But I like Ruby better. It's more elegant in my eyes. Compare the same class in both languages:

Ruby:

class Toaster
  attr_accessor :heat_level

  def initialize() @heat_level = 0 end

  def toast(*toasts)
    toasts.each {|toast| toast.become_toasty if heat_level > 5}
  end
end

Objective-C:

// Toaster.h
#import <Cocoa/Cocoa.h>

@class Toast;
@interface Toaster : NSObject
{
    int heatLevel;
}

- (void)toastToast:(Toast *)toast;
- (void)toastToasts:(NSArray *)toasts;

@property(readwrite, assign) int heatLevel;
@end

// Toaster.m
#import "Toast.h"

@implementation Toaster
@synthesize heatLevel;

- (void)toastToast:(Toast *)toast
{
    if (heatLevel > 5)
    {
        [toast becomeToasty];
    }
}

- (void)toastToasts:(NSArray *)toasts
{
    for (Toast *toast in toasts)
    {
        [self toastToast:toast];
    }
}
@end

The entire Ruby class is fewer LOC than Toaster.h! It can be quite nice to write in a language like that. I'm not trying to hate on Objective-C — I still use it, and it's really not bad. But Ruby is simply a more powerful language, and that's why people might like to write in it. Objective-C gives up a lot for the sake of speed and C compatibility.

On the other hand, the RubyCocoa bridge is far from perfect. There are a lot of subtle "gotchas" where something you do doesn't sit well with the bridge and you'll be stuck Googling for 30 minutes to try and figure out what it was, eventually discovering that you foolishly followed the RubyCocoa convention of putting a _ in place of an Obj-C : the one time it doesn't want you to. That's a pretty big con. You also mostly have to give up multithreading, and it's a lot easier for people to see your source code.

Chuck
A: 

I don't see benefits in using RubyCocoa - it's still under development and there is practically no active forums on problems, that may come up. You're on your own. May be it's elegant language and the code is shorter, but it doesn't make my life easier if i need google for hours looking for an answer... BTW RubyCocoa 0.13.2 leaks, i tried to pay attention of those responsible - no success. 1.1.0 crashes my application on the very beginning. So if you have a choice - use cocoa.

Nava Carmon
+4  A: 

Don't forget MacRuby. It's the fastest Ruby yet and runs on top of the Objective-C runtime. It's open source and is supported by Apple. An Apple employee heads the project and is leading development.

Rod Schmidt
A: 

Try to see this the other way around. The XCode platform comes with a whole lot of extra's, one of the sweetest part is the Interface Builder. You can easily 'draw', 'drag & drop' and 'stylish' an user interface for the OSX platform. There is a lot more to say about XCode, but it will fall out of this scope. The Ruby-bindings allows coders to reuse code, develop methods like they are used too.

If you think Objective C will do the works for you, surely go ahead. However, if you would be already developing with Ruby (Rails, Ramaze, etc.) there is no need to dive into Objective C, because RubyCocoa does just fine for RAD. By the way, learning the basics of a new language takes more than just same days. Good judgement comes from experience...

Shyam