macOS RubyCocoa: good idea to program 100% in ruby?

[jstad]

I was curious if it was a good idea or not to program an entire program (lets say bank software) in RubyCocoa. I have had this debate for awhile with some of my fellow Comp Sci majors at my university. The part we are worried about is the overhead and memory management of Ruby. I know that with the next version of Ruby that it is going to get a speed increase but will that really matter? Also since ruby began and still somewhat is a scripting language, wouldnt it be a bad idea to use it as the base for a program?

The reason we are not doing Objective-C is because we want to use the Cocoa framework on OSX but we want to use other GUI frameworks depending on the platform. We considered Java briefly but since Apple took it out of its update cycle for Cocoa, it was quickly abandoned.

If not RubyCocoa, what would you use? (Trying to avoid Obj-C for minimal re-write per platform)

 

[kainjow]

If you are going to use Ruby, wait for Leopard.

 

[garethlewis2]

The same rubbish argument about overhead and garbage was bandied about in the 80s with NextSTEP using Objective-C instead of C++.

If you are writing a program with Cocoa, 90% of your computing time is going to be waiting for user input.

 

[HiRez]

Nothing wrong with Ruby, like many former "scripting" languages, it is now a real programming language. But a few reasons why you might not want to go this route:

1. I don't trust Apple to support Ruby in the future (see what happened to the Java bridge). This doesn't mean you can't use it, but some things you come to rely on could get complicated later.

2. If you need to be cross-platform, you'll be losing a lot of what makes Cocoa great, such as Bindings, Core Data, and newer things like Core Animation. Sure, you could use these things on the Mac and write other solutions for other platforms, but your code could get messy.

You might look into an all-web solution like RoR/Ajax, or Adobe Apollo/Flex. If your application fits it, you can do some pretty nice, dynamic interfaces with these nowadays and not have to deal with cross-platform headaches. Apollo will also let you deploy as a cross-platform, double-clickable desktop application.

 

[jstad]

Nothing wrong with Ruby, like many former "scripting" languages, it is now a real programming language. But a few reasons why you might not want to go this route:

1. I don't trust Apple to support Ruby in the future (see what happened to the Java bridge). This doesn't mean you can't use it, but some things you come to rely on could get complicated later.

2. If you need to be cross-platform, you'll be losing a lot of what makes Cocoa great, such as Bindings, Core Data, and newer things like Core Animation. Sure, you could use these things on the Mac and write other solutions for other platforms, but your code could get messy.

You might look into an all-web solution like RoR/Ajax, or Adobe Apollo/Flex. If your application fits it, you can do some pretty nice, dynamic interfaces with these nowadays and not have to deal with cross-platform headaches. Apollo will also let you deploy as a cross-platform, double-clickable desktop application.

I dont know if you can answer this or not, but what makes a language a scripting language or a "full-fledged" language? This is more of a techincal question than a general "scripting languages are used for quick development" stuff.

 

[HiRez]

I dont know if you can answer this or not, but what makes a language a scripting language or a "full-fledged" language? This is more of a techincal question than a general "scripting languages are used for quick development" stuff.

I can't say what the technically correct answer would be, but I would think things like advanced loop and iteration handling, direct byte access to binary data, objects, encapsulation, exceptions, extensive support for various common heterogenous collection classes (array, hashtable, set, tree) with a unified API, and good debugging capabilities, would all be factors. In fact, that actually makes C, which some would consider the mother of all modern "real" programming languages, seem rather feeble by comparison. I guess it depends on how you feel about garbage collection, as it might be a big positive for some folks and a big negative for others.

Certainly each language has their specialty. C is fast and efficient. Ruby and Python are better at handling strings and collections natively. And much of what we think of when we think of a language is what APIs are available for it, although they're often separate. You can program in Objective-C without Cocoa, but very few people do nowadays. Personally I consider any language that you can use to program a complex, modern application to be a "real" programming language (that could be web-based or desktop-based). In that sense, I suppose there are very few "scripting" languages left. Ruby, Python, Perl, PHP, and others have all added features over the years to fill most of the holes they might have initially had. You can even program a complex application in AppleScript, although that one is still a unique oddball (alternatingly frustrating and wonderful for me).

Anyway, that's one of the things I like about programming on the Mac in Xcode. I can take bits and pieces from a dozen different languages and APIs and rather easily use them all in the same application, if I have to.

 

[garethlewis2]

I dont know if you can answer this or not, but what makes a language a scripting language or a "full-fledged" language? This is more of a techincal question than a general "scripting languages are used for quick development" stuff.

This is another question that gets asked a lot and the answer is completely obvious, but so obvious that the thinker decides to ignore it.

Scripting languages are full-fledged languages. They can do anything that a language like C, C++ or Objective-C can do. The biggest difference being the latter are interpreted and the former are compiled.

What the question should be is. What makes language X more suitable for a problem domain than language Y. Would you attempt to write an OS in Ruby? Of course not. Where would the runtime that executes the interpreter be run?

 

[janey]

Idly reading around, I came across a blog entry a while back vaguely mentioning RubyCocoa and something new called Nu (har har), and so maybe you'd be interested:
http://importantshock.wordpress.com/2007/08/12/how-tim-burks-and-nu-stole-the-show-at-c41/

 

[garethlewis2]

There's a language that is going to die horribly. 99% of the MacRumors developers will get excited. Download Nu. Realise they are horrendously underdeveloped in the academic programming area, and go back to <<insert language here>>

 

[WildPalms]

If you are going to use Ruby, wait for Leopard.

Why wait for Leopard?

 

[kainjow]

Why wait for Leopard?

Ruby will have an official bridge to Cocoa in Leopard.

From Apple's website:

