RubyMotion Goes 2.0 And Gets OSX Support, Templates and Plugins | Hacker News Reader

RubyMotion Goes 2.0 And Gets OSX Support, Templates and Plugins

blog.rubymotion.com

185 pointsjballanc74 comments

This is excellent news. I purchased RubyMotion when it came out and largely didn't use it for awhile. Since last 3 months our company which is entirely made of Rails/JS guys have been building small apps using RubyMotion.

I didn't know they were working on OSX support. But this is huge for me, back on GNU/Linux GUI programming using dynamic languages is easy. py-gtk/ruby-gnome2 bindings really work well and It is incredibly awesome that you can build small utils for yourself in a afternoon using py-gtk/ruby-gnome2. Ability to do the same for OSX is exciting!

I'm not sure I understand this. Is RubyMotion just a set of wrappers around Objective-C classes to allow you to develop applications in Ruby? If so, why? Is the point to allow Rubyists that don't want to learn Objective-C to develop applications in Ruby?

Thats part of it and you do not have to use Xcode. Some of the gems such as BubbleWrapper also created a really nice syntax.

That is exactly the point.

Agree. Not language but API should be fixed.

Disagree. And that's why we have RubyMotion! :-)

RubyMotion is not a wrapper. It is an implementation of Ruby on the Obj-C runtime. This means that a RubyMotion object is an Obj-C object (for comparison, a Ruby object in MRI is just a C struct). So why would you want to use RubyMotion? Well...

* Obj-C, from the very start, was implemented as a strict superset of C. This means that every valid bit of C code must also be valid Obj-C. This places some rather sever limitations on the Obj-C syntax. Ruby does not have this limitation, and neither does RubyMotion. So one reason you might use RubyMotion is to get a cleaner syntax that does the same thing as Obj-C.

* The Obj-C runtime is very dynamic. You can create classes on the fly, add methods to them at runtime, move methods around between objects, and create methods dynamically. The Obj-C language makes it nearly impossible to take advantage of any of these features of the Obj-C runtime. So another reason you might use RubyMotion is to get the most out of the Obj-C runtime.

That was really informative. Thanks for the breakdown.

Bullet #2 is so very very wrong. Nice try. I can't speak to the first bullet.

Please elaborate; I have only minimal experience with ObjC and do not use Ruby in the context of native development, so any well-described counterpoints would be much appreciated.

Edit: I obv. didn't write your parent comment. What I meant was that I'm sure others in my position, having read your parent, would appreciate more elaboration from you as well. :)

Sorry, you're right. It was an off the cuff rebuttal with no substance. Added to the parent comment.

I think he meant ruby in bullet 2

In Objective-C we can create methods, properties and classes on the fly using <objc/runtime.h>

Here's how to create a property on the fly (great for categories)

@dynamic progressView;

- (void)setProgressView:(ACProgressView )progressView { objc_setAssociatedObject(self, ACProgressViewKey, progressView, OBJC_ASSOCIATION_RETAIN_NONATOMIC); }

- (ACProgressView )progressView { return objc_getAssociatedObject(self, ACProgressViewKey); }

You still had to tell the compiler ahead of time about the property. The actual test is more like

    NSObject obj = [NSObject init];
    giveObjectAProperty(obj, @"progressView");
    obj.progressView = [NSNumber 42];

Writing giveObjectAProperty may not be "nearly impossible" but it sure isn't easy.

And of course the parent is talking about methods, not properties, but...same argument.

Fair enough.

Here's how you'd make that class on the fly:

   Class mySubclass = objc_allocateClassPair([NSObject class], "MySubclass", 0);

Here's how you'd add a description method to a newly created class:

   static NSString *Description(id self, SEL _cmd){
        return [NSString stringWithFormat: @"<%@ %p: foo=%@>",[self class], self, [self foo]];
   }

    // add Description to mySubclass
    // grab NSObject's description signature so we can borrow it
    Method description = class_getInstanceMethod([NSObject class],
                                                 @selector(description));
    const char *types = method_getTypeEncoding(description);
    
    // now add
    class_addMethod(mySubclass, @selector(description), (IMP)Description, types);

And your iVars:

   class_addIvar(mySubclass, "foo", sizeof(id), rint(log2(sizeof(id))), @encode(id));

What jballanc is saying is that yes these things are possible in Objective-C, but the technique of doing these tricks in Ruby/Motion is an order of magnitude simpler and idiomatic:

    klass = Object.const_set "MySubclass", Class.new(Object)
    
    klass.send(:attr_accessor, :foo)
 
    klass.send(:define_method, "description") {
      "<#{self.class}: foo=#{self.foo}>"
    }

