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

RubyMotion - Ruby for iOS

rubymotion.com

Post reply on HN
Print view View original

111–120 of 250 posts

Re: RubyMotion - Ruby for iOS

#111

Post by grey-area »

octopus wrote: post #57

A suggestion for Laurent Sansonetti will be to release this similarly with the way Xamarin has released Mono for iOS. Basically you should be able to download and use the library for free in the iPhone/iPad simulator and you will need to buy a license if you want to be able to export the app to the actual device. This licensing model has the advantage that is similar with what Apple does for developing apps for iOS.…

I'd second this suggestion. I love the idea of using ruby on ios, this looks like a womderful solution, and it looks far more rubyish in syntax than Mobiruby (which isn't there yet anyway), but I would really like to try it out for myself in the simulator and develop a few simple apps before deciding whether I would want to use it professionally. If they could limit it to simulator only for free it would be much easier to tell if it is going to be really useful or more painful than just putting up with obj c. Having a demo might even boost adoption.

A question for the developers - did you consider this option and reject it for some reason?

Re: RubyMotion - Ruby for iOS

#112

Post by aiscott »

robomartin wrote: post #109

I am not criticizing. This is a perfectly neutral question: Isn't the issue with a lot of these "look Ma, no Objective-C" approaches in that there are always little nagging issues here and there? I mean, Apple is constantly moving Objective-C/Xcode/iOS (notice I didn't say "forward"). Isn't it somewhat dangerous to adopt peripheral approaches for development rather than staying (suffering?) with the Apple-provided to…

I said this in another reply, but I'll reiterate here. It's not the lack of Objective-C that is the big deal here. Afterall you are still interfacing with cocoa, and are stuck with a lot of the verbosity in doing that.

The real key to this is the REPL and interactivity between coding and the running app. Being able to edit bits of functionality and structure in the running app, and immediately see the results is AWESOME!

Re: RubyMotion - Ruby for iOS

#114

Post by drpancake »

From the screencast it looks like they altered Ruby syntax by adding named parameters to conform with Obj-C's way of specifying prototypes. I guess this is a trade-off for the fact that Obj-C has some unusual syntax that has no real analog in Ruby -- if you've ever tried developing with PyObjC you'll be familiar with how odd it looks.

Re: RubyMotion - Ruby for iOS

#116

Post by robomartin »

aiscott wrote: post #112
robomartin wrote: post #109

I am not criticizing. This is a perfectly neutral question: Isn't the issue with a lot of these "look Ma, no Objective-C" approaches in that there are always little nagging issues here and there? I mean, Apple is constantly moving Objective-C/Xcode/iOS (notice I didn't say "forward"). Isn't it somewhat dangerous to adopt peripheral approaches for development rather than staying (suffering?) with the Apple-provided to…

I said this in another reply, but I'll reiterate here. It's not the lack of Objective-C that is the big deal here. Afterall you are still interfacing with cocoa, and are stuck with a lot of the verbosity in doing that. The real key to this is the REPL and interactivity between coding and the running app. Being able to edit bits of functionality and structure in the running app, and immediately see the results is AWES…

I don't know Ruby. Therefore, by my own admission, this comes out of complete ignorance.

I am currently working on a project that uses a genetic solver and some fairly complex state machines driven by fairly involved databases. I can't possibly see how something like this could be made to be interactive in terms of the development process. Generally speaking you are writing a lot of code before you get to compile and see the results. And, personally, I don't have any issues with the compilation process.

What do you mean by "interactive"?

Re: RubyMotion - Ruby for iOS

#117

Post by chc »

coffee wrote: post #103
chc wrote: post #89

Earlier quoted context omitted.

Compared to learning Cocoa (Touch), Objective-C is really nothing — especially since to use MacRuby you have to learn a bunch of kinda-awkward hacks they've stuck on top of Ruby to make it compatible with Objective-C (e.g. the "def foo(bar, baz:quux)" syntax and Pointers). It's a very simple language. Unless you are exceptionally bad at learning syntax, you're really not saving yourself a whole lot of time.

You've completely missed my point. Feel free to re-read what I wrote. Just for reference, yes I code in both Objective-C AND Ruby. There are significant speed gains when using the tools/language you're most familiar with. I've seen this first hand with myself, and in others... It's not about "how easy it is to learn" it's about "how much time it takes." You're mixing together two entirely different topics.

I was specifically addressing this point (which seemed to be the crux of your comment):

> Remove the concept of learning a new language, a new IDE, and only require that I learn a new lib to work against and I'm FAR quicker.

That's a bit like saying, "Remove the concept of putting on running shoes and warming up and only require that I run a marathon and I'm FAR quicker." The time to tie your shoes is nothing compared to running the marathon. Likewise, the trouble of learning Objective-C (especially with a background in Ruby) is insignificant compared to the time it takes to learn Cocoa.

Re: RubyMotion - Ruby for iOS

#118

Post by chc »

Argorak wrote: post #102
chc wrote: post #89

Earlier quoted context omitted.

Compared to learning Cocoa (Touch), Objective-C is really nothing — especially since to use MacRuby you have to learn a bunch of kinda-awkward hacks they've stuck on top of Ruby to make it compatible with Objective-C (e.g. the "def foo(bar, baz:quux)" syntax and Pointers). It's a very simple language. Unless you are exceptionally bad at learning syntax, you're really not saving yourself a whole lot of time.

def foo(bar, baz: "something") is perfectly valid ruby(1.9).

Really? What on earth does it mean? The "baz: something" ought to parse as a hash literal, which isn't legal in a method declaration.
Post reply on HN