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

161–170 of 250 posts

Re: RubyMotion - Ruby for iOS

#161

Post by FuzzyDunlop »

octopus wrote: post #9
tobiasbischoff wrote: post #5

nice, but where is the advantage over just using objc? the hard part of coding for iOS isn't objc, it's learning how to use all the API's.

It depends, if your background is in dynamic languages like Perl, Ruby, Python than using Ruby for iOS makes a lot of sense. On the plus side Ruby is better for programmer productivity. If you have a good background in C than yes, using Objective-C is not so difficult.

I concur with the other posters who say Objective-C itself is not the barrier, the API is. Such is the design and verbosity of the API (which is great for self-documentation and talking about, less so for typing), it'd be an absolute nightmare to work with without the extensive auto-complete Xcode offers.

This is a very exciting (and very positive) development, but at this moment in time I would still bite the bullet with Objective-C. I came to it with a background in PHP of all things and didn't struggle with picking it up in a few weeks.

I can't wait to see the things people do with it and with Ruby's metaprogramming.

Re: RubyMotion - Ruby for iOS

#163

Post by jbrechtel »

spacemanaki wrote: post #87
sjtgraham wrote: post #32

I don't see the point of this. Objective-C is not hard to learn, and with ARC, blocks, the new literals for NSArray and NSDictionary, etc, Objective-C has actually become pleasant to write IMO. The example RubyMotion code also doesn't look very nice either. The problem with Rubyists (being one for the past 6 years I feel qualified to say this) is in general they want to use Ruby for everything. It's not always the be…

Forgive my ignorance of iOS, but do the current Objective-C based tools deliver "An interactive shell [...] for introspection, live coding and debugging" ? If RubyMotion can actually deliver a real first-class REPL that works, that would be a pretty huge deal. Lack of a REPL is the biggest reason why I dislike mobile (Android) development.

What are you looking for with an Android REPL? Asking because this is something I might be interested in building. Feel free to take the conversation to email (@gmail) or twitter (@jbrechtel) if you'd rather limit the off-topic discussion.

Re: RubyMotion - Ruby for iOS

#164

Post by sassafras »

tolmasky wrote: post #70
sjtgraham wrote: post #32

I don't see the point of this. Objective-C is not hard to learn, and with ARC, blocks, the new literals for NSArray and NSDictionary, etc, Objective-C has actually become pleasant to write IMO. The example RubyMotion code also doesn't look very nice either. The problem with Rubyists (being one for the past 6 years I feel qualified to say this) is in general they want to use Ruby for everything. It's not always the be…

I've never understood this logic: The existence of this project is not an attack on Objective-C. Objective-C is not hard to learn and awesome, I agree. But what does that have to do with providing an alternative? There can exist multiple good solutions to one problem. You said it yourself: Ruby is not always the best tool for the job, perhaps Objective-C is also not always the best tool for the job. Perhaps the use o…

I can't speak for the parent, but my take on it is that Ruby is considerably slower than Objective-C and one of the slower scripting languages in common use, IIRC. I wouldn't go out on a limb and suggest that it's unsuitable for iOS development without having a chance to see it myself, but it's something to keep in mind.

As I'm sure you've seen, even Objective-C is too slow for many things when developing for iOS - for instance, if you want to get halfway decent UITableView performance it's best to write a custom UIView where instead of laying out nested subviews, you drop into C and do all your layout in drawRect using only CoreGraphics API calls.

If you're attempting to do anything more complicated than hooking together pre-fab components, your performance is probably going to suck if your views are written in Ruby. And it's the silky smooth graphics people have come to expect that give iOS the reputation it's earned for slick UI.

