[MacRuby-devel] A Future for MacRuby

Joshua Ballanco jballanc at gmail.com
Thu Dec 22 01:15:23 PST 2011


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20111222/cd908c69/attachment.html>


More information about the MacRuby-devel mailing list