A review of RubyMotion(samsoff.es)

http://samsoff.es/posts/rubymotion-review

30 comments

One of the ObjC examples could be more concise. He writes:

  id navigationBar = [UINavigationBar appearance];
  [navigationBar setBackgroundImage:[UIImage imageNamed:@"nav-background.png"] forBarMetrics:UIBarMetricsDefault];
  [navigationBar setTitleTextAttributes:[[NSDictionary alloc] initWithObjectsAndKeys:
    [UIFont cheddarFontWithSize:24.0f], UITextAttributeFont,
    [UIColor colorWithWhite:0.0f alpha:0.4f], UITextAttributeTextShadowColor,
    [UIColor whiteColor], UITextAttributeTextColor,
    nil]];

which could be

  id navigationBar = [UINavigationBar appearance];
  [navigationBar setBackgroundImage:[UIImage imageNamed:@"nav-background.png"] forBarMetrics:UIBarMetricsDefault];
  [navigationBar setTitleTextAttributes:@{
    UITextAttributeFont : [UIFont cheddarFontWithSize:24],
    UITextAttributeTextShadowColor : [UIColor colorWithWhite:0 alpha:0.4],
    UITextAttributeTextColor : [UIColor whiteColor],
  }];

as compares to the Ruby,

  navigationBar = UINavigationBar.appearance
  navigationBar.setBackgroundImage(UIImage.imageNamed('nav-background.png'), forBarMetrics: UIBarMetricsDefault)
  navigationBar.setTitleTextAttributes({
    UITextAttributeFont: UIFont.cheddarFontWithSize(24.0),
    UITextAttributeTextShadowColor: UIColor.colorWithWhite(0.0, alpha:0.4),
    UITextAttributeTextColor: UIColor.whiteColor
  })

Also kind of wondering where he got "cheddarFont". :-)

barrym14년 전

I didn't know about the new @{} syntax for dictionaries - http://blog.ablepear.com/2012/02/something-wonderful-new-obj... - very nice.

samsoffes14년 전

You can't use that unless you're running Mountain Lion and you can only submit apps to the store with a released version of Xcode. The new syntax is amazing though!

rads14년 전

Cheddar is the name of his app: https://cheddarapp.com/

ricksta14년 전

Objective C classes and methods are designed to be long and mostly typed by Xcode's autocomplete. With RubyMotion, I will end up typing out all those verbose methods, which I don't know if it's something I feel too big about.

The example author made here feels like I will end up typing about twice as much with RubyMotion than objective C.

Ruby: @window = UIWindow.alloc.initWithFrame(UIScreen.mainScreen.bounds) @window.makeKeyAndVisible

Objective C: self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]]; [self.window makeKeyAndVisible];

jmonegro14년 전

I agree. With XCode's powerful autocomplete, I don't have to remember all the methods. In fact, you can guess the names a lot of the times due to their verbose and descriptive naming conventions, and XCode will help you along the way.

I'm a Rubyist, it's my primary language and I'd love to use it over Objective-c. But I'm also starting really like Obj-c, and right now it's the best thing out there for iOS because of XCode.

If you want to learn how to make iOS apps, learn Objective-c. Or at the very least learn it first. Trust me, you'll be glad you did.

subwindow14년 전

The real benefit with Ruby is the creation of DSLs that make working with these UI elements much easier.

It's only a matter of time before someone creates a DSL that looks something like:

  window = screen.main.new_window(
    frame: true,
    key: true,
    visible: true
  )

Or something like that. I'm not an iOS developer, so I'm not really sure what parts of the insanely-verbose method calls are actually necessary.