Mac OS X is now the ideal platform for all kinds of script-based development. Ruby 1.8.6 and Python 2.5 are both first-class languages for Mac development, thanks to Cocoa bridges, Xcode and Interface Builder support, DTrace monitoring, and Framework builds — as well as AppleEvent bindings via the new Scripting Bridge.

 

[WildPalms]

Ruby will have an official bridge to Cocoa in Leopard.

From Apple's website:

Ahhhh. Gotcha.

 

[hhas]

Ruby will have an official bridge to Cocoa in Leopard.

The "official" Ruby-Cocoa bridge is RubyCocoa. All Apple have done is get behind an existing OSS project, provide some assistance with developing and polishing it, and bundle a recent copy with Leopard. Ditto with PyObjC for Python.

It's great that Apple are giving their official blessing to these projects, but let's not get carried away by Apple marketing pitch. The only direct technical benefit for developers is that they'll now have the extra option of using Leopard's bundled Ruby and RubyCocoa to produce more compact standalone applications, whereas previously they had no other choice than to include these dependencies in their application bundles, increasing distribution size by several MB.

Developers who wish to use the latest and greatest Ruby/RubyCocoa releases, or who require their applications to be portable between OS versions, will no doubt continue to use the latter approach regardless, and an extra few MB of download is pretty much a non-issue for broadband users (and usually tolerable for dialup users) anyway.


Either way, there's no reason why the OP shouldn't start using RubyCocoa today if they wish. That said, they may wish to consider other options as well; e.g. personally I prefer Python + PyObjC, which is a bit faster and more mature than Ruby + RubyCocoa, although the latter is catching up.

If they really want to minimise per-platform rewrites, they may be better off using a cross-platform application framework such as wxWidgets (which has bindings for several languages), or Java (which is still fully supported by Apple; all they've done is drop support for their slightly dodgy, Mac-only Java-Cocoa bindings but that doesn't stop you using existing cross-platform Java application frameworks). The only tradeoff is that cross-platform framework may not give quite the same level of Mac look-n-feel, but depending on the type of application and audience this may be entirely acceptable.

Also, w.r.t. speed concerns, don't forget that PyObjC and (IIRC) RubyCocoa are full two-way bridges while Python and Ruby both provide extensive C APIs as well, allowing you to write your initial version completely in Python/Ruby, then performance profile it and recode any performance-intensive portions using C or ObjC once you're happy with the overall design.

HTH

 

[kainjow]

The "official" Ruby-Cocoa bridge is RubyCocoa. All Apple have done is get behind an existing OSS project, provide some assistance with developing and polishing it, and bundle a recent copy with Leopard. Ditto with PyObjC for Python.

Cool, thanks for sharing. I didn't know this, although I kind of figured it was the case. I guess it's ok then to start with RubyCocoa since it's the same thing.

Developers who wish to use the latest and greatest Ruby/RubyCocoa releases, or who require their applications to be portable between OS versions, will no doubt continue to use the latter approach regardless, and an extra few MB of download is pretty much a non-issue for broadband users (and usually tolerable for dialup users) anyway.

This was my reason for waiting for Leopard, because the apps wouldn't be so bloated with the RubyCocoa libraries.

 

[ChrisA]

I was curious if it was a good idea or not to program an entire program (lets say bank software) in RubyCocoa.

If this is an interactive 'point and click" type desktop application the single most slow bottle neck is the user. He can only cause events to occur at a relativly low rate. As long as you can keep up with the mouse and keyboard why go faster?

You can also argue that a Porshe is fater then my old pickup truck. But you know what? I don't get home from work faster in the Porshe. The car's top end speed is not what is determining my travel time. Same here. Nothing happens until the user clicks "OK" so what would a faster program do? Only spend more time in a idle loop sleeping. Once your software can "keep up with traffic" it does not need to go faster.

OK there are exceptions, some user interface stuff is computationaly expensive. "Cover Flow" comes to mind. but banking is mostly not that.

But on the other hand If that software ran at the bank you'd care a bit more about performance as it would be doing more then just waiting for the user to do something.

Most of what happens on the desktop is just waiting for input from the user.

 

[hhas]

This was my reason for waiting for Leopard, because the apps wouldn't be so bloated with the RubyCocoa libraries.

FWIW, including Python and PyObjC in a 32-bit UB application adds approx 4MB to the .dmg size (e.g. 4.5MB vs 0.5MB), and I imagine the numbers are similar for a Ruby-based application. Whether or not this is a issue will depend on the type of project, audience and/or distribution method. e.g. I've written several standalone PyObjC-based utilities for Python/Ruby/AppleScript users and not had any complaints so far. OTOH, if just it's a ten-line script that folk'll run once and throw away, or a popular application that gets a million downloads and you're paying all your own hosting bills, distribution size may be more of an issue.

HTH

 

[Alloye]

I was curious if it was a good idea or not to program an entire program (lets say bank software) in RubyCocoa. I have had this debate for awhile with some of my fellow Comp Sci majors at my university. The part we are worried about is the overhead and memory management of Ruby. I know that with the next version of Ruby that it is going to get a speed increase but will that really matter? Also since ruby began and still somewhat is a scripting language, wouldnt it be a bad idea to use it as the base for a program?

RubyCocoa has come a long way in recent months. In addition to minimizing the semantic differences between Ruby and Objective-C, they've also greatly reduced the performance penalty for crossing the bridge. My advice would be to do a little prototyping with it and see how you feel about the results.

 

[Alloye]

There's a language that is going to die horribly. 99% of the MacRumors developers will get excited. Download Nu. Realise they are horrendously underdeveloped in the academic programming area, and go back to <<insert language here>>

Been there, done that.