Hacker News Reader

Comment by hlidotbe | Hacker News Reader

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.

View on HN

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

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.

Reply on news.ycombinator.com