Live data from Hacker News

Why RubyMotion Is Better Than Objective-C

joshsymonds.com

31–40 of 70 posts

Re: Why RubyMotion Is Better Than Objective-C

#31
post #19

- Objective-C is Hard to Use It has a much steeper learning curve than Ruby for sure, but once you're proficient it's no harder to use. Indeed there's benefits to both languages. - Xcode is Unstable It's gone through periods of instability. But in the current version you may encounter the odd crash (perhaps once a week in full time use for me). Really not an issue given it's a cutting edge tool that's rapidly evolvin…

I have yet to write an iOS app where I didn't at least once dip down into raw C for speed and/or control. On resource constrained platforms Obj-C's ability to go from high to low in a line of code is a big competitive advantage. I don't give that up lightly.

If RubyMotion offered a truly higher level abstraction over Cocoa Touch or offered cross-platform portability I might be interested but an arguably better syntax over the same API just isn't enough of a win.

Re: Why RubyMotion Is Better Than Objective-C

#32
post #16

I agree that for some people, RubyMotion may be better than ObjC. I'm not one of them. Regardless, I think your Ruby code examples could have been better chosen: - I'm a huge fan of Ruby's || operator, but probably wouldn't use it to dequeue or create a table cell, because the line is way too long. Perhaps this is fixable with a return after the || - creating labels programmatically seems like a poor example because…

Also, the || operator can be written ?: in Objective-C.

Re: Why RubyMotion Is Better Than Objective-C

#33

Earlier quoted context omitted.

Well see part of the problem is that it takes more experience to know your way around C++; it's just bigger than Objective-C, even if you only talk about the "commonly used" parts. If you know C and are reasonably familiar with OO, you can easily learn all of the important differences between C and Objective-C in a week or so. And since it's a true superset, everything you know from C carries over. C++ is just more c…

Exactly. C++ is simply way more complicated than Obj-C. Also, the Obj-C object system is pretty high level and dynamic (message passing, late binding, dynamic dispatch). This makes it somewhat slower at method calling, but at the same time a lot easier to work with. The downside of being slow is usually mitigated by simply being able to drop back to plain old C if need be. Of course, C++ can emulate all that, and wit…

There is, of course, also Objective-C++. In my naïve younger days, I used that so I could have operator overloading in Objective-C. What a nightmare.

Re: Why RubyMotion Is Better Than Objective-C

#34

Ramblings like this are a premier example of what is wrong with engineers today. If you are afraid to learn or use tools outside of ruby, you are not a true engineer. The world does not revolve around ruby. Get some real iOS development under your belt before you make these broad assumptions.

Last time I checked engineering was about producing solid and creative results in smart ways.

If using Ruby for a developer to produce the same result is more productive, then not using Ruby Motion would be a crime against "true" engineering.

Re: Why RubyMotion Is Better Than Objective-C

#35
post #16

I agree that for some people, RubyMotion may be better than ObjC. I'm not one of them. Regardless, I think your Ruby code examples could have been better chosen: - I'm a huge fan of Ruby's || operator, but probably wouldn't use it to dequeue or create a table cell, because the line is way too long. Perhaps this is fixable with a return after the || - creating labels programmatically seems like a poor example because…

A possible Objective-C version to create the labels looks pretty much the same to me anyway:

    #define MSTR(...) [[NSString stringWithFormat:__VA_ARGS__] UTF8String]
    
    @implementation LotsaLabels

    - (id)initWithFrame:(CGRect)frame
    {
      if (self = [super init]) {
        CGFloat offset = 0.0;

        [@[@"label1", @"label2", @"label3", @"label4"] enumerateObjectUsingBlock:^ (id object, NSInteger idx, BOOL *stop) {
          object_setInstanceVariable(self, MSTR(@"%@_text", object), [[UILabel alloc] initWithFrame:CGRectMake(0, 10 + offset, self.frame.size.width, 40)]);
          object_setInstanceVariable(self, MSTR(@"%@_label", object), [[UILabel alloc] initWithFrame:CGRectMake(0, 55 + offset, self.frame.size.width, 14)]);
 
          UILabel *text = object_getInstanceVariable(self, MSTR(@"%@_text", object));
          UILabel *label = object_getInstanceVariable(self, MSTR(@"%@_label", object));
 
          text.font = [UIFont fontWithName:@"Arial Rounded MT Bold" size:40];
          text.textColor = [UIColor redColor];
          label.font = [UIFont fontWithName:@"Arial Rounded MT Bold" size:15];
          text.textColor = [UIColor grayColor];
 
          text.text = label.text = [object capitalizedString];
          text.adjustsFontSizeToFitWidth = label.adjustsFontSizeToFitWidth = YES;
          text.backgroundColor = label.backgroundColor = [UIColor clearColor];
          text.textAlignment = label.textAlignment = UITextAlignmentCenter;
 
          [self addSubview:text];
          [self addSubview:label];
 
          offset += 90.0;
        }];
      }

      return self;
    }

    @end
