21–30 of 31 posts
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.
Earlier quoted context omitted.
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…
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.
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 intera…
You could certainly us it for GUI interactions. Take the MacRuby equivalent to:
[[[[[[[UIApplication] sharedApplication] delegate] window] rootViewController] view]
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.
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.
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,…
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.
Earlier quoted context omitted.
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.
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
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 intera…
> 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] rootViewCon…