Live data from Hacker News

RubyMotion - Ruby for iOS

rubymotion.com

121–130 of 250 posts

Re: RubyMotion - Ruby for iOS

#121

> RubyMotion is built on top of iOS. You have access to the entire set of public iOS APIs and can also use 3rd-party Objective-C libraries or Gems So this should be compatible with cocos2d right?

cocos2d is writen in Objective-C so in principle it should be compatible with RubyMotion. Not so sure about the ARC integration (last time I've checked cocos2d was only "ARC compatible"). I've seen some work arounds using a cocos2d as a static library (no ARC enabled) linked with a main Objective-C application that uses ARC. It should work ... but I can't give you a final answer.

Re: RubyMotion - Ruby for iOS

#122
post #7

Earlier quoted context omitted.

Having been part of the private beta I can tell you that it's a huge time saver. Objective-C is nice be ruby is much more expressive, you can use the same API with much less code, you can skip XCode altogether and use your favorite editor, ... I can't express properly how awesome it is, really.

The call syntax is still painful compared to straight Objective-C as it actually uses more characters and is not as clean. I really wish he had come up with something that resembled Objective-C better.

If you want objective c syntax and behaviour surely you'd just use objective c?

Re: RubyMotion - Ruby for iOS

#123
post #117
post #103

Earlier quoted context omitted.

You've completely missed my point. Feel free to re-read what I wrote. Just for reference, yes I code in both Objective-C AND Ruby. There are significant speed gains when using the tools/language you're most familiar with. I've seen this first hand with myself, and in others... It's not about "how easy it is to learn" it's about "how much time it takes." You're mixing together two entirely different topics.

I was specifically addressing this point (which seemed to be the crux of your comment): > Remove the concept of learning a new language, a new IDE, and only require that I learn a new lib to work against and I'm FAR quicker. That's a bit like saying, "Remove the concept of putting on running shoes and warming up and only require that I run a marathon and I'm FAR quicker." The time to tie your shoes is nothing compare…

> That's a bit like saying, "Remove the concept of putting on running shoes and warming up and only require that I run a marathon and I'm FAR quicker."

It's not at all like saying that. Feel free to keep your words out of my mouth :)

> ...is insignificant compared to the time it takes to learn Cocoa.

I see you've changed from using the word "easy" to the word "learn." That's a step in the right direction :)

Though, we are not comparing the time it takes to learn Cocoa vs. Objective-C. That was NOT the crux of my comment. Again, you're missing the point (you seem to be very talented at this).

The comparison is with Ruby ;)

Re: RubyMotion - Ruby for iOS

#124

I don't see the point of this. Objective-C is not hard to learn, and with ARC, blocks, the new literals for NSArray and NSDictionary, etc, Objective-C has actually become pleasant to write IMO. The example RubyMotion code also doesn't look very nice either. The problem with Rubyists (being one for the past 6 years I feel qualified to say this) is in general they want to use Ruby for everything. It's not always the be…

Forgive my ignorance of iOS, but do the current Objective-C based tools deliver "An interactive shell [...] for introspection, live coding and debugging" ? If RubyMotion can actually deliver a real first-class REPL that works, that would be a pretty huge deal. Lack of a REPL is the biggest reason why I dislike mobile (Android) development.

Yes, it's called GDB or LLDB, depending on your compiler. Not live coding though, but I don't know if that's a big deal.

Re: RubyMotion - Ruby for iOS

#125

I am not criticizing. This is a perfectly neutral question: Isn't the issue with a lot of these "look Ma, no Objective-C" approaches in that there are always little nagging issues here and there? I mean, Apple is constantly moving Objective-C/Xcode/iOS (notice I didn't say "forward"). Isn't it somewhat dangerous to adopt peripheral approaches for development rather than staying (suffering?) with the Apple-provided to…

What you have to keep in mind is that RubyMotion is not "just another wrapper". It is actually implemented on top of the Obj-C runtime. So that means Apple would have to make breaking changes to the runtime (the thing documented here: https://developer.apple.com/library/mac/#documentation/Cocoa...) in order to break RubyMotion.

Re: RubyMotion - Ruby for iOS

#126

Earlier quoted context omitted.

Isn't that really the difference between something like: def animate UIView.begin_animation yield UIView.commit_animation end animate do # Do something end and: void animate(void (^block)(void)) { [UIView beginAnimation]; block(); [UIView commitAnimation]; } animate(^ { // Do something }); Which to my eye are pretty much exactly the same. In fact, UIView already provides a similar method built into the API. Anyway, I…

In RubyMotion, you can do something like: def animate(*args) UIView.begin_animation yield(*args) UIView.commit_animation end animate(myButton, &buttonAnimateBlockFromSomewhereElse) animate(myView, myOtherView, &genericAnimateBlockFromSomewhereElseWithTwoArgs) animate do # Do something locally ignoring args end And, yes, you can do the same thing with Obj-C and some creative casts...but it's nicer in RubyMotion! (ymmv…

You do it this way:

    [UIView animateWithDuration:1.0f
                         animations:^{
                             self.view.alpha=0.0f; 
                         }];
Not so hard.

Re: RubyMotion - Ruby for iOS

#127
post #123
post #117

Earlier quoted context omitted.

I was specifically addressing this point (which seemed to be the crux of your comment): > Remove the concept of learning a new language, a new IDE, and only require that I learn a new lib to work against and I'm FAR quicker. That's a bit like saying, "Remove the concept of putting on running shoes and warming up and only require that I run a marathon and I'm FAR quicker." The time to tie your shoes is nothing compare…

> That's a bit like saying, "Remove the concept of putting on running shoes and warming up and only require that I run a marathon and I'm FAR quicker." It's not at all like saying that. Feel free to keep your words out of my mouth :) > ...is insignificant compared to the time it takes to learn Cocoa. I see you've changed from using the word "easy" to the word "learn." That's a step in the right direction :) Though, w…

I know you aren't comparing the time it takes to learn Cocoa vs. Objective-C. My point is that if you did make the comparison, you'd realize that if you have the time to learn Cocoa, you have the time to learn Objective-C, because the latter takes basically no time compared to the former. You get a time savings of like 0.05% by learning MacRuby instead of Objective-C.

Re: RubyMotion - Ruby for iOS

#128
post #118

Earlier quoted context omitted.

def foo(bar, baz: "something") is perfectly valid ruby(1.9).

Really? What on earth does it mean? The "baz: something" ought to parse as a hash literal, which isn't legal in a method declaration.

Sorry, I really should get some sleep: i read "foo(a: b)", but wrote what you wrote and complained about it. :)

You are right :).

Re: RubyMotion - Ruby for iOS

#129

Earlier quoted context omitted.

The call syntax is still painful compared to straight Objective-C as it actually uses more characters and is not as clean. I really wish he had come up with something that resembled Objective-C better.

If you want objective c syntax and behaviour surely you'd just use objective c?

Ruby is really nice for everything else, but the call syntax over to Objective-C is not quite good.

Re: RubyMotion - Ruby for iOS

#130
At the very beginning of the presentation he underlines the importance of the static compiler RubyMotion is based on, yet at 7:30 when he compiles a file with a name error in it the compiler doesn't even file a warning. Such non-existent methods and other similar errors should be caught at compile time if we're talking about solid AOT compilation.
Post reply on HN