
Why RubyMotion Is Better Than Objective-C - Veraticus
http://joshsymonds.com/blog/2012/05/04/why-rubymotion-is-better-than-objective-c/
======
GuiA
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.

~~~
mcdillon
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!

------
poutine
\- 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 evolving.

\- Xcode Hides Important Information

It has a learning curve. Some things take time to learn but once you do you're
more productive.

\- Objective-C Is Tedious

Matter of opinion. One person's tedium is another being explicit and reaping
the benefits during refactoring, code completion and compilation speed.

\- RubyMotion is Easy to Use

For sure easier than Objective-C. But so what? Can it build complex apps more
quickly than Objective-C when someone becomes proficient? Probably not.

\- RubyMotion is Ruby

That's great. Ruby is a great, easy to use and powerful language. I love Ruby.
However given all the other things you sacrifice to get Ruby it's really not
worth it.

\- RubyMotion Makes Debugging Easy

Really? It sure doesn't look like it does. Xcode and LLVM save me a hell of a
lot of time writing my apps because I don't need to actually run them and see
the exceptions. And what about the static analyzer?

\- RubyMotion Isn’t Perfect

Indeed.

\- Better Than Objective-C

For trivial apps yes. For apps you'll be paid to write, in my opinion probably
not.

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

~~~
bunderbunder
Score one for ObjC's use of reference counting instead of a garbage collector
on iOS, too.

Now don't get me wrong, I'm normally of the opinion that anything that whiffs
of manual memory management is for chumps. But by day I write apps that target
workstations that have enough RAM that I can get away with pretending that
memory is an unlimited resource.

On a memory-constrained platform like iOS, though, being able to tightly
control how much memory you're using becomes much more valuable. If not
critical. And the one place where garbage collection simply can't beat manual
memory management is total memory consumed. All those dead objects that are
waiting around to be scooped up by the collector do take up space. Sometimes a
whole lot of it.

~~~
ryanpetrich
It's not all rainbows and butterflies. From the RubyMotion documentation:
"Object cycles, when two or more objects refer to each other, are currently
not handled by the runtime, but will be in future releases."

------
tudorizer
Here we go again. Another "Obj-C killer". "Ooh, that ugly obj-c is so
unproductive!".

Currently I'm mainting a couple of medium to big obj-c projects and one big
ROR custom CMS. My background was mostly in Python. A few years ago this
sharade of writing faster obj-c app started. You guys might have heard of Wax
(in Lua) which seemed to have a similar concept to RubyMobtion (of course, w/o
the shiny presentation style that comes with the ROR community). After rolling
my sleeves and digging into Obj-C (and CocoaTouch), all other alternatives
look like made for people who are comfy/lazy and stick to writing in high-
level scripting languages. If they admit their status, no problem, just that
personally I would not bet medium-to-big project on anything else except plain
obj-c.

The "RubyMotion Makes Debugging Easy" is the silliest part. Good luck on using
GDB/LLDB!

Note: _sharade_ and other casual language was in no intent meant to discredit
the hard work put in by the developers of such tools. Full respect for the
gents behind RubyMotion. They are building a fair business.

All and all, stop whining and get to know both sides.

~~~
Posibyte
_All and all, stop whining and get to know both sides._

A bad workman blames his tools. And, from what I read from the author, that's
what he's doing. He doesn't understand trivial software patterns, such as
pocketing like types into arrays (I hope everybody who took Programming 1
remembers this), and insists on doing things the Ruby way without a clear
understanding of why Obj-C is actually a pretty good tool.

------
natesm
> Why do I have to have huge statements like this?

Uh, because you're declaring six static color variables. Also, they _could_ be
collapsed into one line.

> Introspection is unavailable at runtime

Not sure what this means. Everything is introspectable in Objective-C. #import
<objc/runtime.h>

The cell dequeueing comparison uses a one liner for Ruby and an if statement
for Obj-C. That's not a fair comparison. "dequeue ?: allocate" would be fair.

> dequeueReusableCellWithIdentifier, ugh.

What is wrong with this?

• I am dequeueing something from the receiver.