There are a few very well-written wrappers that make utilizing the Obj-C runtime much easier. MAObjCRuntime [1] is a good example of such a wrapper. Look at MACollectionUtilities [2] as an example of how to use MAObjCRuntime.

[1]: https://github.com/mikeash/MAObjCRuntime [2]: https://github.com/mikeash/MACollectionUtilities

I'm doing a serious project in RubyMotion at the moment. It doesn't save you having to know Objective-C, since all example code for doing anything in Cocoa are still in Objective-C, but it does save you from having to write in Objective-C itself. That means, no writing everything twice (header files, type declarations), and no brackets. I find Ruby a lot more readable, even when writing the incredibly long method names from Cocoa.

But the real payoff is threefold:

1) You can use and write very ruby-ish wrappers for things. A great example is teacup, which lets you essentially write stylesheets for your UIViews (and I guess now NSViews).

2) Working with collections like arrays and hashes is MUCH more convenient. You can spend a good part of your time doing just that.

3) Command-line toolchain. It's not for everyone, of course, but for those who work better like that, it's a revolution.

Right now it's pretty wild west. There's no obvious winner in terms of libraries for the data layer, for example. So taking on an RM project right now either means rolling up your sleeves and hacking on the infrastructure, or just living with raw Cocoa, without benefit of autocomplete. Give it another 6-12 months and I think you'll see a very strong contender.

  > That means, no writing everything twice (header files,
  > type declarations)

  Your header files can be practically empty if you don't need to show something to outside. Just put your @property'ies into class extension. Even @synthesize no longer needed (most of the time, there are exceptions).

  > Working with collections like arrays and hashes is MUCH
  > more convenient. You can spend a good part of your time
  > doing just that.

With latest versions of XCode it is possible to use foo[5] instead of [foo objectAtIndex:5] and foo[@"bar"] instead of [foo objectForKey:@"bar"]; There are also array and dictionary literals @[…], @{…} and you can also just type @1 to get NSNumber from primitive.

I'm aware of all that, but of course you DO want to show things to the outside, all the time. I also know about the newer syntax, which is awesome the few times I still dip into ObjC, but I'm more thinking of map/each/select/detect/etc. There are builtin methods for doing those, but their sheer verbosity tends to discourage the sort of free and easy chaining that Ruby encourages. (Some might argue that's a benefit. Not me.)

Cocoa is a fantastic system to build on top of. NSDate is MILES better than the Ruby time stuff, for example. NS/UI solid core plus Ruby's flexible syntax and culture of sensible defaults is a marriage made in heaven.

>> I'm aware of all that, but of course you DO want to show things to the outside, all the time.

Well, there's a solid argument to be made in favor of limiting how much internals are exposed to other objects. I personally like keeping my headers as minimal as possible.

To clarify: Ruby has public and private. You can control visibility all you want, you just don't have to use a separate header file.

Your header file is your interface and documentation to anyone using your code/class. Why wouldn't you want to declare your public interface there?

As for readability. Ruby is getting there but currently:

   - (void)employersWithCarrierID:(uint)carrierID withMaxReturnCount:(uint)count;

   [self employersWithCarrierID:123 withMaxReturnCount:10];

is a lot more readable and verbose than

   def employers (id, count)

   employer 123 10

Except in Ruby, you'd just as likely see named arguments too.

`employer carrier_id: 123, max_return_count: 10` is very much valid ruby.

Beyond that, RM has "real" named arguments based on the objective-C core.

I found BlockKit [1] to be very useful for any Ruby-like collection methods. BlockKit, as the name says, uses blocks extensively to provide all the most common collection methods one would find in Ruby. Some examples of these methods, taken from the NSArray(BlocksKit) [2] documentation are "each", "apply", "map" & "reduce". There are much more.

[1]: https://github.com/pandamonia/BlocksKit [2]: http://pandamonia.github.io/BlocksKit/Documentation/Categori...

The legacy is RubyCocoa -> MacRuby -> RubyMotion.

RubyCocoa was actually a wrapper, but was very slow. MacRuby's innovation was that it was a Ruby implementation in Obj-C, but it relied on GC and was Mac OS X only. RubyMotion ditched the need for the GC and supports iOS and now Mac OS X.

That's awesome. I recently tried to get into MacRuby development, but there's a serious dearth out there of resources (for the beginner), and I had to guess on how to do a lot of things.

Hopefully the RubyMotion support will be better!

Beyond the OSX support the weakref support is very welcome!

WeakRef still doesn't zero out collected references, so https://github.com/farcaller/motion-memorymanagement (based on mikeash's MAZeroingWeakRef) is still the better alternative.