It doesn't mean you shouldn't necessarily use a framework like this, but you don't get all that convenience for free. I've often felt that the reason Objective-C remains in use (aside from the fact that it's kept alive by Apple) is that it sits in a really practical middle ground between the bare metal performance of C and the convenience (and tradeoffs) of "nicer" languages. As I said above, though, this is just my default reaction, and I'd love to see this stuff in action if it's truly usable for a reasonable subset of use cases.

Re: RubyMotion - Ruby for iOS

#165

Post by [deleted] »

malyk wrote: post #105
conradev wrote: post #99

Earlier quoted context omitted.

> UIView already provides a similar method built into the API. Yeah, it's actually much, much simpler to do it in Objective-C in this case. [UIView animateWithDuration:0.5f animations:^{ // Do something }];

Its UIView.animateWithDuration(0.5, animations:lambda { //do something }) in RubyMotion. Basically the same.

[deleted]

Re: RubyMotion - Ruby for iOS

#167

Post by eaurouge »

chc wrote: post #89
coffee wrote: post #83

Earlier quoted context omitted.

Speed is what you're missing. Not to denigrate you or your statement, and yes Objective-C is not that hard to learn, but it comes down to speed. If I've never programmed in Objective-C and if I'm experienced in Ruby my time from concept to live iPhone app can be FAR quicker by using the tools/language I'm already familiar with (regardless of which tools/language). Remove the concept of learning a new language, a new…

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're missing something here. I understand Objective-C, I can write Objective-C code. But it doesn't come as naturally to me as Ruby does, there are certain nuances that I stil don't understand intuitively. Ruby is the complete opposite, coding it is almost instinctive for me.

RubyMotion doesn't just slap on a Ruby syntax, its objects inherit from both Ruby and Objective-C classes with some mixed in Ruby modules.

The RubyMotion development environment is, in my opinion, an improvement over XCode. And of course, there's the REPL.

The "awkward hack" you mentioned is nothing. I don't particularly like the way he's implemented pointers to pointers, but that's also minor. The benefits, for me, easily outweigh the negatives.

Re: RubyMotion - Ruby for iOS

#168

Post by cageface »

jeremymcanally wrote: post #157
cageface wrote: post #156

Earlier quoted context omitted.

But you're going to be coding to those same Apis in ruby too, just with a lightly different syntax.

No, actually. I can use Ruby's nice facilities for external processes (e.g., "x = `ls`" to get a directory listing or "system('do_something')") or simple regular expressions (i.e., "'string' =~ /my_regex/" and friends vs. NSRegularExpression's verbose syntax). I'm not forced to use Cocoa's verbose API if it has a nice Ruby wrapper (and if it doesn't have one, I can make one).

This:

https://github.com/HipByte/RubyMotionSamples/blob/master/Ges...

Is what 95% of the code in your app is going to look like and I don't really see what it's buying you. You're also throwing away all the type checking you'd get on essentially the same code in Obj-C.

I really like Ruby but I don't intend to use it for iOS apps.

Re: RubyMotion - Ruby for iOS

#169

Post by Me1000 »

sassafras wrote: post #164
tolmasky wrote: post #70

Earlier quoted context omitted.

I've never understood this logic: The existence of this project is not an attack on Objective-C. Objective-C is not hard to learn and awesome, I agree. But what does that have to do with providing an alternative? There can exist multiple good solutions to one problem. You said it yourself: Ruby is not always the best tool for the job, perhaps Objective-C is also not always the best tool for the job. Perhaps the use o…

I can't speak for the parent, but my take on it is that Ruby is considerably slower than Objective-C and one of the slower scripting languages in common use, IIRC. I wouldn't go out on a limb and suggest that it's unsuitable for iOS development without having a chance to see it myself, but it's something to keep in mind. As I'm sure you've seen, even Objective-C is too slow for many things when developing for iOS - f…

I can only assume you didn't read up on the technology at all. RubyMotion does not use a Ruby VM, instead it's a static compilation to machine code. So any previous Ruby performance benchmarks are invalid in this instance.

Also, Objective-C is not the slow bit in the example you described. There is a lot of logic overhead in laying out views in Cocoa. While it's true Objective-C (the language) may have some overhead, it's not much. And it's certainly not anything compared to laying out a complex view tree.

Re: RubyMotion - Ruby for iOS

#170

Post by [deleted] »

nupark2 wrote: post #77
tolmasky wrote: post #70

Earlier quoted context omitted.

I've never understood this logic: The existence of this project is not an attack on Objective-C. Objective-C is not hard to learn and awesome, I agree. But what does that have to do with providing an alternative? There can exist multiple good solutions to one problem. You said it yourself: Ruby is not always the best tool for the job, perhaps Objective-C is also not always the best tool for the job. Perhaps the use o…

I am personally concerned that the Rubyists will flood the iOS development space, bringing their culture and introducing a dogmatic and insular environment. We already have -- and without great fanfare -- Lua, JavaScript, C# (MonoTouch), et al. This seems somehow different.

[deleted]
Post reply on HN