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: "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. 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... -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Technical editing and writing, programming, and web development