Please pardon an off topic question: is the compiled code from RubyMotion similar to Objective-C compiled code? (Within a factor of 2 or 3 in speed?) Thanks.

In the large majority of cases, compiled RubyMotion is indistinguishable from Obj-C, both in terms of speed and size.

I am very keen to know what Apple thinks about RubyMotion. It seems like a fine tool; but it's not typical Apple to allow external commercial vendor to influence it's core development environment.

Anyone from Apple, or anyone that gained the sense in events like WWDC, care to share?

Apple made it clear a few years back that any language that compiles to "normal" binaries is fine, after (at first) being completely restrictive about the tools you could use.

Their major remaining rule is that you can't build environments that download code from the internet and run it. (Except for Javascript, and you have to use JavaScriptCore (Apple-supplied) for that.)

Anyone had experience incrementally adopting rubymotion in a larger objective-c project? The languages obviously match up pretty well, I'm thinking more about toolchains, etc.

Would love to play with this but am fairly invested in a big obj-c thing right now.

I haven't done a larger project, but I did port a small project by starting with just the AppDelegate. It was easier to first turn the xcode project/obj-c code into a library, and compile it as such. The classes "just worked", and with all the nibs in resources/ those loaded, too!

I translated the models into Ruby, and pulled those out of the xcode lib. Eventually the entire codebase was converted (except the nibs).

How I wish something like this exist for python..

The closest thing I know about is Kivy.

PySide isn't half as bad as you might remember. And yes, kivy is pretty respectable and only getting better. They did win a little grant too recently.

Is there a way to play with it for people who can't still afford it?

It would be nice to have it in other platforms, anyway it quite nice to have the option to natively compile Ruby code.

Can RubyMotion work with GNUStep?

I doubt this has ever been tried, but I seriously doubt it... the compiler does a lot of work looking at the Cocoa frameworks to build the bridgesupport files. Are GNUStep frameworks built the same way?

Looks awesome. I just wish it was free and open.

SO rad!

And here is how MacRuby developers were lied to and the RubyMotion project made the choice to not contribute back but instead to focus on keeping innovation proprietary.

https://lists.macosforge.org/pipermail/macruby-devel/2012-Ap...

It's quite a sad day to think that Apple invested on MacRuby and kept it open source... and RubyMotion chose another route even for OS X dev.

Oh yes, what a horrid selfish man, trying to feed his family and make a business for himself. Not like generous, giving, open source-loving Apple!

Give me a break. The guy's made something amazing. Good on him for charging for it, making a success of it, so much so that we now have a version 2.0. This would never have come from some lousy half-hearted Apple mailing list.

I am happy to pay for this product, and I do not blame him for keeping it proprietary. I just don't see what your point is. It seems like you just want something for nothing and are dressing that up in some unlikely open-source clothes.

You have completely missed the point.

Charging for software is not a crime. The point is that he lied to the open source community about his intentions.

It has been over a year since that post. It is not at all implausible that the post accurately described his intentions at the time he wrote it.

Your accusation that he deliberately lied, rather than simply changed his mind, has no foundation whatsoever.

I can vouch for this. Laurent and I heavily discussed RubyMotion in its early days. His idea was to create a mobile solution (ergo Motion in the name) and had no intention whatsoever to include Mac OS X development at the time. It turns out however that the market wanted a unified toolchain. Many customers asked for it. And Laurent, like any good business person would, listened to the needs of his customers.

Antonio, but nothing prevented him to contribute back to MacRuby (OS X) the required changes to get rid of the GC and therefore to not rely on deprecated technology.

Who says that that option is off the table for good; many companies release open source software after the initial proprietary release.

Tough shit. He's trying to support himself and his employees. Likewise, backporting their work to a even slightly different code base would require time they frankly don't have. Unless you have a time travel device you can give him, don't demand time he doesn't have.

Laurent frankly is underpricing his wonderful tools, and has to support himself and all those folks he's hired.

Time is finite, and no human can do all the things they'd like to do.

Modifying RubyMotion to have the right hooks for the OS X apis etc is likely much simpler than fixing up MacRuby architecturally.

Point being, people have finite time, they can't do all the things they want to. Either be nice or give him a time turning / time travel device

Except, he didn’t lie. He spent money to have Watson also do maintenance work on MacRuby.

