Does MacRuby change the game?

I know MacRuby is still strongly in development, but the pace with which it is growing seems to indicate this will be the defact-o way to do RubyCocoa projects in the late future.

I’m curious about the ‘compatibility’ of the lessons learned in this book. Overall, I suspect the differences are nominal and change is the nature of the business, I”m just looking for an educated guess on how harsh the changes will seem.

Thanks!

My best guess at this point is that well over 50%, but less than 90%, of the material will be applicable to both RubyCocoa and MacRuby.

Thank you for using percentages and not a statistical correlative value. Also, not using “It should mostly be good”. I guess you could consider my comment a possible requested addition to the book - some sort of hint or brief on macruby. It doesnt’ seem reasonable give the time frame - but it never hurts to ask.

Thank you for your response!

I’m running all the examples on MacRuby while I’m reading the book; I actually bought the ebook in order to write MacRuby/Cocoa applications… In general, everything works after a few changes, but you have to remember to do those changes each time.

Here are the differences I’ve found so far: - in MacRuby, you can use the new parameter syntax: menu.addItemWithTitle(“Speak”, action: “speak:”, keyEquivalent: ‘’) - which is much more readable IMHO - you don’t have to add OSX:: or “include OSX”, because everything is based on OSX anyway - you write ‘framework “cocoa”’ instead of ‘require “osx/cocoa”’ - currently IB doesn’t understand classes that use the new parameter syntax, or that don’t inherit from NSObject explicitly (which is discouraged in MacRuby, as Object is a subclass of NSObject so all objects inherit from NSObject anyway); this is already on their buglist - ib_outlets doesn’t work, only ib_outlet does - not sure if this is a bug or feature - example 3.3: using “speak” or “speak_” as the selector name doesn’t work, only “speak:” works - there’s no objc_methods method

Generally speaking, MacRuby looks very promising to me. I think it would be good to at least mention it in the book, I’m sure some of your readers will want to give it a try.

To take the discussion a step further, I’m wondering if MacRuby will obsolete RubyCocoa. I have been looking forward to this book since it’s announcement. But with MacRuby slated to become the defacto in GUI development with Cocoa and Ruby, I’m not so sure it make sense to invest tons of time into RubyCocoa.

One thing I can say is it’s a great time to be a Ruby developer and a Mac user.

Yes, MacRuby obsoletes RubyCocoa.

http://alternateidea.com/blog/articles/2008/6/17/macruby-the-path-forward

MacRuby (ruby 1.9+) is the future of RubyCocoa (ruby 1.8). The same developer works on both for Apple (Laurent Sansonetti). He would not be working on MacRuby if RubyCocoa had a future. When I spoke to him, I gathered that he’s looking forward to production level MacRuby so he can drop maintenance on RubyCocoa.

Ironically, the first production level release of MacRuby is slated for “2008-11” (http://www.macruby.org/trac/wiki/WhyMacRuby), the same month this book releases. This smacks of “planned obsolescence” :-).

I suggest refocusing the book on MacRuby rather than RubyCocoa. Yes, they’re similar, but MacRuby is the future of Ruby on OSX: RubyCocoa does 1.8 and prior; MacRuby does 1.9/2.0 and beyond. MacRuby is also very special compared to the cumbersome (but typical) scripting-bridged, converted, and proxied object approach that RubyCocoa takes (and all other mainstream OSX scripting languages take) to Objective-C compatibility. Why?

http://www.macruby.org/trac/wiki/WhyMacRuby

MacRuby makes ruby support on OSX virtually seamless with Objective-C in a way scripting bridge (typical scripting languages) can not match. I believe this book should focus its love on MacRuby and highlight its strategic advantage of ObjC compatibility (over and above OSX’s other mainstream scripting approaches, including RubyCocoa). With MacRuby, this book becomes incredibly timely.

A MacRuby focus could be the difference between an incredibly timely and great book and a just very well written (but slightly out of sync) book, and early adopters prefer timely and current books. RubyCocoa should probably become a brief appendix in the back about how to upgrade code from RubyCocoa to MacRuby (a la Jakub Suder’s primer above). So I suggest retargeting and focusing the book on MacRuby to make it fully relevant, attractive to all early adopters (your prime ruby on OSX target market), and potentially great.

Well written, timely book. Cool stuff. 2c.

-=-

P.s., Brian (and PragProg) perhaps you could contact Laurent Sansonetti (google says: lsansonetti@…) about MacRuby vs RubyCocoa and the Ruby on OSX roadmap, and even get him to write a Foreword for your book.

Hi guys,

I would like to confirm a few things :)

