> 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?
RubyMotion - Ruby for iOS
121–130 of 250 posts
Re: RubyMotion - Ruby for iOS
#122Earlier 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.
Re: RubyMotion - Ruby for iOS
#123Earlier 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…
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
#124I 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.
Re: RubyMotion - Ruby for iOS
#125I 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…
Re: RubyMotion - Ruby for iOS
#126Earlier 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…
[UIView animateWithDuration:1.0f
animations:^{
self.view.alpha=0.0f;
}];
Not so hard.Re: RubyMotion - Ruby for iOS
#127Earlier 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…
Re: RubyMotion - Ruby for iOS
#128Earlier 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.
You are right :).
Re: RubyMotion - Ruby for iOS
#129Earlier 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?