The Ruby version is slightly less verbose, I'll give him that, but many of the lines are nearly identical.

Re: Why RubyMotion Is Better Than Objective-C

#36
Seen in the article:

"Why do I have to have huge statements like this?

static UIColor firstColor = nil;

static UIColor secondColor = nil;

static UIColor thirdColor = nil;

static UIColor fourthColor = nil;

static UIColor fifthColor = nil;

static UIColor sixthColor = nil; "

Great, so someone who doesn't know how to use arrays is criticizing Objective-C as a language.

To everyone claiming that Objective-C's syntax is unintuitive/unwieldly/etc: remember that familiar != intuitive.

My two darling languages are Python and Haskell and I learned programming in C/assembly, and I find Objective C + Cocoa Touch quite nice, especially since ARC was introduced. Yes, there are things that can be slightly bothering, but once you pass the initial "wow this syntax is weird" hurdle, you're good to go.

It's great to have Ruby as an alternative, but all that Objective-C hating is silly and quite unproductive. Yes, there are limitations in the iOS dev stack (mostly with XCode— but hey, it's not that bad, people have gotten good things done with Eclipse and it doesn't exactly have a perfect track record either). But if the only thing that's getting in your way of developing a great application is the fact that Objective C's syntax makes you uneasy, then you should probably reconsider your abilities as an engineer.

As usual, the ones doing great things done probably won't be the ones tweeting & blogging about how Objective-C is lame and that if only $(arbitrary language) could be used for iPhone dev, then they would change the world.

Re: Why RubyMotion Is Better Than Objective-C

#37
In my opinion lot of these threads completely miss the point of a tool like RubyMotion. It isn't about which solution is "better"...it is about ease of use for the large number of people that already know Ruby, and want to leverage that knowledge into exploring IOS development. Not everyone has the time or inclination to learn Objective-C right now, even though we can all agree that learning other languages is a good thing. This clearly scratches a market itch, will be supported by a great community that will layer tons of syntactic sugar and cleaverness over any verbosity/UI tool problems, and will likely grow into something truly great for the market it seeks to serve. I think it makes for one hell of a 1.0 MVP release.

Re: Why RubyMotion Is Better Than Objective-C

#38
post #29

Earlier quoted context omitted.

Objective C's collection syntax is terrible and is easily the worst thing in the language. Apple fixed it with collection literals in OS X 10.8 though and those enhancements are almost certainly coming to iOS soon.

Is it true that those are only available in 10.8? It thought they just compiled to +[NSArray arrayWithObjects:count] calls, which would work anywhere.

As far as I understand they required patches to LLVM so it may be that the resulting code would also work on older releases and don't need runtime support. But the version of Xcode that supports them is only available for Mac devs, as far as I can tell.

Re: Why RubyMotion Is Better Than Objective-C

#39
post #27
post #19

- Objective-C is Hard to Use It has a much steeper learning curve than Ruby for sure, but once you're proficient it's no harder to use. Indeed there's benefits to both languages. - Xcode is Unstable It's gone through periods of instability. But in the current version you may encounter the odd crash (perhaps once a week in full time use for me). Really not an issue given it's a cutting edge tool that's rapidly evolvin…

All of these points are subjective, why are you trying to argue against them?..

Because I wanted to? It's the Internet.

Re: Why RubyMotion Is Better Than Objective-C

#40
post #36

Seen in the article: "Why do I have to have huge statements like this? static UIColor firstColor = nil; static UIColor secondColor = nil; static UIColor thirdColor = nil; static UIColor fourthColor = nil; static UIColor fifthColor = nil; static UIColor sixthColor = nil; " Great, so someone who doesn't know how to use arrays is criticizing Objective-C as a language. To everyone claiming that Objective-C's syntax is un…

In addition to your points; I'm not a fan of sensationalist blog posts that start off with whining about how something is hard even though the 'about me' section states how awesome they are at writing code. This seriously just screams hey come read my blog!
Post reply on HN