

RubyMotion pros and cons - mattetti
http://merbist.com/2012/05/04/macruby-on-ios-rubymotion-review/

======
objclxt
This is probably one of the better articles on RubyMotion: mainly in that it's
fairly balanced...it annoys me to see posts like "Why Ruby Motion is Better
than Objective-C", or "Ruby Motion: The Worst Thing to Happen to iOS"...

As an Objective-C developer who knows very little Ruby, this probably isn't
for me. But I can't see how opening up iOS to a wider range of developers is a
bad thing: personally, I'm an Objective-C fan, but I can see why people don't
like it, and if you're at a start-up or a small team looking to get some app
deployed and you don't want the hassle of learning Objective-C then this seems
like a great alternative.

So like any language or environment there are pros (the REPL looks amazing)
and cons (closed source, at least in my view). And whilst I'm sure this wasn't
the intention of RubyMotion at all it's actually making me revisit Ruby as an
Objective-C developer and see if I can improve my knowledge and experience of
it. No bad thing!

------
chrisdevereux
_Even though ARC made memory management much easier for Objective-C
developers, when using RubyMotion you don’t have to worry about memory (well
at least not explicitly, don’t be dumb and create a bazillion objects and hold
references to them either)_

I'm not convinced about this. Here's a quote from the rubymotion runtime
guide:

 _RubyMotion’s memory management system is designed to simplify the
development process. Unlike traditional Objective-C programming, object
references are automatically created and destroyed by the system. It is very
similar to Objective-C’s ARC, in design, but it is differently implemented._

 _Object cycles, when two or more objects refer to each other, are currently
not handled by the runtime, but will be in future releases._

There are a lot of things that look really cool about RubyMotion, but it
doesn't seem to me that memory management is massively different to the
situation in Objective-C with ARC on, or indeed C++ with smart pointers.

They haven't said how weak references are going to be handled, but it seems
like the programmer will have to specify that a reference should be weak. In
that case, the difficult part of memory management in a non-gc langage ---
making sure you avoid either reference cycles, or inadvertently deallocating
objects --- is still there in rubymotion.

(disclaimer: I haven't used rubymotion -- I'm just going on what's been
published about it)

------
stcredzero
_REPL/Interactive shell

RubyMotion doesn’t currently have a debugger, but it does have something
Objective-C developers don’t have, a REPL working with the simulator. ... You
can click on a visual element in the simulator and start modifying the objects
in real time in a terminal window and see the modifications in the simulator.
It reminds me of the first time I used firebug to edit the html/css of a web
page and saw the changes in real time._

This might be the real strength of RubyMotion. Maybe someone should take
Squeak/Pharo Smalltalk and create a utility that can be used as a REPL working
with the iOS simulator. Smalltalk is basically Objective-C minus the C parts,
types, and the glue to attach the C parts, so it would be the perfect REPL for
the simulator. All you're left with is keywords and variables. Developers can
insert this into projects for prototyping and debugging, but take it out when
they deliver apps.

~~~
mpweiher
I did the original Cocoa Squeak VM, and in the end found it too heavy-weight
for my taste, so I developed Objective-Smalltalk instead. It's been in use in
a couple of my products for a number of years, and recently I've adapted it
for use in iOS. Even reserved the objective.st domain, but haven't populated
it yet...

~~~
hboon
Would love to check it out. Any way to get notified when you do?

------
VeejayRampay
Optionally typed Ruby would be interesting indeed.

Kind of wondering how that would work in practice though...

~~~
gerrit
Have a look at Mirah[1] a statically typed ruby-like language that runs on the
JVM, by Charles Nutter, the main jRuby developer. Here's an article [2] with
short descriptions of Mirah and other Ruby-dialects or Ruby-inspired languages

[1] <http://www.mirah.org/>

[2] [http://www.igvita.com/2010/12/14/beyond-ruby-mirah-reia-
rite...](http://www.igvita.com/2010/12/14/beyond-ruby-mirah-reia-rite/)

------
senthilnayagam
bought it earlier today was able to get all sample apps running on the
simulator in couple of minutes, lot eadier than getting started on objective C
and xcode.

plan to spend time in weekend in getting some small project ported, will
update

------
batista
From the article:

" _Yesterday, RubyMotion was released and let’s be honest, it is the best
alternative to Objective-C out there._

Really? Not so sure. How about Mono Touch? Not only it also compiles to native
code, but it has a more mature IDE (MonoDevelop, with autocompletion), can use
Interface Builder files, and has lots of apps done with it already in the Mac
App Store. It's also able to target Android and Windows Phone, if you want.
Oh, and it's been in use for far longer so a lot of bugs have been ironed out.

~~~
eddieroger
Having developed in MT and ObjC (but not yet bit the bullet on RubyMotion), I
can concur that this statement is valid. MonoTouch was an emulation, making it
at best slow to catch up and at worst a version behind iOS. It also had a
fairly funky debug scheme, having to use IP and not the wire. Granted, you get
the REPL in lieu of a debugger with RubyMotion, but given how incredible the
REPL is, I imagine a debugger will follow. As for cross-compilation, that
wasn't so much MonoTouch as MonoCross, something that falls in to "jack of all
trades, but master of none." MonoDevelop may have autocompletion, but it was
buggy as all hell for me, and RM is positioning itself as using _any_ IDE,
where MonoDevelop locks you in as Xcode does.

~~~
damian2000
Doesn't MonoTouch use Visual Studio ... or is it something else?

~~~
batista
You can use it on Windows, IIRC, but for Mac where VS is not there, you use
the cross platform MonoDevelop IDE (+ XCode for parts).

