On Why I Am Not Buying RubyMotion(upbeat.it)
upbeat.it
On Why I Am Not Buying RubyMotion
http://www.upbeat.it/2012/05/08/on-why-i-am-not-buying-rubymotion/
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.
56 comments
Objective-C isn't the hard part about iOS programming, it's fairly simple and can be learned in a day by a programmer.
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).
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).
I think the potential of something like RubyMotion is that it facilitates very high-level abstraction so that building application with very common themes - like an app showing only a list/detail view - could be done in less than 10 lines of code. Think jQuery vs manual DOM manipulation instead of CoffeeScript vs JavaScript. These days I don't really know how to manually manipulate DOM or read document on getElementById. Similar, you could imagine a new group of iOS programmers not reading official Cocoa documentation and instead rely on a higher level abstraction totally built on top of RubyMotion. For that to happen, RubyMotion needs to grow its own ecosystem instead of relying on people from Objective-C wanting to save some keystrokes.
Xcode is also a hard part, for it is a pretty crummy IDE.
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?
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 think the potential of RubyMotion is in the "new ways of thinking and coding" aspect you mention -- the big potential win here is to import a Rubyish way of thinking about iOS programming.
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.
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.
Like I said in the post, totally open to change my mind.
> Whenever I see a third party tool I ask myself: how quickly it will be updated to the last SDK version? ... What will I tell to the client? “Oh look, we have to wait one week for technical reasons”. For every project I have taken on I have never had the guts to run such a risk.
Forget the rest of the article, this sums up why it's not for you.
Forget the rest of the article, this sums up why it's not for you.
I was also sold on that "If you stumble on an issue and you don’t know what’s under the hood it is likely you’ll need much more time (possibly all the time you have saved in advance by using the tool) to find out a way to fix it or a workaround."
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.
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.
I'm curious about this ... how much more is "under the hood" of a RubyMotion app than an ObjC app? In the HTML5 -> Native tools you're dealing with an extra abstraction, Javascript running on top of an interpreter that talks to native APIs, which becomes a problem if you need to use the native APIs in a way the interpreter designers didn't think of. But RubyMotion isn't a layer on top of native code, it is native code -- it's a Ruby->machine code compiler. So is there any more standing between you and the hardware than there is if you use XCode? Maybe I'm totally misunderstanding the architecture ...
Like I have said it is just a "language layer" around Cocoa API, there are no extra, built-on-top classes/things. Instead of writing Obj-c you write Ruby, but the behavior is the same.
Just wondering if you, unlike me, had the guts and ran the risk. I am curious if you had such an experience. Can you share it?
Who is the "you" you're referring to? Me? I hope not, I'm really enjoying RubyMotion.
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.
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.
I don't know who you are, so I assume I'm not. I was referring to the writer as I'd just quoted.
> ps2: How cool would it be to have a REPL console like the one in RubyMotion on the Xcode console?
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].
[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
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].
[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
Okay this sounds really cool, but I am a little confused as to how to implement it. How do I use the console to interact with my app in the simulator?
> How do I use the console to interact with my app in the simulator?
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.
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.
but then you type nu code in the prompt, not obj-c, right?
Yes, you'll be typing Nu code in a Nu interpreter.
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:
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)))thanks for the link. I'll try it out.
Sounds interesting... I was just looking into F-script (http://www.fscript.org/), is this similar?
Aye, pretty similar. F-Script has some features that Nu does not (like the object explorer), while Nu is the only one that works on iOS.
The big difference is heritage: F-Script is Smalltalk and Nu is Lisp.
The big difference is heritage: F-Script is Smalltalk and Nu is Lisp.
[deleted]
The funny thing is; That's not listing any of the major issues I have with RubyMotion. One of them would be that I bought the software and I can't integrate one external library I need, but, one of the greatest thing about RubyMotion is that it has been getting updated every day. So I bet you they'll update it with any new version of the SDK before it gets released.
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!
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!
What about user support ? Can you write and get an answer from the author in a reasonable amount of time ?
Yes, you can get support just by typing motion support, they have a Google group too, if you need a quicker response from the community.
got a problem with the installer and received a fix from the author in 4 min. thumbs up
When I bought ruby motion I was a bit in provisioning_profile hell. I shot off a support Ticket and got an answer within 4 minutes from Laurent Sansonetti. When I told him in a second Mail that I'm not too chummy yet with Xcode he came up with some really useful links half an hour later.
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.
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.
> RubyMotion is that it has been getting updated every day
Specifically, run:
$ sudo motion update
Specifically, run:
$ sudo motion update
Great write up, although not all the points are strictly speaking valid (epecially the one regarding future ios versions; since all the pre-release iOS firmwares are available for developers, there are chances RubyMotion will be updated in a timely fashion).
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.
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.
Although updates to the last SDK version in a timely manner is a valid concern, but does one really rebuild his application with a new major iOS version after a week of the release?
You might want to if there's a killer new API feature available, or if there's a new iOS device with a different resolution that requires a rebuild to support.
And the new sdk versions usually coincide with the release of a new device.
It's often been necessary -- most recently, iPad apps needed to be built against a new version of the SDK to correctly use 2x graphics on the new iPad's high-res screen.
For the major iOS versions, many developers will have an update ready on release day. People will download apps just to play with new features. Keeping current with the SDK is absolutely a business advantage.
I'm hoping they bring out a trial version... Ruby is not my main language, and while I'd like to give this a try, I'm not $149 keen on seeing if it is something I'd use.
This looks very promising, but are there any examples of real applications written with RubyMotion and submitted to the AppStore? Everything I see is just stand-alone examples, but can all the pieces be glued together and turn into a functional app?
And second, maybe this is a dumb question, but is there any possibility that Apple blocks apps submitted using third party tools like this?
And second, maybe this is a dumb question, but is there any possibility that Apple blocks apps submitted using third party tools like this?
Apple shouldn't block them. Eg iPhone Wax, a Lua environment, is fine for submissions.
Apple doesn't care how you write your apps (well, they'd probably prefer you used their tools), and they've come out and publicly stated they have no problem with things like RubyMotion, Corona, Adobe Air to ObjC conversion, etc.
There are apps written in MacRuby (RubyMotion's desktop sibling) in the Mac App Store, and there are apps written in other alternative languages in the iOS App Store, so it's hard to see what the problem would be. The RubyMotion FAQ agrees with this assessment.
I've got a little rebuttal to this here:
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.
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.
[deleted]
It's the whole discussion of CoffeeScript vs pure JavaScript imo. Except that RubyMotion doesn't play nice with existing libraries. Or does it?
Just make up your own mind. I'm thinking about just learning Objective C just because I would definitely use those nice existing libraries.
Just make up your own mind. I'm thinking about just learning Objective C just because I would definitely use those nice existing libraries.
RubyMotion should be able to invoke any existing Obj-C library. It already has documented support for CocoaPods.
New iOS SDK release support is a valid concern, but I don't think library usage is a big problem.
New iOS SDK release support is a valid concern, but I don't think library usage is a big problem.
OP makes good arguments, but they seem out of place considering he's already dependent on the Apple approval process.
What IOS developer isn't dependent on the Apple approval process?
Kind of my point. OP's dependency arguments boil down to a matter of comfort. Discomfort with depending RubyMotion seems at odds with discomfort with depending on maintaining good favor with Apple.
I find both dependencies are well worth it.
I find both dependencies are well worth it.
Change. It scares people.
>Whenever I see a third party tool I ask myself: how quickly it will be updated to the last SDK version? Say Apple releases a iOS6 today. Will an aligned version of the tool be ready today? If not, when? One day would be fine, one week would not.
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.
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 had this issue with an iCloud-based app. A client wanted it to be ready on the iOS5 release. I agree, it's living on the edge, but sometimes it is required to have access to beta stuff and work on that. Not every third party tool allow that.
Well, if you're doing client work maybe it makes sense.
I was mostly talking about one's own work.
I was mostly talking about one's own work.
Light gray text on dark gray background! Great choice.
> Using a third party tool is like gambling: you might win or loose
"Loose"? AAAAAGH
> Using a third party tool is like gambling: you might win or loose
"Loose"? AAAAAGH
neither statements make for a useful conversation. please avoid them in the future.
To be fair, the "light grey text on a grey background" criticism is valid. Your blog should be readable in most browsers and on most monitors. This blog fails that test. I've looked at it on both Windows and Linux and on a couple of different monitors. It's hard to read in all cases. I shouldn't have to fire up Readability to read a blog post.
It's a valid criticism, but it's not interesting or on-topic for the conversation here. Cesare has an email address and a Twitter — those would be better media for a comment like this.
Yes, we should definitely encourage people to present their writing with unreadable formatting and notorious grammatical errors.
asking a person to act civil is a far easier task than making the internet on the whole be aware of concerned with contrast, especially when done in a complaint - on a completely separate site - in a frankly childish tone.
Can you please send me a screenshot of what you see? I ran many test on readability and I did not verify the issue you mention.