Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I loved building Basecamp for iPhone in RubyMotion

37signals.com

Post reply on HN
Print view View original

11–20 of 60 posts

Re: Why I loved building Basecamp for iPhone in RubyMotion

#11

Post by stcredzero »

> Respect the Style

RubyMotion is Ruby, which is normally succinct, short, and sweet. The iOS APIs stick out like sore thumbs amongst what is normal Ruby code: camelCase usage is pervasive and reallyFreakingLongParameterNames can’t be tuned out.

When I first read the above paragraph, I was afraid this was going to be a case of someone using a great tool to enable willful ignorance, but:

> So far, I’ve ended up with staying in Objective-C style. All of the API calls you make into the various iOS frameworks need to be in that style, and seeing the different opinions of variable and method naming clashing ended up hurting my head.

I commend the author for being perceptive and pragmatic. There is also a reason why things are the way they are in iOS and Cocoa. Long Intention Revealing names document what's going on, and reduce the incidence of unwanted name collisions. It has a heritage from Smalltalk, so it's been around and developing for something like 40 years! That puts it in the same league as Lisp as a way of doing things with merit that stands the test of time.

Re: Why I loved building Basecamp for iPhone in RubyMotion

#12

Post by jbigelow76 »

flixic wrote: post #5
anderspetersson wrote: post #2

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.

I don't think RubyMotion exists because like Obj-C it was inspired by SmallTalk. Well maybe it is, but that doesn't mean it's an insurmountable barrier that would render a similar project in python impossible or "un-python like". C#/.NET got the treatment a long time ago, http://xamarin.com/. It's just that (it appears) no company or OS developer has taken on the challenge of creating the tooling for python.

Re: Why I loved building Basecamp for iPhone in RubyMotion

#14

Post by cozykozy »

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.

Re: Why I loved building Basecamp for iPhone in RubyMotion

#15

Post by FuzzyDunlop »

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 documentation will be comparatively thin on the ground, and the same applies to the resources found on StackOverflow.

I'm a Ruby developer, and I find Obj-C a nice language to work with (though I do prefer the s-expression style in favour of the more recent dot notation). I still haven't managed to justify using Ruby in place of Objective-C.

The only major benefit I see is the REPL that ties into the simulator, and losing the dependency on X-Code, but again, I feel that the verbosity of the APIs is the fault for that.

Re: Why I loved building Basecamp for iPhone in RubyMotion

#16

Post by flixic »

cozykozy wrote: post #14

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.

The bigger reason to use RubyMotion is not a different syntax - you do end up using very similar code anyway, although lack of header files is a nice thing - but different tools. Objective-C is not the barrier. Xcode is.

Re: Why I loved building Basecamp for iPhone in RubyMotion

#17

Post by qrush »

cozykozy wrote: post #14

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!)

Re: Why I loved building Basecamp for iPhone in RubyMotion

#18

Post by qrush »

FuzzyDunlop wrote: post #15

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 was knee-deep in the Apple docs for most of it.

Re: Why I loved building Basecamp for iPhone in RubyMotion

#19

Post by michaelbuckbee »

flixic wrote: 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?

Re: Why I loved building Basecamp for iPhone in RubyMotion

#20

Post by cozykozy »

flixic wrote: post #16
cozykozy wrote: post #14

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.

The bigger reason to use RubyMotion is not a different syntax - you do end up using very similar code anyway, although lack of header files is a nice thing - but different tools. Objective-C is not the barrier. Xcode is.

No argument here, XCode sucks. RubyMotion seems like a heavy-handed answer to that, though.
Post reply on HN