(As an aside, I have Vim rigged up to do autocompletion with Ruby. I'm sure it would work with these Cocoa libraries as well)

stcredzero14년 전

I'm not an iOS developer, so I'm not really sure what parts of the insanely-verbose method calls are actually necessary.

It's called "Intention Revealing Names." Names are long to provide the programmer information, so shortening them would have a negative impact.

As an aside, I have Vim rigged up to do autocompletion with Ruby. I'm sure it would work with these Cocoa libraries as well

If someone writes the necessary plumbing.

286c8cb04bda14년 전

Somebody already did once[1], though it's gotten a bit out-of-date. It needs to be manually revised every time a new SDK comes out, so it's going to keep falling out-of-date.

[1]: http://www.vim.org/scripts/script.php?script_id=2674

poutine14년 전

You need to keep in mind that you don't actually type out the entirety of XCode's methods. For instance:

self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];

Was about 45 key presses in Xcode. And this is a fairly short method, take something like animating a view with a block and you're looking at way more typing to do it in Ruby Motion.

egze14년 전

I wonder if IDEs like RubyMine will have a nice autocomplete for RubyMotion

adamjcooper14년 전

RubyMine doesn't support RubyMotion or the iOS SDKs now, but they're considering it (cf. http://devnet.jetbrains.net/message/5458781#5458781). You can vote up the feature here:

http://youtrack.jetbrains.com/issue/RUBY-11039#tab=Comments

stcredzero14년 전

I would look at the autocomplete scripts/library, see how the metadata is handled there, then see if the autocomplete data in XCode can be hooked up.

EzGraphs14년 전

As someone who uses ruby for the sheer joy of it (and finds ObjC a bit clunky), I want to be more excited about this. I am just not seeing the benefit yet.

Ruby syntax is nice, not having autocomplete available is a problem, especially since a good deal of time is spent figuring out the appropriate calls to underlying libraries. Maybe this will be remedied in future releases.

I tend to like command line / REPL interactive development... but does this really add any significant benefit when making iPhone Apps? I would imagine if you have a lot of calculations or String manipulations involving non GUI/device interaction this could be handy. But every actual test of code is going to involve running rake and the emulator, which is not an advancement from running make (by clicking a button in XCode) and the emulator.

Finally, what about running an interactive debugger or memory management tools? XCode/ObjC has a number of benefits that eliminate some of the need to be intimately acquainted with some of the underlying painful details. There is not a lot of appear in trying to write an App in Ruby, backing out and rewriting it in ObjC/XCode, and then porting it to Ruby.

Still, it was just released. Perhaps improvements in these areas will be forthcoming in the future...

286c8cb04bda14년 전

> I tend to like command line / REPL interactive development... but does this really add any significant benefit when making iPhone Apps? I would imagine if you have a lot of calculations or String manipulations involving non GUI/device interaction this could be handy.

You could certainly us it for GUI interactions. Take the MacRuby equivalent to:

    [[[[[[[UIApplication] sharedApplication] delegate] window] rootViewController] view]

That gets you the main view on screen, to which you could add or remove elements at your pleasure.

EzGraphs14년 전

Thanks - that is a benefit.

Arcanum-XIII14년 전

It's not a real review — it's a guy having fun with a new toy, which is nice. I'm still not more informed about the real advantages or disadvantage of this solution, nor its speed... But to be honest, this soon, I wasn't expecting much.

Still, as other, I'm perplexed with the difference. It all seem to boil down to syntax (and I must confess I like the objective C one, it being my second language after C) — and syntax is not that important, it's the concept behind. XCode is not a good IDE, but not that bad for its purpose. Is there an equivalent for Ruby, especially to debug the app ?

Alternative is good, but it need to add something to be really differentiated. I'm not sure using ruby syntax is enought...

Argorak14년 전

The differentiator is the console-based development flow and the REPL, which is not an afterthought but a prime feature.

The REPL is basically your debugger.

Also, while the Ruby stdlib is not running on rubymotion, I see a chance for sharing Code between rubymotion/ruboto environments (ruboto is Jruby for Android).

Arcanum-XIII14년 전

Does the REPL work on the live application ? Otherwise I'm not sure it's that usefull — but I'm more of compiler/breakpoint guy at the moment so feel free to prove me wrong !

-- EDIT --

Ok, I've read the review from ArsTechnica, and yes you can do that. Now I'm curious to try it !

jeremymcanally14년 전

Yup it does. There's a screencast on the Pragmatic Bookshelf site that shows it off. You can change things live in the app (e.g., label text, state, whatever). It's incredibly cool.

smartgoat14년 전

But you can already do that in gdb and lldb.

blt14년 전

What is the advantage? I'm neither an iOS or ruby developer, please enlighten me. It seems like this gives you a different language syntax to access the same libraries with no additional abstraction. It doesn't seem like it would speed up development much.

anko14년 전

The interactive REPL looks fantastic. It's one of the things I love about developing in ruby - you can try things without going through the compile or even save/execute process. There is a lot to be said for a short/instant feedback loop.

andrewflnr14년 전

I assume you get other benefits of working with Ruby, like it's functional programming aspects, (nicer) dynamic typing, data structures, etc. Plus if you were a ruby developer, like the author here seems to be, it would feel more familiar.

jamesjn14년 전

What I really like about it is that it allows me to do everything from the command line.

I can edit the ruby files in vim and then just run the rake task to open up the simulator to test the changes I just made.

igorgue14년 전

There's additional abstractions, e.g.: Strings inherit from NSString, you can also use "#{variable}" instead of the stringWithFormat:... objc thing.

sthulbourn14년 전

The only clear win I can see from this is the REPL.

Everything else is down to preference... I'd rather write native Obj-C code, but the guy next to me would rather write in ruby.

It's very subjective and down to coder preference, I can only hope that the ruby world has a great work around for the very verbose selector names in the iOS SDK; I was expecting some sort of wrapping for the iOS SDK to make it simpler.

poutine14년 전

REPL seems to be a crutch for not having a visual interface builder. His example in the video wouldn't have been an issue in Xcode as you'd have positioned and named the label correctly to begin with, and would have seen it in context too.

poutine14년 전

As a long time Ruby and Objective C developer who loves both languages I'm not impressed.

Sure the REPL stuff is neat, but I would position my UI elements correctly in interface builder to begin with. I'm also not keen on typing out the code to assign properties that were done with the GUI before. There doesn't seem to be any support for Storyboards which are awesome as segue transitions save a ton of code that you'd normally have to type. Storyboards provide a visual layout and ease of inserting steps in a flow or changing connections.

Once you have proficiency in Objective-C your coding method in XCode really consists of typing 3-4 characters, hitting tab, a couple more characters, a variable name and so forth. Code completion rocks and works quite well in particular with Objective-C. I would expect all of the examples given there would be many fewer keystrokes in Objective-C than Ruby.

I find the side by side code samples somewhat humorous. I expect to see something like coffeescript to javascript which is visually obvious which one is more concise. Instead I see roughly the same code expressed differently. Sure Objective-C turns people off who don't know it, but once you do it's really not a big deal.

Xcode also gives you great tools for refactoring code that due to the nature of Ruby simply are not possible. This is pretty important for large projects.

The tough part of making non-trivial IOS apps is learning the API and the best practices in using it. That can take months or even years.

vlucas14년 전

I took a look at RubyMotion and came away pretty disappointed. It seems like the target market is for people who already write apps in Objective-C, but want to write them in Ruby instead. The larger and more lucrative market is for people who want to write apps without touching Objective-C at all or knowing anything about it (i.e. using their existing knowledge of web technology to write apps).

Compared to other abstraction frameworks on the market like Titanium, the RubyMotion code is way too verbose and obtuse, and is really only obvious to those who have already worked with Obj-C. On top of that, you don't get the autocompletion and hinting because people don't typically write Ruby in IDEs. I love the idea of using Ruby in this manner though, and hopefully people will begin to build frameworks on top of RubyMotion so I can use it with a single helper method call and a dictionary of options, like Titanium or a jQuery plugin.