I write code in both Ruby and Objective C pretty regularly, but man oh man is my Ruby code SO MUCH shorter and cleaner in a lot of respects. A lot of the Objective-C API's are just terribly terribly verbose. My favorite one to whine about is NSTask; it shouldn't take me 10 lines of code to spawn a simple external process. :P
For me, I prefer working in Ruby. Some people don't. But I think this will probably spurn me to get more serious about writing more iPhone apps, and it should open the door for a few more people who work on Ruby-based apps to write their own simple iPhone apps rather than paying a consultant to do it for them.
I can use Ruby's nice facilities for external processes (e.g., "x = `ls`" to get a directory listing or "system('do_something')") or simple regular expressions (i.e., "'string' =~ /my_regex/" and friends vs. NSRegularExpression's verbose syntax). I'm not forced to use Cocoa's verbose API if it has a nice Ruby wrapper (and if it doesn't have one, I can make one).
Is what 95% of the code in your app is going to look like and I don't really see what it's buying you. You're also throwing away all the type checking you'd get on essentially the same code in Obj-C.
I really like Ruby but I don't intend to use it for iOS apps.
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.
Some people hate interface builder and don't use it at all. I really like it and would have a really hard time getting rid of it. The amount of code you would need to write to make all of your views would be terrible.
I would liken it to not using HTML when you're making a web app and you can only use javascript to generate (by hand) all of the UI.
Except that I feel the control you lost by using IB is smaller compared to the control you lose by using an HTML builder. But then again, it's been forever since I last used an HTML builder.
In both cases, there are border cases that need to be handled in code (or markup).
I quite like Interface Builder, and this sounds like a bit of a deal-breaker for me. I'd rather not have my controllers cluttered with UI-positioning code, etc. It's a much more elegant way to create you UI (most of the time).
In relation to working with Appcelerator or a similar system that allows you to load in images/views/visuals & position programmatically, I wouldn't say it's a problem, more a shift in practice.
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.
I may have missed something but API calls looks like a regular Ruby call with a hash and since all [] are dropped it's systematically shorter (not even counting the fact that you don't have .h/.m, declaration/implementation, it's not just a matter of API calls).
i.e. [obj method: param second: param2]; vs obj.method(param, second: param2) which is exactly two characters shorter in ruby.
And what would be the point of having something that looks like Objective-C?
In the Ruby version I wouldn't use that selector with any parens. The resulting line would be one character longer than the ObjC version but use the Shift key one less time and would avoid two pinky trips out to the square brackets. (unless I am miscounting)
All other things being equal between the two options, and of course they aren't but let's just keep splitting hairs for a moment, it sounds like a typing win for the Ruby option. Readability is of course in the eye of the beholder.
What language features does Ruby have that Objective-C lacks? It's a bit more succinct, perhaps, but when you're calling out to Cocoa all the time, that succinctness is going to get thrown out the window.
Ruby has "yield" which, while possible to replicate in Obj-C, it's not nearly as nice. Also, Ruby can yield arguments, and the block being yielded to is free to ignore those arguments. That's the sort of flexibility that can make Ruby so much more enjoyable to work with in high-level code.
I did some looking, and I found a few[1] examples[2] of coroutines in Objective-C, though none of them seemed fully fleshed-out. Even if they were, none were, as you say, nearly as nice as "yield".
It depends, if your background is in dynamic languages like Perl, Ruby, Python than using Ruby for iOS makes a lot of sense. On the plus side Ruby is better for programmer productivity.
If you have a good background in C than yes, using Objective-C is not so difficult.
I concur with the other posters who say Objective-C itself is not the barrier, the API is. Such is the design and verbosity of the API (which is great for self-documentation and talking about, less so for typing), it'd be an absolute nightmare to work with without the extensive auto-complete Xcode offers.
This is a very exciting (and very positive) development, but at this moment in time I would still bite the bullet with Objective-C. I came to it with a background in PHP of all things and didn't struggle with picking it up in a few weeks.
I can't wait to see the things people do with it and with Ruby's metaprogramming.
