What I'd like to suggest is the following:
1. Define clear goals for MacRuby that we can easily evaluate:
- Focus primarily on making MacRuby the tool to use for quickly prototyping OS X and iOS applications.
This is the wrong thing for "MacRuby" to focus on, in my opinion. I've been watching MacRuby be developed over the years, and liked everything I saw on the blog post updates for new releases, but I never understood the focus on trying to build complete applications with it, and trying to simplify the Cocoa frameworks by including wrappers. These are two separate (but related) projects. MacRuby should be a *foundation* for which those kinds of projects can be built upon, but it shouldn't be a main goal of the MacRuby project itself. Creating a bulletproof Ruby which is completely compatible with the official version (when using plain Ruby code), where you can use Obj-C<--->Ruby as needed, with leanings towards increasing performance where possible, is a challenge in itself, and a very worthy goal. I'm a full time Cocoa developer and have done many Mac and iOS apps. If anything, the thing that makes it "difficult" to prototype Mac/iOS apps is not Objective-C, it's the structure and learning curve of the Cocoa frameworks. Particularly on iOS, the view controllers are specialized with specific purposes and usage patterns and you need to know about and understand those to use them properly. Objective-C doesn't get in the way of that. Connecting some view controllers together, dropping in images, hooking up buttons to transition between the view controllers etc, all of that involves a trivial amount of code. If you already know Objective-C then there's zero benefit to using Ruby to prototype instead. If you *only* know Ruby, then sure, using Ruby might make it possible for you to prototype an app, but the more significant barrier is still the frameworks. I should preface this by saying I'm also a Rubyist so it's not just a blindly biased opinion. I use Rails, have complex Ruby-only code for massaging and dealing with a lot of data, and have written code bundles in C and Obj-C to connect with Ruby via C bindings to do performance-critical code. Now, personally, I don't want to write a Cocoa app in Ruby. The tools Apple ships (Xcode, Instruments, etc) all work great with Obj-C and help me stable and performant code. Using Ruby as the main language of development in my application only makes it more difficult for me to debug and keep performance up when it matters. Sure, simple applications can be written in Ruby and all the power to those who want to do that, but to me it's not what MacRuby is for. MacRuby may be a *part* of that solution, but if it's for a prototyping, that would be best served by a separate MacRuby-based framework and GUI application. What MacRuby is to me: MacRuby to me, is interesting in a few ways: 1) Performance — Using llvm to JIT Ruby to native code, plus libauto was supposed to yield a notable performance increase over the standard Ruby. Now, Ruby has come a long way since <= 1.8 in performance, so how significant these potential gains are now, I am unsure, but in the applications we have, performance matters. 2) In the Mac applications I do write, there are several possibilities for me to use Ruby. Let's say for example, I want to allow my user to be able to use Ruby to write "plugins" for my application. This capability would be for any user to implement a custom process, using Ruby to directly work with Cocoa objects that get used in the application. This would require no compiling on the user's part, I wouldn't have to write a ton of C bindings glue to connect Cocoa and Ruby — it would just work. 3) Sometimes in our Ruby projects, it would be oh-so-convenient to be able to use Obj-C frameworks to get something done — Again, with no need to write C bindings. Say I need to get at the stuff in the address book, want to use methods available to NSString/NSCharacterSet/etc because it's faster, or better yet use Quartz to do graphics rendering from my Ruby code. 4) Another thing that interested me, is shipping an actual binary. Say I have some proprietary code written in Ruby and I want to ship this to clients (specifically running on Mac OS X). I obviously don't want to be passing out my source code. With MacRuby, I want to be able to effectively compile my Ruby code and have a binary I can ship out. It's mainly the performance and interoperability between Ruby and Obj-C the makes up what MacRuby is to me. Not using it for prototyping or building entire Mac/iOS applications. My two cents. -- Seth Willits