RubyMotion pros and cons(merbist.com)
merbist.com
RubyMotion pros and cons
http://merbist.com/2012/05/04/macruby-on-ios-rubymotion-review/
22 comments
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)
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)
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.
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.
> Maybe someone should take Squeak/Pharo Smalltalk and create a utility that can be used as a REPL working with the iOS simulator.
I'm gonna keep pimping it here on HN: Use Nu[1] as a REPL for iOS[2] and OS X[3]. I do all the time.
[1] http://programming.nu
[2] http://groups.google.com/group/programming-nu/browse_thread/...
[3] https://github.com/timburks/nu/blob/master/nu/console.nu
I'm gonna keep pimping it here on HN: Use Nu[1] as a REPL for iOS[2] and OS X[3]. I do all the time.
[1] http://programming.nu
[2] http://groups.google.com/group/programming-nu/browse_thread/...
[3] https://github.com/timburks/nu/blob/master/nu/console.nu
Sounds a lot like what FScript does for mac: http://www.fscript.org/
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...
Would love to check it out. Any way to get notified when you do?
Oh, Smalltalk is more different than that. Most Smalltalk applications are deeply integrated with their development environment, so that for example you can't store your code in files and easily connect them with bits of code in another language, and you can't statically compile your programs. Essentially, your programs would have to become image-based, which is a much bigger hurdle than just another language.
I'd guess "the image thing" is probably the reason Smalltalk hasn't taken off more than it has.
I'd guess "the image thing" is probably the reason Smalltalk hasn't taken off more than it has.
> Most Smalltalk applications are deeply integrated with their development environment
I used to work for a vendor, and I've written a significant fraction of such an environment.
> so that for example you can't store your code in files and easily connect them with bits of code in another language
Which is why I know this to be patently false. You can actually add compiler objects and have select methods written in SQL or whatever language you like.
> Essentially, your programs would have to become image-based
Again, patently false for the REPL use case. Also there are a number of declarative Smalltalks already, which don't need to be started from an image file. Also, Smalltalk MT used to compile down to a DLL indistinguishable from any C++ DLL.
I used to work for a vendor, and I've written a significant fraction of such an environment.
> so that for example you can't store your code in files and easily connect them with bits of code in another language
Which is why I know this to be patently false. You can actually add compiler objects and have select methods written in SQL or whatever language you like.
> Essentially, your programs would have to become image-based
Again, patently false for the REPL use case. Also there are a number of declarative Smalltalks already, which don't need to be started from an image file. Also, Smalltalk MT used to compile down to a DLL indistinguishable from any C++ DLL.
Ah, this is a little bit embarrassing. I had somehow read your comment as meaning that somebody should make something like RubyMotion but with Smalltalk, with the REPL being a neat incentive. Rereading, I see that was totally in my head. Sorry. No idea what I was thinking, but it's too late to delete it now. I suppose my brain just saw "Smalltalk" and "iOS" in the same sentence and got worked up.
But incidentally, do you happen to know offhand of any resources about adding new compilers like you were talking about? That sounds pretty neat. I unfortunately missed the golden age of Smalltalk, so most of what I know comes from playing around with Squeak and GNU Smalltalk and reading about older implementations.
But incidentally, do you happen to know offhand of any resources about adding new compilers like you were talking about? That sounds pretty neat. I unfortunately missed the golden age of Smalltalk, so most of what I know comes from playing around with Squeak and GNU Smalltalk and reading about older implementations.
But incidentally, do you happen to know offhand of any resources about adding new compilers like you were talking about? That sounds pretty neat.
The examples for the T-Gen compiler compiler in VisualWorks Smalltalk talked a little about this, and had a toy SQL example. IIRC, there was a <pragma: > you could put in a method to use your own Compiler object. Also, Smalltalk/X actually let you implement methods in C right in the Smalltalk class browser.
Unfortunately, a lot of documentation and other info are lost in the mists of time.
The examples for the T-Gen compiler compiler in VisualWorks Smalltalk talked a little about this, and had a toy SQL example. IIRC, there was a <pragma: > you could put in a method to use your own Compiler object. Also, Smalltalk/X actually let you implement methods in C right in the Smalltalk class browser.
Unfortunately, a lot of documentation and other info are lost in the mists of time.
I agree that this is a really cool feature and I expect to see other ObjC alternative solutions copying the approach.
F-Script (see chrisdevereux's comment) has been around since the very early days and allow itself to be included in the program to begin with or injected later. You can do a lot of experimentation with it.
Optionally typed Ruby would be interesting indeed.
Kind of wondering how that would work in practice though...
Kind of wondering how that would work in practice though...
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...
[1] http://www.mirah.org/
[2] http://www.igvita.com/2010/12/14/beyond-ruby-mirah-reia-rite...
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
plan to spend time in weekend in getting some small project ported, will update
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.
"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.
This is a fair criticism, MonoTouch, Corona and other solutions have their place and are great solutions too. I reworded my article to avoid this unnecessary bias.
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.
How long has it been since you used MonoTouch? I first used it a little over a year ago: debugging over the wire worked just fine (though you can debug over a network connection), the API was only ever behind on major iOS updates (it's also not hard to call an Obj-C API from MT yourself, without waiting for them to put out a new release of MT), and all the compilation was handled by command line programs called by the MT MonoDevelop plugin - you could call them from make/Rake/whatever, should you prefer to.
Doesn't MonoTouch use Visual Studio ... or is it something else?
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).
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!