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.
RubyMotion - Ruby for iOS
101–110 of 250 posts
Re: RubyMotion - Ruby for iOS
#102Earlier quoted context omitted.
Speed is what you're missing. Not to denigrate you or your statement, and yes Objective-C is not that hard to learn, but it comes down to speed. If I've never programmed in Objective-C and if I'm experienced in Ruby my time from concept to live iPhone app can be FAR quicker by using the tools/language I'm already familiar with (regardless of which tools/language). Remove the concept of learning a new language, a new…
Compared to learning Cocoa (Touch), Objective-C is really nothing — especially since to use MacRuby you have to learn a bunch of kinda-awkward hacks they've stuck on top of Ruby to make it compatible with Objective-C (e.g. the "def foo(bar, baz:quux)" syntax and Pointers). It's a very simple language. Unless you are exceptionally bad at learning syntax, you're really not saving yourself a whole lot of time.
Re: RubyMotion - Ruby for iOS
#103Earlier quoted context omitted.
Speed is what you're missing. Not to denigrate you or your statement, and yes Objective-C is not that hard to learn, but it comes down to speed. If I've never programmed in Objective-C and if I'm experienced in Ruby my time from concept to live iPhone app can be FAR quicker by using the tools/language I'm already familiar with (regardless of which tools/language). Remove the concept of learning a new language, a new…
Compared to learning Cocoa (Touch), Objective-C is really nothing — especially since to use MacRuby you have to learn a bunch of kinda-awkward hacks they've stuck on top of Ruby to make it compatible with Objective-C (e.g. the "def foo(bar, baz:quux)" syntax and Pointers). It's a very simple language. Unless you are exceptionally bad at learning syntax, you're really not saving yourself a whole lot of time.
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.
Re: RubyMotion - Ruby for iOS
#104No interface builder? Depending on what type of apps you make it can be a big issue I think
With RubyMotion you get to roughly lay out your controls, and then you get to use the interactive interpreter for fine-grained adjustments. See around the 5:30 mark in the getting started video for an example.
Re: RubyMotion - Ruby for iOS
#105Earlier 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…
> UIView already provides a similar method built into the API. Yeah, it's actually much, much simpler to do it in Objective-C in this case. [UIView animateWithDuration:0.5f animations:^{ // Do something }];
UIView.animateWithDuration(0.5, animations:lambda { //do something })
in RubyMotion. Basically the same.
Re: RubyMotion - Ruby for iOS
#106So this should be compatible with cocos2d right?
Re: RubyMotion - Ruby for iOS
#107Earlier quoted context omitted.
I think you'll find the difference between working with Cocoa APIs in Obj-C vs Ruby is that it's much easier in Ruby to turn what you've learned into a simple, boiled-down, easier to digest set of helper methods/objects/modules. For example, in using the RubyMotion beta, after I understood the UIView animation flow, I created a helper method using "yield" to do the actual animation. If I were working in Obj-C, it wou…
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…
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)Re: RubyMotion - Ruby for iOS
#108I 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…
This is a step in the right direction, a step toward getting immediate and interactive results when you code.
The piece that I find a tiny bit lacking is disconnect between what you futz with in the REPL and what is your source. By that I mean, all the manual tinkering in the REPL isn't saved anywhere, you have to copy and paste.
Emacs rectifies this sort of thing a little with swank and slime. Maybe there will be a mode for RubyMotion.
Re: RubyMotion - Ruby for iOS
#109Isn'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 tools?
Now, if someone has an alternative IDE that truly allows me to record Xcode to a DVD and perform a ritual burning ceremony of said DVD...that would be something.