Hacker News Reader

Comment by tobiasbischoff | Hacker News Reader

nice, but where is the advantage over just using objc? the hard part of coding for iOS isn't objc, it's learning how to use all the API's.

View on HN

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.

But you're going to be coding to those same Apis in ruby too, just with a lightly different syntax.

No, actually.

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).

This:

https://github.com/HipByte/RubyMotionSamples/blob/master/Ges...

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.

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?

I was looking at the example and their are a fair number of commas. If you pass 3 selectors it is longer.

  UIColor.colorWithRed(red/100.0, green:green/100.0, blue:blue/100.0, alpha:1.0)

  [UIColor colorWithRed:red/100.0 green:green/100.0 blue:blue/100.0 alpha:1.0];

>And what would be the point of having something that looks like Objective-C?

Because the name of the function is not colorWithRed(), it is colorWithRed:blue:green:alpha:.

Seeing as we're splitting hairs... :)

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.

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.

In the Ars article, I noticed the author mentions you can't use XCode's layout tools.

In practice, how big a problem is that?

I tried a bit, technically it works but currently you have to compile your xib to nib manually using ibtool.

That may have changed tough because I dropped the xib as I didn't really needed it.

How does that work? Layout the view, convert the XIB to NIB, and load it at runtime?

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).

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.

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).

I bet they are working on it, though...

I agree, but many young developers have C phobia and somehow seem not to be able to grasp C based languages.

Or they've been spoiled by certain language features and it seems unbearable to go backwards.

Personally I find great that we have a native Ruby compiler, even if it means a static language with Ruby like syntax in the end.

I hope for the day when we have better and more type safe languages for system programming.

Most attempts so far, Modula-* family, Ada, Oberon and so on, failed to catch on, to my dismay.

Still it does not hurt to know some C.

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.

That's a great example, thanks!

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".

[1]: http://cocoadev.com/wiki/CSCoroutineTest

[2]: https://gist.github.com/1033477

I like C but have Obj-C-aversion because "high level" languages that still need header files all over the place just ain't right.

There I agree with you.

Header files are so 70's.

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.

Reply on news.ycombinator.com