Yes, MacRuby is supposed to replace RubyCocoa. The reasons behind the MacRuby efforts are mainly performances and a better integration with the technologies that power Mac OS X.

MacRuby is still under development, and we plan to deliver a first production-quality release for the end of the year.

Now, I think that for the end user, MacRuby will look very similar to RubyCocoa. If you know RubyCocoa, switching to MacRuby should be very easy. The hard work here is to introduce the user to the Cocoa APIs, and also to how Objective-C works (since most the APIs are in Objective-C). Which is most probably what Brian’s book is covering (I unfortunately have not had the chance to read it yet).

So I think that MacRuby will not deprecate Brian’s book, and that in theory most of the content could be shared for MacRuby too.

Also, RubyCocoa has been added to Mac OS X since 10.5, and it’s not going to disappear any time soon. Apple guarantees to support RubyCocoa applications in upcoming Mac OS X updates. However, once MacRuby will be stable enough, we will provide the necessary tools to easily migrate a RubyCocoa source base to a MacRuby source base (while still preserving RubyCocoa support).

I just bought and am reading the book now, but trying to run in macruby (instead of using RubyCocoa). I believe it would still be far more useful if the book were macruby targeted. Then all the example code would be (briefer and) work as-is with macruby. Trying to find esoteric syntax changes when learning the basics, is just very distracting and annoying.

For experts, I imagine the idiosyncracies between RubyCocoa/macruby are obvious. Not so when starting out.

I’d still suggest making the changes to the code samples (and minimally to the text) to support macruby. It still sounds like the book will arrive about the time macruby will be getting production ready. I also think basing the book on macruby would be steering prospective Mac ruby users in the right direction (rather than backwards to expired technology, whether still on life support or not). It would also kill off RubyCocoa faster giving more life (and with luck Apple engineering resources) to macruby.

I’d be curious for your thoughts on macruby focus for the book, Laurent?

Finally, I’d like to chime in agreement with all the folks who say the book is very well written. Brian, awesome job. The tone is very inviting, and the book a delight to read.

Cheers,

= Joe =

This is an interesting thread. I’m looking forward to the next beta revision of the book. I have 2c for this thread because it’s something I was thinking about too.

Rubycocoa ships with leopard. Apps written in rubycocoa can be shipped right now without problems. Examples from the book can be written and run today. Open Xcode, Build and Go.

Macruby will replace Rubycocoa as far as I can tell when both Ruby 1.9 and Macruby are considered stable.

I think Matz has set Christmas as the release date for ruby 1.9? Is that when it will be considered stable? Maybe Laurent could confirm whether the next version of OSX will ship with either of them? Or may it be that Macruby doesn’t ship with OSX for 2years+ ?

I think Apple has a great strategy for attracting developers to OSX. Making OSX the best platform to write ruby apps (and python apps, and java apps and …) is a great idea. Macruby is gonna be a great addition.

Still, ruby code can’t be compiled or otherwise obfuscated afaik, so unlike cocoa-python apps (of which there are a few, great, commercial ones), I can’t see rubycocoa or macruby having a life outside of prototyping or in-house or opensource apps. We all love performance. But for prototyping or in-house apps is it such a big deal whether we use rubycocoa or macruby?

Without making a ruby+osx app a viable shipping platform, is Macruby gonna change much?

Also, I can’t see how the new cocoa API calling convention that macruby introduces increases code legibility much. Why is this such an attractive feature?

I can’t wait for the next beta revision of this book, especially the parts about KVC! (what I nightmare that was to figure out using only the apple cocoa docs).

