The result we're looking for (IMHO) is a way to write Cocoa apps that "look right" to Ruby programmers. The number of Objective-C programmers who don't work on OSX apps is vanishingly small.
By opening up OSX programming to MacBook-carrying Rubyists, Apple can grow its developer base in relatively short order. Jordan's "artist cum programmer" folks may follow along, but the Rubyists (and some book authors) will have to pave the way.
More than one step will be needed to bridge the gap between ObjC- based OSX programming and the Ruby crew. First, we need a Ruby implementation with direct, efficient access to OSX functionality. For example, it should be straightforward to read about the ObjC API and then code up the appropriate MacRuby call(s). MacRuby is expected to provide this implementation.
However, this means that MacRuby code is going to look a lot like transliterated ObjC. Java and Objective-C programmers are inured to their languages' verbosity (and downright inconvenience), so they may not understand how WRONG this code looks to a Rubyist:
That's simply because at that time they don't know any better. But real rubyists will educate themselves is my experience.
"Programming in TSO is like kicking a dead whale down the beach"
-- Ken Thompson
The first step in making MacRuby look reasonable to a Rubyist is to reduce the verbosity of method names and arguments, fill in common defaults, etc. I see no problem with letting HotCocoa do this, if it does so in a well-documented and -engineered fashion.
Well actually there are a few problems with this: - First of all, it would mean hundreds of man hours to create basically just shortcuts, and then also need to be maintained. - Then there's the documentation part, you say “if it does so in a well-documented and -engineered fashion”. Which means: Someone will have to write documentation for the shortcuts _again_ because the docs already exist in Apple's Cocoa reference docs. Honestly, nobody would want to do that. Apple has a much better track record for keeping their docs up to date. - Then there's the point I tried to make earlier, but apparently failed at: Say, hypothetically, that all of Cocoa would be wrapped in shortcuts and even docs would exist. Then at some point I would like to start using other OSS Objective- C code, should I ask the maintainers to write shortcuts for that as well? Or should I simply take the effort to learn the syntax used by idiomatic Objective-C? Which really only takes 1 afternoon. Just to restate the last point: Smart rubyists _will_ be able to figure out how to use Objective-C classes in 1 afternoon, I have seen it happen many many times over the past years that I have been active in the RubyCocoa area. (Lazy people don't. But my guess is this applies in all areas.) After using it for a while, they _will_ figure out that it was best option to learn some Objective-C and cherish the big API and it's documentation provided by Apple. And let's not forget the wealth of info available through Google, all in Objective-C and it's verbose syntax.
I would also be delighted to have HotCocoa provide high-level abstractions for Cocoa (etc) functionality, cute ways to lay out windows programmatically, etc. My only real concern is that it may become unwieldy, because it is trying to do too much. So, I might suggest a bit more modularity, along the lines of Merb...
Like stated before, I hope HotCocoa will _only_ provide high level abstractions and maybe some shortcuts. Not the other way around. To put this all in perspective: - I am a rubyist pur sang, not a Java/Objective-C programmer, and never used Cocoa before RubyCocoa. - I too thought it would be a good idea to create ruby like syntax abstractions around all of Cocoa, but have realized after actually doing stuff that that would have been a cumbersome task. And more importantly, it would not have taught me to educate myself where needed. - Eloy