On Why I Am Not Buying RubyMotion
upbeat.it
I like Ruby and the way it is easy to work with. I personally use ruby in many projects, mostly on the server side. I am not a lover of Xcode. Yet, RubyMotion is not for me.
upbeat.it
It's the frameworks that are hard, and you have to learn those using RubyMotion anyway.
And not only that, but you have to rely on objc framework documentation and do the translation to Ruby in your head. Too many wasted cycles, imho.
On the flip side, I like seeing experimental tools like this to promote new ways of thinking and coding and it will inevitably foster new features into the official SDK (ala blocks).
And of course, while Objective-C is easy to learn it's not necessarily a fun language to express yourself in, much the way M4, ColdFusion or MUMPS aren't usually considered fun languages to use (no offense meant to Objective-C's designers or people who like it, just drawing on the languages least likely to have any fan out there).
> On the flip side, I like seeing experimental tools like this to promote new ways of thinking and coding
Ruby isn't exactly a "new way of thinking and coding" now is it?
I'm not part of either the ObjC or Ruby communities, but the impression I get as an outsider is that Ruby is a language and coding culture obsessed with elegant and minimalist expression, and ObjC doesn't make those things priorities. So what I'm hoping to see come out of RubyMotion is an obsessive drive to wrap the iOS frameworks in libraries that let you do the common things with no code at all, and the uncommon things with the least code possible. For people who have only worked in lower-level languages ... well, the difference over time could be surprising. At least I'm hoping so.
To put it in practical terms: I bet if you follow the sample RubyMotion apps over the next six months, you'll see the number of lines of code required to do what they do plummet, replaced by high-level libraries. If I'm right, let's get back together then and high-five. If not, oh well, it was a fun experiment.
Forget the rest of the article, this sums up why it's not for you.
This is a problem with current HTML5 -> Native frameworks as well, you have to know what's under the hood so that you can make efficient designs.
Would I recommend it to a company that only does iOS development? heck no. How about a RoR company that wants to do some iOS development? Now we're talking. If nothing else, I think it is a great way to learn the Touch/Cocoa/Foundation frameworks without having Obj-C cruft get in the way of having a good time.
You can!
Every time it comes up, I'm going to repeat this suggestion: Use Nu[1] as a REPL for iOS[2] and OS X[3].
[2] http://groups.google.com/group/programming-nu/browse_thread/...
[3] https://github.com/timburks/nu/blob/master/nu/console.nu
Nu builds as a static library. You need to include it in your project and link it into your binary to make it available. Then you'll need to instantiate a NuRemoteHost object after your application has launched.
Once it's running you can launch a Nu interpreter and execute NuRemoteClient to connect to the host you created earlier.
Even though it's a Lisp dialect, Nu was designed from the beginning to be interoperable with Objective-C, so translating between them is easy. (Convert brackets to parentheses and you're 80% of the way there.)
As a contrived example, this:
if(![self.address startsWith:@"https://"])
self.address = [@"https://" stringByAppendingString:self.address]
(if (not (@address startsWith:"https://"))
(set @address ("https://" stringByAppendingString:@address)))The big difference is heritage: F-Script is Smalltalk and Nu is Lisp.
The reason you should be excited about RubyMotion is that it's just easier to read that ObjC since it has a lot less noise, and lot of goodies you just "get" from Ruby's core. And the debugger is fantastic!
By now there is a very active Google Group.Wrote a question yesterday and had an answer within 10 Minutes. Very friendly vibe, mostly Rubyists dabbling into Xcode, but also some very nitty gritty in depth topics.
Also the BubbleWrap repo (https://github.com/mattetti/BubbleWrap) is chugging along nicely, cool for a young project... So, yes: you can get help.
Specifically, run:
$ sudo motion update
My take on this is the following: using RubyMotion, overhead will be tremedous - while debugging, you will need to make sure and double check that it's you who screwed things up and not RubyMotion's author(s). This alone is a major downside of the whole thing.
And second, maybe this is a dumb question, but is there any possibility that Apple blocks apps submitted using third party tools like this?
http://www.fastchicken.co.nz/2012/05/11/so-many-straw-men-so...
You have a good point, but mostly, I think it's a strawman argument.
Just make up your own mind. I'm thinking about just learning Objective C just because I would definitely use those nice existing libraries.
New iOS SDK release support is a valid concern, but I don't think library usage is a big problem.
I find both dependencies are well worth it.
Really why? I don't even update my original XCode straight from Apple that often.
When you sell to customers (for profit), you want to target previous versions of the iOS, not the latest, and surely not within a week.
I was mostly talking about one's own work.
> Using a third party tool is like gambling: you might win or loose
"Loose"? AAAAAGH