Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A review of RubyMotion

samsoff.es

Post reply on HN
Print view View original

11–20 of 31 posts

Re: A review of RubyMotion

#11

Post by Arcanum-XIII »

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

Re: A review of RubyMotion

#12

Post by Argorak »

Arcanum-XIII wrote: post #11

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 synta…

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).

Re: A review of RubyMotion

#13

Post by EzGraphs »

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

Re: A review of RubyMotion

#14

Post by subwindow »

ricksta wrote: post #2

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) @windo…

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)

Re: A review of RubyMotion

#15

Post by Arcanum-XIII »

Argorak wrote: post #12
Arcanum-XIII wrote: post #11

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 synta…

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).

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 !

Re: A review of RubyMotion

#16

Post by stcredzero »

subwindow wrote: post #14
ricksta wrote: post #2

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) @windo…

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'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.

Re: A review of RubyMotion

#17

Post by stcredzero »

egze wrote: post #4
ricksta wrote: post #2

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) @windo…

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

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.

Re: A review of RubyMotion

#18

Post by jeremymcanally »

Arcanum-XIII wrote: post #15
Argorak wrote: post #12

Earlier quoted context omitted.

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).

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 !

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.

Re: A review of RubyMotion

#19

Post by samsoffes »

barrym wrote: post #9
kenferry wrote: post #5

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], UITextAttributeT…

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

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!

Re: A review of RubyMotion

#20

Post by vlucas »

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.

Post reply on HN