Where is the GC switch he mentioned tho ?

I just thought I would point out that the guy you're replying to is actually one of the top contributors to MacRuby.

Yes, and Shizuo Fujita and Laurent are THE top contributors. Both HipByte employees. Matt's last commit was two years ago:

f6908b2 - 2011-04-28 21:50:28 -0700 fixed a stupid bug in the Xcode4 template (Matt Aimonetti)

I know, I know. I don't care who's right or wrong here, colinta. It's only that I thought "hey, maybe venus doesn't know that mattetti is one of the guys that worked on MacRuby, I'll point that out".

If you don't like RubyMotion, then don't buy a license. Plain as that! Thanks Laurent, Shizuo, and the FANTASTIC RubyMotion community!

[Disclaimer: MacRuby core member here.]

I agree, it’s too bad that people can’t just work for free as much as they would like on the stuff they love.

Now it is true that Laurent himself has not touched the repo since that email you linked to, but you know just as well as me that Watson has been doing maintenance work on MacRuby while on the payroll of RubyMotion (HipByte). His latest commit was 15 days ago and here’s a generalised diff of all the work done since the email: https://github.com/MacRuby/MacRuby/compare/94c90b351c18ce1f5....

This is what people with limited time resources do, they delegate.

To conclude, when you’re out to paint someone black, you really should be more specific. As it stands, there are no lies in that email, which means that you are the one that is not telling the truth. I’m not sure why you want to spread FUD, but it’s quite obvious and really does not make you look professional.

PS: Whatever Apple chose or chooses to do has absolutely no relevancy to this at all. The moment they released it as Open-Source, they effectively said that people can do what they want as long as they follow the license.

Well put.

Alloy my point was not about maintenance but the fact that MacRuby relies on the ObjC GC which is now deprecated. In this email thread Laurent acknowledge the need to switch to static compilation and that he has a working branch he will soon merge.

This is exactly what RubyMotion just released and I'm saddened that it was not contributed back as promised.

It's as simple as that.

I've been losing respect for HipByte. Laurent is making tough calls, I'll bide my time.

Well, spoking of broken promises and people abandoning things, didn't you write a book on MacRuby and a couple of articles touting it, and then abandoned the project for greener pastures (Ruby, Go and such)?

What about the folks that bought into the book and MacRuby, thinking that it was a viable project, and then see you, one of the (few) main contributors abandon it -- and long before today's release of RubyMotion.

I'm saddended my pizza shop does not hand out free pies, too.

Shell out the $200 for the hard work they put into it and get over your entitlement complex.

"But you PROMISED!"

Apple invested in MacRuby? What a joke! This project was almost singlehandedly held by one person. I know for a fact that Apple doesn't give a fuck about MacRuby, don't fool yourself about that.

Who ask for this misinformed opinion?

>Apple invested in MacRuby? What a joke!

Yes, it did. Back in the day, MacRuby started by Apple employees and initial development was paid by Apple.

>This project was almost singlehandedly held by one person.

Which is beside the point.

>I know for a fact that Apple doesn't give a fuck about MacRuby

You don't say! That has been the case several years now, since Apple stopped supporting the project. Everybody in the MacRuby community knows this.

>don't fool yourself about that.

Thank you, Captain Informed.

As someone who wrote a number of MacRuby apps, I find the support for OSX wonderful.

MacRuby is slow and clunky. Fact. This is a big improvement performance wise.

Do I mind paying for that improvement? Hell no. MacRuby development has pretty much halted once it lost Apple Support. I don't mind paying for something that will be maintained and improved upon.

I wouldn't take this personally, it is just a smart business decision. It makes sense that once you buy a RubyMotion license to be able to use the same toolchain on OS X.

Also, I wouldn't mind paying for RubyMotion as long as I'm assured the project will go forward.

Unfortunately MacRuby lost momentum when Apple decided to not support the project anymore.

Lied? or changed his mind?

I find that it's a happy day, not a sad day (even if I like open-source).

Why? Because now some of my customers are going to seriously think about using Ruby for Mac OS X apps, because they know someone is making profit while supporting this, so they feel they can rely on this.

I much prefer this to the fate of IronRuby (or to some extent, MacRuby).

Remember what you wrote one year ago [1] ?

    Using RubyMotion for a professional product represents
    a significant business risk, which is exactly the same
    as using proprietary technology from any vendor.

It turns out the opposite is coming to reality :p

[1] http://merbist.com/2012/05/04/macruby-on-ios-rubymotion-revi...

Reply on news.ycombinator.com