[MacRuby-devel] A Future for MacRuby
jballanc at gmail.com
Fri Dec 23 00:36:25 PST 2011
On Thursday, December 22, 2011 at 11:15 PM, Jeff Hemmelgarn wrote:
> I cannot separate the stakeholders (and their issues) from the roadmap. MacRuby will go where people who care to push want it to go. Barring getting a job where I am paid to push MacRuby in a certain direction, I will be at best a small addition to the overall effort. Given that, I would like to feel that 1) I am not pushing in a direction that will be nullified by more powerful stakeholders or 2) an indifferent universe will not cause any effort I put forth for MacRuby to be spilled out upon the sands. Apple is the 800-pound gorilla in the room and can certainly cause either outcome to happen, whether by malice or indifference. I don't need a blessing but a gesture would help a lot. It is one thing to get paid to write shelf-ware, and another to spend your spare time doing it!
There are already shipping, money-making MacRuby apps in the App Store. I think that pretty much refutes your "shelf-ware" concerns.
> So, to avoid the first problem I would like Apple to give some guidance to the community as to what it sees it's interest is in MacRuby.
MacRuby is an Open Source project with a permissive license. Regardless of what direction Apple chooses to take the project in, I can personally assure you that any effort you put into the project will not be nullified. It is important to note that, despite it's name, MacRuby is an implementation of Ruby on the Objective-C runtime and Apple's Objective-C runtime is not the only game in town. While there has not been any effort to build and run MacRuby on GNUStep, there is no reason to think that it could not be done with some effort.
Moreover, MacRuby's dependence on Objective-C is very, very low-level. For Apple to make a move that would disable MacRuby, they would effectively have to rewrite the entire Objective-C runtime (which has been under continuous development longer than either the JVM or the CLR).
> To avoid the second problem I would like to see some indication that Apple plans to move forward on including MacRuby in it's offerings as a first-class citizen on all platforms. Again, I am dreaming to think that could happen. This is all in response to the call for participation in the project. There aren't many people who have the skill set to work on MacRuby and the willingness to work on a project with such little transparency from the main stakeholder. So please don't be unrealistic about what support MacRuby is likely to garner.
Instead of worrying about whether or not Apple will decide to call MacRuby "first-class", how about we discuss what "first-class" would mean. Does it mean the ability to run compiled code without any runtime bridging costs? MacRuby already has that. Does it mean a debugger? Ok, what sort of debugger? Is a command-line interface ok, or would we want something more visual? If it means full integration with Xcode on par with Objective-C, then I'm afraid we are out of luck. However, there is no reason that we can't use MacRuby to develop our own tools. Such tools would have the added benefit of being open and relatively easy to hack on for fellow MacRuby developers.
MacRuby itself is technology-wise not all that different from many other implementations of Ruby or other languages. I suspect that there are a great many number of developers with the skill set to hack on MacRuby, and so long as you understand some basics of C++, it wouldn't be too hard to get up to speed on the project. Regarding transparency, every commit to the MacRuby project is available for public inspection on Github. As for support, obviously we will take all that we can get, but the core team works on MacRuby because it is something that we like to do. We'll continue doing that so long as we can. Yes, that will mean that the project has high and low points, but that is true for almost every Open Source project (for example, Rubinius went from 2 developers to something like 8 developers down to 1 developer in the course of a year…and now look where they are).
> My point about iOS was that MacRuby depends on garbage collection which is not currently included in iOS, and it would take a big engineering effort to get a version of MacRuby that doesn't require garbage collection. If you have a spare man-year to dedicate to making a version of MacRuby that works without garbage collection, more power to you! But are you going to do that with the chance that Apple will add garbage collection support to iOS at any point? I won't. I don't have a spare man-year and if I did I would spend it on a less risky venture.
Let me try to clarify the GC/iOS situation with MacRuby… Ruby is a garbage collected language. The C implementation of Ruby uses a fairly straight-forward mark-and-sweep collector. At the time the MacRuby project was getting started, garbage collection had recently been added to Objective-C, so the decision was made to go with libauto (Objective-C's GC) for MacRuby. Honestly, any collector could work. It would not be impossible to hook up an off the shelf Boehm collector to MacRuby. Heck, the GC functions are even fairly well factored into a couple pre-processor macros and an abstracted allocation call. It wouldn't necessarily be easy, but I don't think it would be anything quite like a man-year to accomplish. To assert that the only way for MacRuby to ever run on iOS is for Apple to add GC to iOS is just wrong.
> I was talking about established bugs in the Trac database when I mentioned Fibers(https://www.macruby.org/trac/ticket/253) and encodings(Net:SSH:https://www.macruby.org/trac/ticket/530). There are gems that cannot run under MacRuby because these features are not supported. The code is already written, make it run!
Good! Now we're talking. So, for the Net::SSH bug, if there is just an encoding issue standing in the way of getting things to run, then let's smash that bug! The last comment I see is from 10 months ago and indicates v0.8. Have you tried running it recently? We made a decent dent in the C APIs for encodings right around that time. I wouldn't be surprised if this was already fixed, but if not, let's build a trivial test case and hammer away at it.
As for Fibers…hmm…I don't think we've ever given much serious consideration to Fibers since they don't seem to be a horribly popular feature of Ruby proper, and because implementation could be problematic. That said, I wonder how much of the specs we could get to passing with a GCD-based pure-ruby implementation of Fibers. Anyone up for the challenge?
> I have been looking into some of the more esoteric problems with the current implementation of MacRuby and am hesitant to put too much effort into it because of the "integrate into Objective-C" focus of the project. The changes to get some of the problems fixed with the problematic gems may or may not cause serious performance problems for all of MacRuby, or integration problems with Objective-C frameworks like cocoa. I don't see Apple being supportive of these kinds of changes. Again, this is where the stakeholders and the direction are inextricably entwined.
Again, why are you asking for Apple's support? Send a pull request and see if it gets accepted. Until then, idle speculation on what Apple is or is not being supportive of seems a bit premature. That said, since the primary use case for MacRuby (at present) is for implementing performant, Cocoa-based apps, I don't think it is unreasonable to be wary of a change that adds to Ruby support at the expense of speed or integration. If you disagree, let's argue on specific points instead of abstract generalities.
> I wouldn't be writing all of this if I didn't see a lot of potential for MacRuby. I want to see it succeed and be a blazingly fast ruby implementation. The better it supports all of the gems, the better it will support any arbitrary ruby code I write. I want MacRuby to succeed and be available. But, I accept that the only thing I may get out of working on MacRuby is the work.
…and the experience! :-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the MacRuby-devel