[MacRuby-devel] MacRuby-devel Digest, Vol 46, Issue 25

[Jean-Denis MUYS]

On 21 déc. 2011, at 11:13, Jeff Hemmelgarn
 wrote:

Date: Tue, 20 Dec 2011 23:57:53 -0500
From: Jeff Hemmelgarn <jhemmelg at gmail.com<mailto:jhemmelg at gmail.com>>
To: "MacRuby development discussions."
<macruby-devel at lists.macosforge.org<mailto:macruby-devel at lists.macosforge.org>>
Subject: Re: [MacRuby-devel] A Future for MacRuby
Message-ID: <8C895ABA-A5E5-4FF7-A2EB-0E70BBB22493 at gmail.com<mailto:8C895ABA-A5E5-4FF7-A2EB-0E70BBB22493 at gmail.com>>
Content-Type: text/plain; charset=us-ascii

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.

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.
[…]
Jeff Hemmelgarn

For me, about the only value proposition for MacRuby is to enable the development of Mac applications using the Ruby language.

That's it.

Behind that deceptive mission statement, there hide a number of key features:

On the "Mac applications" side:

- integration with Cocoa frameworks, with as little transmogrification as possible: check. Very good.
- bridging with Objective-C, both to enable multi-language development, and the use of 3rd party libraries: check. Rather good (but for the understandable limitation to require GC).
- integration with Mac development tools: from good to poor. Good for IB, Ok for Xcode templates, poor for debugging

On the "Ruby language" side:

- enabling the use of Ruby gems: reasonably OK, though some are expected to be incompatible. The main issue in that case is that there is no clear path to follow when facing an issue with a gem. Is this a bug with the gem? Is this a bug with MacRuby? How to find out? How to fix or work around it?
- enabling the dynamic ("interpreted") REPL style of software development in a MacApp: not checked. Not done at all, though some recent experiments from me and others (Dynamic MacRuby Reload) showed that a lot is possible.

Overall, my attempt to use MacRuby for my current MacApp application is: very disappointing. Despite Dynamic MacRuby Reload being very useful. There are two main reasons for that:

- First and foremost, the lack of a debugger is killing me and my productivity. I ended up defining an Objective-C routine, PrintAndBreak, that takes an object as a parameter, prints it address, and breaks into GDB. From there I can at least inspect that object before continuing. But I still can't step, and the stack trace seen from Objective-C is mostly useless. So that's not enough. The end result is that for more and more methods, especially the most algorithmic ones, I switched to Objective-C

- Second, my application needs to talk to a mySQL server. That was originally a big incentive to use MacRuby: the promise of using some Ruby mySQL gem was so very enticing. I found the impressive 'sequel' gem. However, it turns out it crashed MacRuby. I found on the net that that incompatibility was known for month. I managed to reduce the incompatibility to one MacRuby routine, and file a ticket to MacRuby. The next day, the incompatibility was fixed. Happy ending? Not so fast. It then turned out that the sequel-MacRuby combination fails for mySQL tables that have column names with diacritical characters (fail. not crash. Empty results are returned). I didn't have time to investigate that second issue. I don't even know if it's MacRuby related. I simply switched over to MCPKit, an Objective-C mySQL library.

As a result of these two issues, my MacRuby app is now 80% Objective-C. For me, that's a MacRuby failure. The perspective is still there, but not the reward.

At the very least, the reward will not be there until we have some debugging facilities. And for that, I can't see how we can achieve this without Apple (or perhaps somehow including macrubyd outside in).

Jean-Denis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20111221/fcfb9eca/attachment-0001.html>