On 21 déc. 2011, at 11:13, Jeff Hemmelgarn
wrote:
Date: Tue, 20 Dec 2011 23:57:53 -0500
From: Jeff Hemmelgarn <[email protected]<mailto:[email protected]>>
To: "MacRuby development discussions."
<[email protected]<mailto:[email protected]>>
Subject: Re: [MacRuby-devel] A Future for MacRuby
Message-ID:
<[email protected]<mailto:[email protected]>>
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
_______________________________________________
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
