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. ^_