[MacRuby-devel] A Future for MacRuby

[David Frantz]

Jeff;

I probably can't help a lot here because frankly I'm not involved in development and only come to the forums as a casual user.   However I will add my 2¢ below.  

Sent from my iPad

On Dec 20, 2011, at 11:57 PM, Jeff Hemmelgarn <jhemmelg at gmail.com> wrote:

> I guess my main angst is with the the direction and philosophy of the project.
> 
> One vision of MacRuby has it being a fully compatible ruby implementation, that happens to be built on the Objective-C runtime and have good integration to all of the libraries provided by Apple, but wrap the guts so that everything is a ruby object.  This is basically how I see the JRuby project.  Access to java libraries and code, but regular ruby runs correctly.
> 

This is pretty much my understanding of the project.  There goal is to take that concept as far as possible.  
> Another vision of MacRuby is instead an Apple-centric tool that exposes it's Objective-C underpinnings in non-compatile ways.  I am talking about using named parameters and having classes like NSMutableArray in the class hierarchy, at least.  There may be other things that I am not aware of.

Isn't it pretty much a given that there will be incompatibilities?   Think about it a bit, straight Ruby already runs on the Mac and runs very well there.   This on the other hand is MacRuby, its goal is to leverage Mac technologies.  In that regard Is it really expected that integrating those technologies will always be compatible with mainstream Ruby?
> 
> If the project had been started outside of Apple I would expect the first vision to hold sway.  The second vision is how I perceive the project from what I have had a chance to glean from the code and the Trac database.  As an Apple outsider, it is harder to get behind the project when I see it as very Apple-centric.  It is a big problem that there are gems that currently look like they will never work under MacRuby (anything using Fibers, or less importantly string encodings).
That isn't a problem, like mentioned above if you want to use mainstream Ruby it is already there on the Mac.   Now think about this how would a product called "MacRuby" not be Apple centric?  
> 
> I agree that integration with XCode is tangential to the core questions.  However, iOS is another matter unless either 1) iOS now has garbage collection (I wouldn't know because I don't follow iOS, I just think it is important to the community of (possible) MacRuby developers) or 2) MacRuby can be compiled to work without built-in garbage collection.  I am perfectly happy to be educated on how either of those things are true.  If they aren't true then there is a lot of developer time between now and being able to run MacRuby apps on iOS, whether Apple allows it or not.
IOS doesn't support garbage collection currently.  Nor do I suspect it will anytime soon.   Currently it seems like the trend is away from garbage collection at Apple.  
> 
> I don't have the time to fix all of these things myself, and I fear that the current direction of MacRuby is not what I would choose.  Therefore anything I contributed would potentially be rejected because I was not pulling in the right direction.  I am not complaining about that:  it is the prerogative of the project lead to take it where they want to go.  To be honest even if the project was running exactly as I wished I wouldn't have the time to contribute too much.  But I think it would be easier for other people outside of Apple to contribute if they saw that MacRuby was trying to be compliant first and Apple-serving second.
Not contributing isn't a problem.  However if you have ideas present them to the rest of the developer community, they would know how any proposed contribution would fit in.  I think the point here is that if you where to contribute to Mac Ruby you would have to accept that it is and always will be Mac centric. 
> 
> A large part of the problem is that there seems to be no communication out of Apple about what is going on.  This is generally regarded as a bad sign for an open source project.  It will be very hard to convince people to contribute when it looks like Apple is taking anyone's contributions and not reciprocating by being open about the process.  How does someone propose a change to the architecture of MacRuby?  Where are the archives of discussions about the design decisions made so far?  Where are the design documents?  Where is the roadmap for bringing MacRuby to 100% compatibility to matzruby?  The contents of the MacRuby Trac component is not sufficient.
This is a frustration of mind, that is Apples lack of buy in or official support is frustrating.  It is one of the reasons I don't invest a lot of personal effort into following Mac Ruby.   Going the Mac Ruby way means spending a lot of effort to learn something that may never get the Apple support it should.    More so you would think that Apple would see and understand the value of a strong and modern interpreter alternative for Mac development. 

As to matzruby if you need that sort of compatibility, Ruby runs really well on the Mac already.  
> 
> All that being said, I will be trying to contribute what I can, especially over the next week and a half since I have the time off.  I do want to help.  I just have quite a learning curve and little time left over from my family and day job.  I look forward to the day I can use MacRuby and be confident that I can use any ruby code, any gem, any library while still using the Objective-C libraries available on MacOSX.

I'm not sure that day will ever come for Mac Ruby.   It is already close to version one, but that is Mac Ruby version one.  
>  To clarify, I think MacRuby should take all valid ruby code and compile and run it correctly.  I don't have a problem with it also taking the named parameters syntax when I want to work with Objective-C code, as long as it doesn't interfere with regular code.  It is a bold vision but if you can communicate that vision convincingly you may be surprised at the support you would get.
> 

At this point I suspect that your contributions would be welcomed.  I also suspect that they would end up being somewhat Mac specific.  

> Jeff Hemmelgarn
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel