Live data from Hacker News

Why I loved building Basecamp for iPhone in RubyMotion

37signals.com

21–30 of 60 posts

Re: Why I loved building Basecamp for iPhone in RubyMotion

#21
post #5

Does something simular to RubyMotion, but in Python exist?

Put simply: no. RubyMotion works because Ruby and Objective-C are very similar internally, both being inspired by SmallTalk and sharing almost all "core" language features - it allows to run ruby code on Objective-C Runtime. In this regard, python is a very different language, that would be extremely difficult to port, and it wouldn't really feel like python.

Well, sort of. I wouldn't really call it running "ruby code on the Objective-C runtime". Your Ruby code is effectively being converted to Cocoa API calls during the compilation process. RubyMotion has a number of Objective-C subclasses that match back to Ruby objects (for example, strings in RubyMotion aren't NSStrings, but a subclass of them). If you dump the headers out of a RubyMotion app you can pretty clearly see this.

Ruby and Objective-C definitely aren't that similar internally - as someone else has suggested, there's no technical reason you couldn't do something similar for Python. It just happens that Ruby to Cocoa bindings have been around for a while (for some time with Apple support), and as a result there has been generally more interest in carrying it forward.

I've probably failed to adequately explain how it works, but the MacRuby source is available on GitHub, and Laurent Sansonetti has done a run through how RubyMotion does it's thing here: http://rubysource.com/laurent-sansonetti-on-rubymotion-inter...

Re: Why I loved building Basecamp for iPhone in RubyMotion

#22
post #3

Oh what a joy it is to read this! My experience with RubyMotion is very similar, and I am very happy to see major, high-profile app made with RubyMotion. However, I was somewhat disappointed to see that they use BubbleWrap persistence instead of true CoreData. I've been struggling to use CoreData without Xcode with RubyMotion for a while and haven't found a great solution yet.

What is the tradeoff between the two?

CoreData is a very powerful object store with many libraries that support it. I haven't tested BubbleWrap much, but it's a very simple system, without searching, indexing, migrations and other CoreData features.

Re: Why I loved building Basecamp for iPhone in RubyMotion

#23

At face value, I like the idea of RubyMotion, but I can't help but feel like it's a crutch to avoid picking up a few subtleties in Objective-C. The article even points out that RubyMotion doesn't hide much of the API from you, so in some ways it feels like 6 in one hand, half a dozen in the other. I'm not trying to be a naysayer, but I don't think the barrier to entry is as high as some make out to be.

RubyMotion is a huge win for me because of the super low friction toolchain. I don't ever have to load XCode and I can automate the build process however I like because it's all command-line based.

I was convinced the moment I checked out https://github.com/HipByte/RubyMotionSamples and just started typing 'rake' in each directory not ever having to setup directory paths for xcode project settings.

Re: Why I loved building Basecamp for iPhone in RubyMotion

#25
post #21
post #5

Earlier quoted context omitted.

Put simply: no. RubyMotion works because Ruby and Objective-C are very similar internally, both being inspired by SmallTalk and sharing almost all "core" language features - it allows to run ruby code on Objective-C Runtime. In this regard, python is a very different language, that would be extremely difficult to port, and it wouldn't really feel like python.

Well, sort of. I wouldn't really call it running "ruby code on the Objective-C runtime". Your Ruby code is effectively being converted to Cocoa API calls during the compilation process. RubyMotion has a number of Objective-C subclasses that match back to Ruby objects (for example, strings in RubyMotion aren't NSStrings, but a subclass of them). If you dump the headers out of a RubyMotion app you can pretty clearly se…

Thanks! I knew most of this, but for some reason had an impression that ruby was in particularly nice spot to subclass Obj-C classes. I have to agree, you are right, and other languages could follow RubyMotion's model.

Re: Why I loved building Basecamp for iPhone in RubyMotion

#27

At face value, I like the idea of RubyMotion, but I can't help but feel like it's a crutch to avoid picking up a few subtleties in Objective-C. The article even points out that RubyMotion doesn't hide much of the API from you, so in some ways it feels like 6 in one hand, half a dozen in the other. I'm not trying to be a naysayer, but I don't think the barrier to entry is as high as some make out to be.

RubyMotion is a huge win for me because of the super low friction toolchain. I don't ever have to load XCode and I can automate the build process however I like because it's all command-line based. I was convinced the moment I checked out https://github.com/HipByte/RubyMotionSamples and just started typing 'rake' in each directory not ever having to setup directory paths for xcode project settings.

XCode is all command-line based too.

https://developer.apple.com/library/mac/#documentation/Darwi...

Re: Why I loved building Basecamp for iPhone in RubyMotion

#28
post #18

The major concern I have with something like RubyMotion is that Objective-C - the language it stands in for - is not a difficult language. The Cocoa/CocoaTouch API and its verbosity is the real problem, and I think that trying to map the extensive documentation written in Objective-C to a Ruby equivalent runs the risk of adding too much mental overhead. That it requires a paid-for license means that Ruby specific doc…

It hasn't been that hard for me to translate Objective-C code into Ruby. The hardest thing has been APIs that have varargs that end in nil for some reason. Recently the RubyMotion team published this yardoc that translates all of the existing APIs for you into Ruby: http://www.rubymotion.com/developer-center/api/index.html But I didn't refer to that for the majority of the development since it wasn't around yet...I w…

I think that's an issue of moving from Objective-C (and pure C), to what is normally a dynamic language.

Using nil as a final argument (also called the 'sentinel') is fine for C to mark the end of a variable length array like it expects with 'strings' (so it doesn't stretch into the next unrelated block of memory), but you'd expect Ruby to handle that for you. Because in any other circumstance, it does.

Re: Why I loved building Basecamp for iPhone in RubyMotion

#29
post #17

At face value, I like the idea of RubyMotion, but I can't help but feel like it's a crutch to avoid picking up a few subtleties in Objective-C. The article even points out that RubyMotion doesn't hide much of the API from you, so in some ways it feels like 6 in one hand, half a dozen in the other. I'm not trying to be a naysayer, but I don't think the barrier to entry is as high as some make out to be.

Call it my crutch, but I got an app shipped without having to worry about a lot of the baggage that comes with Objective-C as a language. Here's two of my favorite examples of things I didn't have to worry about: http://nshipster.com/nil/ (wat) http://ashfurrow.com/blog/seven-deadly-sins-of-modern-object... (6/7 of these don't apply...testing is something I need to work on though!)

You're definitely right — nil / NSNull is confusing to newbies, but Ruby is just as bad. The way it handles UTF8 is somewhat backwards, and the fact that symbols and strings are different (but sometimes used interchangeably) can cause 'gotchas' for newbies too. I'd argue that your language of choice is really dependent on which set of baggage you've internalized :-)

Re: Why I loved building Basecamp for iPhone in RubyMotion

#30

I liked the post and the general message, but the 'Avoid Xcode' part is rubbish. You shouldn't make such assumptions when you don't fully know how to use a tool, specially when you have such large audience.

I agree with this point. A lot of RubyMotion fans seem to be trying to build an app for iOS while learning as little as possible. While that's great if you're on a tight deadline and want to play to your strengths, Xcode is an incredibly powerful tool and features like the static analyzer, visual debugger and core data visualizer shouldn't be thrown out because some command line utility will let you Build & Run.
Post reply on HN