I’ve enjoyed the book a lot so far.

Thanks, Gavin Baker

Gavin:

To me, avoiding the scripting bridge issues is the advantage to macruby (i.e., using ObjC objects natively). The slightly different syntax is just icing on the cake.

Hmm, the point about release dates is important. IIRC, Laurent wasn’t sure (some months ago) whether macruby would make the next OS release or not. I guess that’s a sticking point for “shipping apps”. On the other hand, macruby is pretty compelling for its seamless ObjC integration, and mostly for custom (non-shrinkwrappable) apps so far, so maybe downloading it is trivial for its target market.

Let’s see, when is Snow Leopard due? End of year; early next year? Ruby 1.9 end of year. Maybe macruby could release in time for Snow Leopard, which would hopefully have Ruby 1.9?

Cheers,

= Joe =

Joseph:

I don’t really know what should the book cover, but RubyCocoa and MacRuby are very similar in many ways, so describing RubyCocoa then having a short section covering MacRuby, its goal, and the syntax differences with RubyCocoa, may be a good idea. But I would prefer to not see people reading about it and starting to use it to write production applications, since it’s still under development. It is our objective to release a production capable version at the end of the year, and I’m still confident about it, but we perhaps may not be able to do it.

I cannot talk about SnowLeopard, and if MacRuby will be in it. All I can say is that we are interested to support it in one of the upcoming OS versions. And RubyCocoa will still be supported too.

Gavin:

It is actually possible to obfuscate RubyCocoa applications, I know at least one app that does it. You have several options, either you obfuscate the Ruby source code (simpler), or you transform the Ruby source code as the equivalent Ruby VM C calls and compile it, using ruby2c (harder).

In the case of MacRuby, there will be the possibility to ship an app with YARV bytecode, which may look similar to what Python does (but I’m not an expert). Of course decompiling the YARV bytecode is very easy, so one may one to do an extra obfuscation pass on the code before compiling it.

This obfuscation question is periodically asked, maybe we should add an option to the Xcode templates to perform it automatically.

Laurent

I am a newbie to both iMac and MacRuby and obviously also a newbie to RubyCocoa.

I would like this book (which I have purchased) to also cover MacRuby.

Thank you for your consideration in this matter.

MacRuby is what makes using Ruby for Cocoa compelling. If I wanted to use a very-high-level-language and didn’t mind the scripting bridge issues, I would stick with PyObjC. It’s been around since the days of NeXT and is proven. MacRuby does change the game, and I think it would be wise to focus this book towards (next months) MacRuby 0.4 or the first stable 0.5 release. If that’s not in the cards, perhaps I’ll just wait for the 2nd edition. ^_^

Nathan, I agree with you that MacRuby changes the game. I have broached the subject of repurposing the book to MacRuby (instead of RubyCocoa). However, I believe the publisher decided to go with RubyCocoa for first edition (though I did not ask for the reason(s)). It could be that some legacy code already exists in RubyCocoa, or that they do not want to be accused of bait-and-switching prepurchasers (PDF) of the book with a repurposed title. Frankly, it sounds like putting the wrong color hardwood floor in a building just because it was spec’ced that way, even though everyone knows it needs to be switched out, but that’s just me!-) Books and book publishing are hard and tricky. So I don’t ask.

On the MacRuby side, from Laurent Sansonetti’s talk at RubyConf 2008 earlier this month, he still intends to release “the first production-ready version [MacRuby 0.4] by the end of the year… by production-ready I mean you can really use it to write applications”. That quotation is taken from his RubyConf talk earlier this month (November 6, 2008) about 1/3 the way through when he’s discussing the slide, “MacRuby”. For the talk, see http://rubyconf2008.confreaks.com/macruby-ruby-for-your-mac.html.

MacRuby will support Ruby 1.9 but not (I think) 1.8. I’m not sure whether RubyCocoa will ever support 1.9, but it does support 1.8. Actually, come to think of it, I believe Sansonetti has made claims to support RubyCocoa for some time, so perhaps that means RubyCocoa will support 1.9 (as does MacRuby).