• It is a reusable cell.

• The first (and only) argument is the identifier for the cell.

What would be a better name, without losing the descriptiveness?

> Without tab completion, you do a lot of copying and pasting from the
> documentation when you find a method name you like, just to ensure you don’t
> accidentally typo it.

This is a huge problem, not a minor thing! The whole point of those "long"
message (not method, btw, but that's minor) names is that you don't have to
read documentation. If you want to append a format to a string, but don't know
the name, just start typing "stringby" and the names _are_ the documentation.

~~~
Davertron

      > dequeueReusableCellWithIdentifier, ugh.
      What is wrong with this?
      • I am dequeueing something from the receiver.
      • It is a reusable cell.
      • The first (and only) argument is the identifier for the cell.
      What would be a better name, without losing the descriptiveness?
    

I don't think he's complaining about the name of the method, he's complaining
about the fact that he has to type it all out now instead of Xcode completing
it for him, which is a gripe against RubyMotion, not Objective-C or the cocoa
API.

~~~
spullara
Xcode does complete it for you. So does JetBrains AppCode. I bet RubyMine
would too with RubyMotion.

IMHO, the name sucks because it includes information in the name that is also
in the signature. At least it would be in languages that support overloading.

~~~
ryanpetrich
Text editors don't display method signatures (some IDEs do, but usually only
in tooltips or autocomplete). When writing code in Java or C I often find
myself looking up the method/function definition to be certain which argument
is which.

------
gte910h
The lack of IB support makes the otherwise "Ruby that Looks Too Much Like
Objective C" a bit of a net loss. You lose IB, and the ability to easily
integrate the approaches all the thousands of examples and questions do.

I'm _very_ interested to see where this ends up however. I'd love to do iPhone
programming (with IB support) in python or ruby. Just not with this tool, just
yet.

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

~~~
pbnjay
Agreed. I'm sure obj-c is horrible if you keep expecting it to be like Ruby...
people need to embrace the idioms and syntax of the language they're actually
using.

After using it for almost a year, I find obj-c really nice now. But that was
only after I got out of the C/C++ mindset and more into obj-c mindset.

------
nanijoe
I would have killed for this about 2 years ago, but now that I learned
Objective C, I'm comfortable enough with its quirks that I can just use it to
get stuff done.. Having to learn the nuances of RubyMotion in order to do
stuff I already know how to do, is probably very very low on my priority list.

~~~
glenra
Hmm, I gave up on Objective C about 2 years ago, so learning RubyMotion now is
tempting. :-)

------
cageface
I've written more code in Ruby than in any other language over the last ten
years and I intend to continue using it where it's appropriate. But I have to
agree with a lot of other posters that this just seems like a case of people
being too lazy to learn something new. If we were talking about the old Obj-C
without blocks, ARC and collection literals, I might be more sympathetic. But
this just doesn't seem like enough of an improvement to throw out static
typing, a decent visual debugger, and first-class, unmediated access to the
native APIs without a clumsy pseudo-selector syntax.

It's true that Xcode is bad, but the solution to that is to use AppCode, not
to throw out the language.

------
comatose_kid
Get back to us when you've written a significant application in either
Objective C, or RubyMotion.

------
mrsteveman1
The frameworks themselves sometimes impose verbosity, changing syntax used to
work with them isn't going to do anything about that.

I've seen quite a few examples since yesterday where the code given was not
fewer in line count or even easier to read (partly subjective), but was simply
more approachable and familiar to people who are already set on writing Ruby
instead of ObjC.

