<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br>
<div>
<div>On 21 déc. 2011, at 11:13, Jeff Hemmelgarn</div>
<div> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Date:
Tue, 20 Dec 2011 23:57:53 -0500<br>
From: Jeff Hemmelgarn <<a href="mailto:jhemmelg@gmail.com">jhemmelg@gmail.com</a>><br>
To: "MacRuby development discussions."<br>
<span class="Apple-tab-span" style="white-space: pre; "></span><<a href="mailto:macruby-devel@lists.macosforge.org">macruby-devel@lists.macosforge.org</a>><br>
Subject: Re: [MacRuby-devel] A Future for MacRuby<br>
Message-ID: <<a href="mailto:8C895ABA-A5E5-4FF7-A2EB-0E70BBB22493@gmail.com">8C895ABA-A5E5-4FF7-A2EB-0E70BBB22493@gmail.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
I guess my main angst is with the the direction and philosophy of the project.<br>
<br>
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.<br>
<br>
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.<br>
[…]<br>
Jeff Hemmelgarn<br>
</span></blockquote>
</div>
<br>
<div>For me, about the only value proposition for MacRuby is to enable the development of Mac applications using the Ruby language.</div>
<div><br>
</div>
<div>That's it.</div>
<div><br>
</div>
<div>Behind that deceptive mission statement, there hide a number of key features:</div>
<div><br>
</div>
<div>On the "Mac applications" side:</div>
<div><br>
</div>
<div>- integration with Cocoa frameworks, with as little transmogrification as possible: check. Very good.</div>
<div>- 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).</div>
<div>
<div>- integration with Mac development tools: from good to poor. Good for IB, Ok for Xcode templates, poor for debugging</div>
</div>
<div><br>
</div>
<div>On the "Ruby language" side:</div>
<div><br>
</div>
<div>- 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?</div>
<div>- 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.</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>- 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</div>
<div><br>
</div>
<div>- 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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>Jean-Denis</div>
<div><br>
</div>
</body>
</html>