Cheers,

= Joe =

I’d like to add my voice to this chorus. I didn’t want to until i had a bit more experience under my belt.

After a few months of intense cocoa study which I am certain Rubycocoa helped speed up considerably, I am now ditching it for MacRuby.

There’s loyalty for you :)

Already there are too many advantages to using, MacRuby and I am working on a large project which I would like to keep future proof. Having the GC on the ObjC side is also a must.

I hope the book is aborted for a MacRuby version, maybe with a RubyCocoa appendix. Dave, if you’re listening, why not do a poll like I’ve seen you do in the past, and ask your readers what they would like?

It would be great if you could include a chapter on the major differences between RubyCocoa and MacRuby (including differences in how to set up and use Xcode, if any), and if you (on the books website) could provide MacRuby versions of the example scripts.

My current hope is to rewrite Fenestra in MacRuby, then have a chapter pointing out the differences between that version and the RubyCocoa ones. Since I’ve never used MacRuby, I don’t know how hard that will be. (I’m hoping to get the book out some time before the heat death of the universe, so I can’t keep adding ambitious new subprojects.)

I’ve rewritten Fenestra’s main window in MacRuby. I think you’re better off learning Cocoa via RubyCocoa than MacRuby (but then I would, wouldn’t I?) MacRuby is sweet, but I think you’ll still stumble over bugs too often even with a project the size of Fenestra. For example, I’ve spent much of the afternoon understanding why

@log.addLine("Logging started for '#{notification.userInfo[:app_name]}'...")

… didn’t put anything in the log. What gets interpolated into the string claims to be an NSMutableString, which should be the same as a Ruby String. Indeed when I compare it to a string literal like this:

puts "calculated == hardcoded? #{calculated==hardcoded}"

… the result is true. But when I compare it using the equivalent NSString method, I get a -1 (indicating that the strings are not equal).

puts "calculated.compare = hardcoded? #{calculated.compare(hardcoded)}"

There’s something funny about the first character of the interpolated string. When I ask for either calculated[index] or calculated.characterAtIndex(index) for the character before that, I get the apostrophe. When I ask for that character, I get a nil from [] and an index-out-of-range error from characterAtIndex (even though length() shows the index in range).

RubyCocoa certainly has gotchas, but I suspect it’s easier to get a sense for what’s really going on. I don’t know what the deal is with that string. (I do know how to fix it, though:

# PORT: Somehow the original string is corrupt - this fixes it. def fix(notification_string) NSMutableString.stringWithString(notification_string) end

I’ll have a chapter about MacRuby, and I’ll keep working on a Fenestra port so that I can make useful bug reports. You’ll be able to download new versions of the port as I make progress.

Any chance a version of this will be released for Tiger?

Nick: What do you mean by “this”?

MacRuby. The installer package says it requires 10.5.

I don’t know, but I’d be surprised if Apple released a version for 10.4.

For me it is simple. If this book was focused on MacRuby, I would buy it tonight. Done. Plain and simple.

If it retains its focus on RubyCocoa then sorry… no sale.

Farley - I don’t think the difference between RubyCocoa and MacRuby is really that big… this book is generally an introduction to Cocoa for Ruby developers, and it will work just as well whether you use RubyCocoa or MacRuby - you’ll just have to remember to change a few things if you use the latter. If you want to learn Cocoa in order to use it from Ruby, I believe it’s a better idea to buy this book than to wait for another MacRuby-specific book that may theoretically appear one day…

I find myself vaguely irritated (on Brian’s behalf, I guess) at some of the comments here. You folks that bought the book already (and there’s Farley, who didn’t) bought a RubyCocoa book, and now seem irritated that it won’t cover MacRuby (which is something related, but obviously different). It’s like you just bought a Rails book and are annoyed because it doesn’t mention Merb.

If you want MacRuby, why not buy (or write) a MacRuby book ?

Hi i m just starting with ruby so i dont need this book right now(Learn to program & Programming Ruby 1.9 at least first). There is a lot to learn. In the future there will be a macruby specific book, maybe in a 2nd edition of this one? Thanks