Hey all, I think we need to understand that this thread has been conflating two different issues: 1. Apple support for MacRuby, and 2. the future roadmap for MacRuby.
As for #1: I would respectfully suggest that if you feel you need some sort of official "blessing" from Apple in order to continue working with/on MacRuby, then your time may be better spent elsewhere. Apple is not a particularly developer-centric company, and to be honest I wouldn't put much weight on any word from Cupertino anyway. Am I the only one who remembers Dylan? (Just in case: http://en.wikipedia.org/wiki/Dylan_(programming_language) ) That said, people are using C# and other .Net languages to develop for the Mac and iPhone with no official blessing or Xcode integration. People have used Scheme/Nu for Cocoa development, and there are even alternative IDEs for working with Obj-C now. Then there's Lua. Has everyone seen Codea ( http://twolivesleft.com/Codea/)? If they can do it without Apple's help, there's no reason MacRuby can't. As for #2: I would love to have a discussion about MacRuby's future. In my mind, there's not much point in trying to make MacRuby a "better" Ruby 1.9/2.0. There's already a three-horse race between MRI, Rubinius, and JRuby for the title of "best" Ruby. Obviously, we will always strive for as much feature parity as possible, but the best way to know what features to focus on is to write code. Need Fibers? Tell us. Need encoding support? Well, it should already be there...but if you feel something is missing/lacking, let us know. (BTW, I've been keeping an eye on the design of keyword-args in 2.0, and so far it would not be impossible to support that feature in MacRuby.) I think it is fairly clear that MacRuby's strength is going to be in native apps, so what can we do to make MacRuby stand out from every other way to write native apps? HotCocoa is definitely an interesting direction, but there are other approaches that can be explored as well (such as libraries to make it easier to write menu extras and other app elements). I also like some of the ideas behind using MacRuby as a sort of GUI-REPL, and people should really check out Interactive MacRuby ( https://github.com/alloy/interactive-macruby). The more ideas we explore, the more we can begin to get a feel for what would make a good MacRuby library. Eventually, I think we can begin to understand what direction we want MacRuby to go in. I think it is important to remember that many people were using Ruby for CGI apps before Rails came along, and many more were using Rails on personal side projects for years before any companies took it seriously. All that said, I think perhaps the best thing that the core team can do right now is to better facilitate discussions. The website needs some work. Trac is not the best bug tracker in the world. But the list is not doing too bad, and I try to keep an eye on our IRC channel. I know waiting is the hardest part, but I do think that 2012 is going to be a banner year for MacRuby.
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