If you know ruby very well you may get a head start here without having to
learn ObjC (yet, i'll be shocked if you dont hit walls with this plan), but
the mountain of work for you is learning the frameworks, and learning them
without the benefit of 90% of the examples and help available specifically for
ObjC.

And what of working with the parts of Apple's platforms that aren't
Objective-C in the first place, like all the CoreFoundation stuff which is C.
At some point you're going to hit walls that could be easily solved by dashing
your code with a few lines of C or dropping in an example you found on
stackoverflow, but now you've got to come up with the Ruby equivalent and
you're actually juggling a new set of issues whether it seems that way or not.
Maybe the time you save writing most of an App in ruby makes up for it, but
I'd be surprised if thats the case in practice.

------
mattetti
I wrote a somewhat more balanced review based on my experience with RubyMotion
over the last few months (beta testing)
[http://merbist.com/2012/05/04/macruby-on-ios-rubymotion-
revi...](http://merbist.com/2012/05/04/macruby-on-ios-rubymotion-review/)

~~~
cageface
_While RubyMotion is by far, the best alternative to Objective-C but it is
hard to tell 48 hours after its release what people will do with it._

What about MonoTouch? To be honest I think I'd look at that first if I wanted
something other than Obj-C. At least I could take my non-UI code and run it on
Android.

------
stcredzero
_This is the power of Ruby + Objective-C: you get Ruby’s powerful and
expressive enumerators, metaprogramming, and reflection, but Objective-C’s
APIs and libraries. It’s like chocolate and peanut butter, they just go
together so well._

Not the best researched sentence. Much of this is possible in RubyMotion
because of Objective-C's metaprogramming and reflection and other powerful
features. This makes me suspect the author's depth of knowledge of
Objective-C. That said, he's right that Objective-C has a lot more syntactic
noise than more recent languages like Ruby and Python.

------
rabbitonrails
As someone who has developed and released iOs apps in Titanium before (write
JS / coffee, compile to native app), I am curious about RubyMotion's
performance. One of Titanium's weaknesses is that it is extremely inefficient
in certain views (e.g. tableViewsRows) to the point where if you are
loading/sorting any appreciable amount of data you can only display a few
labels within the view without the app grinding to a halt -- on average
iPhones.

I am not sure if the RubyMotion approach is different than Titanium -- does
anyone know whether it is faster and why?

------
e28eta
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 I'd do
that in my storyboard, and it would take zero lines of code. Or 6 lines of XML
for 6 labels, if I'm being pedantic.

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

------
fusiongyro
I'm not finished with the article, but so far it reads like "Look at this Ruby
code! It's much nicer than this Objective-C code! See! SEE!!"

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

~~~
cageface
As many other posters have noted, learning Obj-C is about 5% of the battle.
Getting to grips with the APIs is the hard part and you have to learn them
whether you decide to use Obj-C, RubyMotion or MonoTouch.

So if you think that Ruby is providing you with a significant shortcut here
you're in for some disappointment.

~~~
fusiongyro
On top of this, when Apple releases new frameworks, the Obj-C users get to use
them immediately. People using weird bridges are giving their competition a
huge time boost by voluntarily delaying their own access to the new stuff.

I worked for a company doing Mac apps in REALbasic for several years, and this
was a constant hassle. Additionally, RB chose the wrong backend for their
compiler (Carbon instead of Cocoa) and there were multiple _years_ of setbacks
due to Apple hemming and hawing about whether they were going to deprecate
Carbon altogether and RB porting their entire framework to Cocoa. During that
process, everybody who emigrated to Objective-C got their stuff to market
sooner, and with access to newer libraries to boot.

------
peterjs
I've been programming a 3D application in Objective-C for a few months. There
are things I like, dislike and find really confusing about the language. The
thing is, you have to learn and understand it before making assumptions based
on "hello world"-like pieces of code. The best "feature" I found so far is not
even a feature. It is the way the language is designed simultaneously with the
framework/os. It feels more compact and makes reasoning about programs easier.

The second is the way in which complex applications are built. Some
programming languages are known for having many design patterns around them,
which often feel artificial. Objective-C and the Cocoa libraries use only a
handful of them, but they come very natural.

------
frou_dh
_Not that it's an invalid position_ , but when Apple-centric developers
proclaim 'ObjC > C++' in such a matter-of-fact way, I always wonder how much
that is based on actual real-world experience.

~~~
mistercow
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 complicated to learn the ropes of.

So I guess what I'm saying is that a lot of people criticizing C++ probably
_don't_ have much experience with it, but that's kind of the point.

~~~
Derbasti
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 without performance compromises, but
at the expense of readability.

For the longest time, I would hands down prefer Obj-C to C++ just because it
was simpler. The more experienced I become with C++, the more I am able to
appreciate its power and no-compromise attitude, though.

~~~
stcredzero
_C++ is simply way more complicated than Obj-C._

Also, Obj-C is somewhat more complicated than Ruby, though there is a _lot_ of
Ruby if you go looking. Obj-C is also more syntactically noisy than Ruby.

~~~
mistercow
Do you mean that Ruby code tends to be simpler than Objective-C code, or that
the language itself is actually simpler. Because, while I haven't done a
formal comparison or anything, I would find the latter to be pretty unlikely.
Most of Objective-C can really be boiled down to little more than few
teaspoons of syntax sugar on top of C (although that is less true today than
it once was), and C is _definitely_ a simpler language than Ruby.

------
cmelbye
This project is really interesting to me, but my biggest issue is the code
completion issue. I can deal with writing UI code manually, but Cocoa's APIs
are complicated and I find it difficult to remember the method names, argument
names, etc. Ruby's nicer array and dictionary syntax may make that easier
though (alleviating the need for [NSArray arrayWithObjects:...], [NSDictionary
dictionaryWithBlahblah] and replacing it with simply [] and {} to remove
complexity.)

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

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

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

------
EternalFury
Why would you say it's better than Objective-C? Since anything it can do has
to exist in the Objective-C framework offered by Apple, it is probably
equivalent.

Also, let's not forget 90% of things that make money in the App Store are
games. RubyMotion doesn't seem to do much to help you with that.

In other words, for Rubyists, RubyMotion is a thin wrapper around Objective-C
classes that feels like home. For everyone else, it's an added layer that
provides a thin sugar coating and not much else.

------
pbnjay
The REPL/debugging looks "better" than iOS obj-c, but I'm not seeing any other
"better" here. Ruby syntax is not "better" than obj-c syntax, it's just
different.

------
pazimzadeh
Isn't RubyMotion always going to lag behind Objective-C in terms of
implementing any new features by Apple?

In the same vein that allowing Flash and C# toolkits above Cocoa Touch would
slow the adoption new features
([http://daringfireball.net/2010/04/why_apple_changed_section_...](http://daringfireball.net/2010/04/why_apple_changed_section_331)).

------
randomdata
Xcode may be unstable, but you can write Objective-C in any text editor. And
since Xcode shells out to regular command line tools, you can do the same
under any environment you wish.

------
Yarnage
>>>Don’t get me wrong, Objective-C is better than C or C++, but I don’t think
that’s saying a whole lot.

Objective-C better than C++? Wow, has this person ever used Objective-C and
C++?

~~~
RandallBrown
Do you really like C++ better than Objective-C? I've been writing both for the
past few years and I have to say I greatly prefer Objective-C.

~~~
trevorchill
Yes, I much prefer C++.

There is a recurring problem in which languages outgrow their original syntax
when applied to new programming paradigms.

For example, accessing an array in C uses simple syntax: arr[5] = 10;

But with NSArrays, etc., we have to add lots of explicit method calls with
lots of named arguments, destroying the clear and simple syntax meant to
express use of an array in C.

The nice thing about C++ is that you can fix that by overloading operators so
that a vector can use the same simple syntax most of the time. You can do this
for any objects for which it makes sense... And it vastly improves the ease of
coding and reading code.

In objective c, you simply can't improve it. Tons of operations with
containers and objects are unnecessarily syntactically unwieldy. Higher level
languages like Ruby do this as well, but C++ is fast and explicit. If you want
to know what the operator is doing, you can step into it. You can read the
code...

------
stevencorona
RubyMotion looks awesome, but I'd really love to have IB support

------
debacle
I don't understand why anyone should have to justify this. It's like saying
"Why C# Is Better Than C."

It's a higher level language, which allows you to get more work done faster.
Case closed.

~~~
poutine
Not case closed. Given that you lose a lot of useful tools (Interface Builder,
Storyboards and such) and that Objective-C can be pretty quick to code with
Xcode I would contend that given expertise in both a complex application would
take less time to code in Xcode/Objective C.

